Realizing the Dream of Cloud Native Application Portability
Image via Unsplash.
Moving an application from one place to another sounds simple: zip it up, ship it over and unzip it. What’s so hard about that?
Such simplistic thinking may have described application portability in the virtual machine (VM) days, when imaging an entire volume captured everything you needed to move an application.
In the cloud native world, however, it’s not so simple.
What do organizations want from cloud native application portability? Why is it so difficult? And most importantly, how do you get it right?
Why Do We Want Cloud Native Application Portability Anyway?
There are several reasons for wanting to move a cloud native application:
- Hot backup. An organization might want to run a live copy of a cloud native application in two different clouds, or perhaps on- premises and in a cloud, in order to be able to switch traffic from one to the other quickly in the event of a failure.
- Multicloud load balancing. If an organization is going to run a hot backup, it might as well divide up live traffic across application instances. This approach also avoids the “all eggs in one basket” problem, as long as the application instances are running in separate clouds.
- Deploying to new environments. In some cases, deployments to production follow GitOps practices, essentially updating them on an ongoing, piecemeal basis. In other situations, an organization might want to move the entire application from dev to staging or staging to production as a unit (or perhaps to additional environments, like a canary or A/B testing deployment).
- Switching clouds for business reasons. Many organizations move from one cloud to another to save money, or perhaps because of a falling out with a provider. Others move from a cloud to on-premises because, at some point, on-premises is more cost-effective.
Why Is Cloud Native Application Portability So Difficult?
Look closely at what it means to be a cloud native application, and many challenges quickly present themselves:
- Applications running on Kubernetes aren’t monolithic. They consist of ephemeral microservices as well as configurations and data. Furthermore, these elements may not all reside on the same VM. Moving them is like moving sand with a fork.
- Microservices are generally stateless, while Kubernetes handles persisted data in an abstracted way. Unlike three-tier applications where database connections are explicit, cloud native applications access persistent data and other state information via operators that abstract the connections. Understanding which data go with which application at a particular time can be tricky.
- Snapshots are usually ephemeral. Creating volume-level snapshots is a common and versatile approach to accelerating volume-level migration. While Kubernetes supports such snapshots, they are generally ephemeral, and thus do not guarantee application-consistent delivery.
How to Achieve Cloud Native Application Portability
Fortunately, modern data protection from vendors like Kasten by Veeam address the challenges above. Here’s how Kasten does it:
- Automatically discover and migrate all Kubernetes components, configurations and data. Instead of taking a volume-centric approach, take an application-centric approach that accounts for Kubernetes’ distributed and ephemeral nature.
- Support portability across namespaces, clusters, regions, clouds and Kubernetes distributions. In theory, Kubernetes runs the same way in one location as another. In practice, however, there are numerous subtle differences among cloud providers and Kubernetes distributions. It’s essential to abstract and resolve these differences.
- Emphasize portability of data at scale. For application-consistent cloud native portability, it’s essential to restore, clone and upgrade data as well as migrate it from one location to another. Furthermore, it’s important to handle these intricacies at scale.
- Cloud native application portability capabilities should be an extension of its data protection expertise. Backup and restore of applications and data are at the heart of data protection. As a result, it’s possible to treat planned application mobility as a special case of the much more difficult problem of application restores after sudden and unexpected failures.
The Intellyx Take
Business continuity is the key to successful application portability, just as it is for application backup and restore. In some situations, it certainly makes sense to turn off an application before moving it. In other circumstances, an application won’t receive live traffic until the migration is complete.
But in the more general case, organizations need the ability to move an application while it’s running, while active workloads are currently processing transactions and the underlying data are in flux.
Application portability in such situations is like rewiring your house with the power on – one wrong move and you’re dead.
Most cloud native application portability approaches on the market are essentially Day Zero technologies – handle the application migration before making anything live.
Kasten, on the other hand, built its technology to handle backup and restore for running applications, where it’s important to keep track of the state of transactions in progress.
This capability, in turn, is essential for most cloud native application portability scenarios, as organizations expect their cloud native apps to be up and running all the time — not simply on one VM, but across VMs and clouds, scaling up and down as necessary.
In other words, cloud native application portability can be a Day 2 (full production) effort without the risk of electrocution.
