Kubernetes has become a go-to way to deploy applications. You can easily deploy your entire microservice infrastructure and service mesh in minutes, just by applying your configuration to a Kubernetes cluster. But what if you need to change locations or move to another cloud vendor in response to shifting business needs? How can you move all your data to a new location without interrupting service for customers?

That’s where data agility comes in. Let’s discuss how you can achieve data agility and application mobility for stateful applications on Kubernetes.

 

Kubernetes Enables Agility Across the IT Ecosystem, but the State Remains a Stumbling Block

 

There are three key elements that make Kubernetes a great fit for servicing evolving workload needs:

Consistent API: Developers can take advantage of a uniform and well-supported API for Kubernetes across any deployment environment.

Declarative nature: Kubernetes comes with the advantage of storing all your configurations as code. In your configuration files that you store somewhere on a Git repository, you declare how you want your configuration to be. You describe the final result, and Kubernetes takes care of doing whatever is necessary to bring it to the state you’ve declared. 

Extensible: Kubernetes has evolved to be highly extensible; you can add features to Kubernetes that teach it about new kinds of resources. 

 

Why Do You Need Application Mobility?

 

There are multiple reasons why organizations strive for application mobility – shifting customer demands, regulatory requirements, internal pressures, or operational needs, such as the need to shift to another cloud vendor due to cost considerations or to gain access to useful features that your current vendor lacks.

A recent Gartner survey on cloud adoption revealed that 80% of respondents using public cloud are using more than one cloud service provider (CSP). These multicloud architectures often arise organically, through the consumption of specific services or SaaS offerings that may not align with the primary cloud strategy, and therefore add complexity to cloud operations.

For example, you have a new customer who works only in Azure or only in AWS, while your application runs on Google Cloud. Or you have a new customer that requires all the data to be stored in the EU due to regulatory pressures. Suddenly, you’re thinking: “Ok, I need to move all my stuff to the EU now. How do I do that?”

You need to respond quickly to changing circumstances, but stateful applications have data that acts as an anchor that is pulling you back. Your state has a gravitational pull that renders your “theoretically mobile” Kubernetes applications completely stuck.

To respond to challenges that require you to be somewhere else in a specific geographic location or another cloud, you can set up a Kubernetes cluster and fire up all of your containers rather quickly. But this new cluster is a clean slate. It doesn’t have the application state your business needs to function.


The bottom line is – your state needs to catch up.


Why Storage is a Stumbling Block

 

The same features that make containers the default choice for cloud-native organizations (flexible, lightweight, disposable) are the same things that make Kubernetes clusters a huge pain when it comes to storage.

Brendan O’Leary, senior developer evangelist at GitLab says:

“Almost every app in existence needs database storage, but in a cloud-native world things come and go but storage can’t do that. Storage has to stick around and solving for that is the hardest part of cloud-native. That’s the thing we need to conquer next.” GitLab

Most business applications are not stateless, says Michael Greenberg, Head of Product at Statehub.

“While we’d all want to live in a world only made of stateless applications, in reality, no business application can ever be truly stateless. You always have data that pulls your application towards it. Theoretically, you can create a new Kubernetes cluster, dump all of your configurations on it, and you’ll get your business environment. But, it won’t be your business environment – it’s a business environment with amnesia.”

Your Kubernetes applications are highly mobile, but only as long as there’s no data involved. 

 

Why Do You Need Data Agility?

 

Data agility remains a problem that still needs to be solved. If your data is as agile and as portable as your Kubernetes clusters, you can be as flexible as you need to be when responding to new operational requirements.

Suppose you built your infrastructure without thinking about it ahead of time. In that case, you are bound to run into problems down the line, such as the lack of operational flexibility and application mobility, vendor lock-in, and resiliency challenges.

Data agility is an important consideration when building your IT infrastructure in the cloud. Without it, application mobility for stateful applications is impossible.

 

You Need a Storage Solution That Was Built for Data Mobility

 

The main reason why it is nearly impossible to achieve application mobility with stateful applications on Kubernetes is the reliance on first-party services for your data. 

These services were not built with data mobility in mind. As far as stateful applications are concerned, moving your state to a different location or a cloud provider as quickly as moving containers between your Kubernetes clusters is nearly impossible when using first-party data solutions.

Kubernetes-based applications are intended to be mobile. But you can’t even ship a snapshot from AWS to Azure or Google Cloud because no compatibility layer or API would allow you to do that. 

The cross-location and cross-region replication are complex enough, but if you want to quickly shift data from cloud to cloud, this is mission impossible. The cloud vendor that you pick today is the cloud vendor you are going to stick with forever because of data gravity.

 

Achieving Kubernetes Stateful Application Mobility in Public Cloud

 

You want to be able to respond to anything that the market throws at you, whether it’s requirements to be in a specific cloud vendor, in a specific geographical region or both. The limitations on data mobility in the public cloud make you unable to react to new business challenges or operational requirements. 

To realize the full potential of the cloud and achieve operational flexibility, your application state must become just as mobile as your containers. You need a solution for your state that extends the agility advantages of Kubernetes to your data.

With first-party providers, decisions such as moving to a different cloud vendor are non-reversible, requiring months of deliberations, preparations, and execution. With a storage solution built for Kubernetes stateful application mobility, this can now be accomplished in minutes and reversed with a click of a button.  

Solutions built for data agility bring the strategic decisions down to the tactical level. Agile storage enables Kubernetes stateful applications that make your business and your IT environment flexible, robust, and ready to take on whatever challenge the market throws at you. Just the way it was always intended to be.