All companies that use cloud services do so for a reason. But those reasons may change. Whether motivated by the need for a multi-cloud strategy, expenditure minimization, legislative or regulatory demands, or simply to get closer to end users, many organizations find themselves migrating from one cloud to another. Cloud-to-cloud migration for a non-trivial application contains a lot of unknown unknowns. This causes stress and uncertainty for a CTO. To help shed some light based on years of experience in the field, we have asked senior cloud architect Lars Larsson at Elastisys, to list some of these issues.
Most companies have been hit by that one cloud bill that surprised them. Some services or features wound up costing far more than originally anticipated.
Are you considering a cloud-to-cloud migration to reduce operational costs? If so, please take a long and hard look at the various costs in each of the clouds. Because each service has a different cost model, making it very difficult to compare accurately. You really need to get to the bottom of it.
Compute and storage costs are often easy enough to compare, because those are the most obvious two. But what about other services? How much are you spending on, e.g., log handling or monitoring? Good services such as AWS CloudWatch come at a cost, especially if you use it for log handling too (AWS CloudWatch Logs). Are you heavily using a managed database service? A queueing or pub/sub service?
Avoid feeling like that one time the surprise cloud bill hit you in the face by doing your homework this time. You are wiser from the experience, after all.
Network transfers in and out of the cloud can also vary by quite a large amount. The three major providers will give you incoming network traffic for free, but charge you for the outgoing traffic. Smaller, regional, cloud providers will often have higher compute and storage costs, but not charge you for network traffic. Or include a much larger amount of it in a free tier offering.
Overwhelming? I get it. It sure looks that way at first glance! But it doesn’t have to be. My trick is to look at your past few detailed billing statements, and map those costs to your new cloud provider options.
Tell me, did you adopt Kubernetes to make yourself less dependent on cloud providers? Reduce vendor lock-in? Are you now surprised at finding out that you are still locked in, but on a different level?
What I’ve seen is that most organizations will make sure they have highly portable application definitions. By relying on Kubernetes, the application definitions work across cloud providers.
But what I’ve also seen is that if you are using a managed Kubernetes service, your users and permissions handling is perhaps tied not to Kubernetes role-based access control (RBAC) features, but rather, to cloud-specific offerings. Like AWS Identity and Access Management (IAM). Great service, but ties you to the AWS platform.
Fully-managed Kubernetes services, if offered by cloud vendors themselves, serve to offer a highly integrated experience. The cost of that integration is that migration to another cloud provider becomes just that certain amount more difficult.
As a community, we’ve tried to fix this. But as a community of engineers, those fixes are technical. Kubernetes dictates standards for certain components or aspects. Networking has to work according to the Container Network Interface (CNI) standard. Storage according to Container Storage Interface (CSI). And so on. Great. But the business people have put in much more clever ways of locking you to the platform. This means that other less obvious aspects are more difficult to freely migrate from one cloud to another.
So what is the option? Do you have to manage Kubernetes yourself? No. Of course not.
