Simplifying Hybrid And Multi-Cloud Portability for Stateful Applications on Kubernetes

Today, we were excited to announce that the Robin Cloud-Native Platform is simplifying application portability across multiple cloud environments. With this product update, we are enabling our customers to more easily adopt the right hybrid or multi-cloud strategy that aligns with their business needs.  

First, some background: The number of applications enterprises need to run their business is ever growing. And as a result, the infrastructure needed to support these applications needs to scale in an agile and cost-effective manner. The data center has undergone significant evolution from the mainframe era to public/private clouds, and the traditional data center approach that has resulted in silos has given way to a  hybrid and multi-cloud strategy. Enterprises have the choice to leverage multiple public clouds and private clouds based on their business needs. Each enterprise will have to analyze their requirements and choose an infrastructure strategy that includes private clouds, public clouds, or a combination of both.

Hybrid cloud vs Multi-cloud: What’s the difference?

A hybrid cloud setup is a combination of a private cloud and a public cloud. In this strategy, the applications can be categorized so that one group can run on on-premises in a private cloud and another group on the public cloud. It is also possible that a single application can stretch between private and public cloud. In this scenario, public cloud can be used for peak usage periods to burst the application from private cloud, as a disaster recovery site, or as a backup destination.

In a multi-cloud setup, there are two or more public clouds used for the enterprise needs. A private cloud could be an addition to two or more public clouds. With public cloud options that include Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, IBM Cloud, there are ample choices for the enterprises to pick for their public cloud strategy.

The Need for Application Portability

Leveraging a hybrid or multi-cloud strategy requires the ability to move workloads between clouds to avoid infrastructure lock-in and to achieve better cost economics. However, each cloud has its own method of automation, deployment, and monitoring, making it challenging to move workloads, often resulting in costly migration projects. For a multi-cloud strategy to be practical, a business application deployed on AWS should have the ability to move to Azure or GCP with ease and should not require a large migration project. Public and private clouds should be simply seen as resources, and platform engineers or site reliability engineers (SREs) should have the ability to move applications from one cloud to another with the click of a button.

Kubernetes: The Standard Platform Across Clouds

Kubernetes has become the de-facto container platform to run cloud-native applications. It is an application management framework that handles orchestration, deployment, scaling, self-healing, automated rollouts and rollbacks.  It has been adopted by all public cloud providers and it has become a common runtime layer across all the clouds, with all public cloud providers also offering managed Kubernetes services. 

Kubernetes as the common runtime environment enables consistent experience for the deployment and lifecycle management of the applications across the clouds. It has enabled application portability for certain stateless applications. However, Kubernetes alone does not provide the ability to move complex stateful applications across clouds. 

Challenges with Portability for Stateful Applications

Enterprise applications can be categorized into stateless and stateful applications. A stateless application does not save any state and does not depend on it to run. Stateless applications are simpler to shift from one cloud to another than a stateful application. A stateful application is a  data-intensive application and needs its data to be persistent for it to function and provide services. Applications like MySQL, MongoDB, Cassandra, Hadoop, and ELK are all examples of stateful applications.  Moving a stateful application from one cloud to another entails shifting the application configuration, metadata and data. This can be challenging, because there is no construct in Kubernetes to wrap all these relevant components in a single entity, meaning the state of the application has to be carefully recreated on the target cloud. Moreover, the state of the application, i.e., data stored in the storage volumes, also needs to be migrated seamlessly across the different storage environments in different clouds. There is a lot of complexity in enabling this capability manually or through custom do-it-yourself scripting work.

Robin Brings Portability to Complex and Multi-tier Stateful Applications

The Robin Cloud-Native Platform enables enterprises to deploy and manage these complex, data-intensive applications with an “self-service” experience anywhere, on-premises or in the cloud. It combines app-aware storage, virtual networking, and application workflow automation built on industry-standard Kubernetes.  The Robin Platform now extends Kubernetes and provides a simple three-step solution to move complex and multi-tier stateful applications from one cloud to another.

Robin provides hybrid or multi-cloud portability for applications and data

Step 1: Create application-level snapshot on the source cloud

The advanced application management capabilities of the Robin Platform allow users to create an application-level snapshot of the application. The application level snapshot captures all metadata, configuration, and data at a certain point in time in an application-consistent manner across multiple services of an application even if they are running on multiple servers and using several storage volumes.

Step 2: Push the snapshot to a global repository

Robin enables users to create a global repository for pushing an application’s snapshot(s). For example, you can create a global repository on AWS S3, which will be accessible to all clouds in your infrastructure. Once you register the global repository with the source, you can export application-level snapshots with a single command or click, using the snapshot created in the previous step.

Step 3: Pull The snapshot from the global repository to the target cloud

On the target cloud, the user simply has to register the same global repository to gain access to all snapshots stored in the repository. Once registered, the user can recreate the application, along with its data and exact configuration, by importing the application-level snapshot using a single command or click. Recall that Robin’s snapshots include the applications metadata, data and configuration. Therefore, upon importing/pulling a snapshot into a different cloud, Robin automatically takes care of mapping the configuration, metadata and data from the environment in the source cluster to that in the target cluster.

See It In Action

In the video below, we will show how simple it is to move a multi-tiered application from AWS to GCP using Robin. We will create a WordPress application with MySQL backend on AWS, create an application-level snapshot, create a snapshot in the global repository using the snapshot on Google Cloud Storage, and import the snapshot in GCP to recreate the application in the exact state it was on AWS.

In the coming days, I will blog about interesting application management topics such as multi-cloud portability, backup & recovery, application consistent and storage efficient snapshots, and disaster recovery, all in the context of Kubernetes. Stay tuned. In the meanwhile, you can download our Advanced Data Management for Kubernetes white paper to learn more about Robin, or visit our website at www.robin.io.