BrainBlog for Kasten by Jason Bloomberg
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.
Read the entire BrainBlog here.
SHARE THIS:
