arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full dots-horizontal facebook-box facebook loader magnify menu-down rss-box star twitter-box twitter white-balance-sunny window-close
You might not need a multi-cloud strategy after all
5 min read

You might not need a multi-cloud strategy after all

Today,  I want to talk about what seems to have become a controversial word in the world of cloud — multi-cloud. For Google Cloud, it's become central to their product strategy, and is viewed as a competitive differentiator, while for AWS it's viewed as a threat, and was only recently removed from a list of "banned" words for partners attending conferences.

Companies aren't sure what to do either. I've seen companies that use multiple clouds, and aren't really sure why, companies that have started using a second cloud without a comprehensive strategy, and companies that have deliberately chosen to stick with one.

In this post, I want to cover three things.

First, what are the benefits of using multiple cloud vendors, and are those benefits realized? Second, what are the costs, seen and unseen, of using more than one provider? And finally, in what contexts might it make sense to use multiple clouds anyway?

The benefits of multi-cloud

There are a few key reasons why companies choose to use multiple cloud providers:

  • To avoid "vendor lock-in" and bring competitive tension to the contract negotiation process
  • To allow their developers to use the best services across multiple clouds
  • To take advantage of credits rolled into their productivity suite contract (looking at you Microsoft)

Let's walk through each of them in a little more detail.

Avoiding lock-in with lock-in

Avoiding vendor lock-in has been a central part of software procurement decisions for decades, but it should be treated as one factor among many, and weighed against the complexity that comes from selecting multiple providers.

Specific to cloud, there are two main points to make here.

First, when it comes to the cloud, vendor lock-in is less a function of whether you choose one provider or two, and more a function of how you architect specific workloads with those providers. If you choose to go with multiple cloud providers, but then build complex services exclusively using 'sticky' services like AWS Lambda and Google Cloud Functions, you'll still find yourself with a lot of work should you ever want to migrate those services to another cloud.

Second, in choosing to maintain flexibility, you restrict yourself to using only those services that can be easily transferred between providers — things like VMs, container services, and SQL databases that have a portable artifact with a standard format. Unfortunately, these are also the services that offer the least return on your investment.

Lifting and shifting workloads to the cloud, by itself, is unlikely to offer you significant value. Rearchitecting those services to take advantage of managed services and scalable cloud infrastructure will. Paradoxically, in your efforts to avoid vendor lock-in, you've locked yourself in to using low-value services that prevent you from getting a better return on your investment.

Best of breed products

Some companies choose to use multiple cloud providers to ensure their developers have access to the best services on each platform, and can pick and choose the services that best meet their requirements.

This is well intentioned, but as of writing, across the three major cloud providers, there are 558 (no that's not a typo) different services available, with a significant amount of overlap in capability among many of them. I don't know about you, but having developers sift through half a thousand products looking for the best fit for their workload seems inefficient to me.

Having said that, there is some value to the "best of each platform" argument. Some services, like Google Cloud Spanner, don't have an equivalent on other platforms. If you need that specific capability, it might make more sense to use another cloud provider than to recreate the functionality elsewhere.

"But it's free"

Finally, you might find yourself in a situation where a cloud provider Microsoft is willing to throw in a bunch of cloud credits as part of a larger productivity contract.

Needless to say, it's tempting, and looks free on paper, but it rarely turns out that way. Cloud providers know they're in a consumption business — once you migrate a workload and start spending, you almost certainly won't go back. Unless you're very careful to use only easily transferrable services to burn through your credits, there will be significant work required to migrate the workload once they're gone. They know this, it's why they do it.

The costs of multi-cloud

In a similar vein to the benefits, there are a few major costs to using more than one cloud provider:

  • The cost of maintaining enterprise support across multiple vendors
  • The technical complexity of bridging multiple clouds — this has both an upfront and an ongoing maintenance component
  • The time developers need to invest in learning multiple platforms

Once again, let's walk through these one by one.

Support ain't cheap

Most organizations will require enterprise level support to meet their requirements for hosting critical workloads with a cloud provider. For Google Cloud and AWS, this starts at $15,000 a month, and goes up from there, depending on usage. Azure isn't quite so transparent with their pricing, but let's assume it's similar.

For most large organizations, this is a fixed cost to using multiple clouds that is often overlooked. It might not seem like such a big deal, but the costs quickly add up. If you use all three major cloud providers, you're looking at over $500,000 a year, just on support.

It's particularly wasteful if you only have a few small workloads running on one provider — in these scenarios, it isn't uncommon for support costs to represent 20% - 50% of total cloud spend for that provider.

Bridging two (or three) worlds

Moving from one cloud to two comes with a whole host of new technical challenges:

  • Identity federation, extending security perimeter, and handling short-lived credentials for service accounts across clouds
  • Networking across two or more clouds, IP management, maintaining portability of data, and egress charges when crossing network boundaries
  • Centralizing management of compute infrastructure across providers, ensuring compatibility with existing CI/CD workflows
  • Building a strategy and process to determine which workloads should live on which clouds, and why

The effort required to adequately address these challenges is significant. Networking alone can be tricky to get right, especially considering that there are significant differences between network infrastructure across providers. These challenges aren't insurmountable, and there are plenty of open-source technologies and 3rd-party tools that exist that can help you solve them, but they all come at a cost, be it time or money.

Learning it all

It's true that there are many similarities between the services that the different cloud providers offer, and there's a certain amount of cloud knowledge you can gather that is provider agnostic. It's also true though that there are significant differences in the way some services are structured and architected — a "best practice" serverless architecture in AWS is unlikely to be so in GCP.

Using multiple clouds, then, means asking your developers to learn how each one works, and what the relative strengths and weaknesses of each are in order to make sound architectural decisions. In my experience, most developers are unlikely to rise to that ask, not because they can't, but they don't perceive it as their job to learn the nuances of different cloud providers.

It's possible to abstract these differences away from developers (I managed to get this far without mentioning Kubernetes), but this just shifts the burden of understanding from application developers to the infrastructure engineers.

Wouldn't it just be far simpler if everyone got to learn one thing well?

When multi-cloud makes sense

All this isn't to say that one cloud will work for everyone. There are some good reasons to use multiple clouds (though not as many as you'd think):

  • If you want to use a particular service that isn't available on your existing cloud, and, even considering the added costs of using a second cloud, the benefits are significant (you can apply this same logic to hybrid cloud, which I haven't mentioned intentionally)
  • If you have an existing contract or credits that you need to burn down with another provider (stick with generic services unless you want to get stuck)
  • If you feel that the additional discount you get from maintaining competitive tension in the contract negotiation process exceeds the costs of using multiple clouds (having seen this process from the inside, I'm pretty confident this is almost never the case)

Barring those reasons, you'll get the most value from the cloud by picking one provider, learning to use it well (and integrating it with your business processes), and moving 'up the stack' by taking advantage of managed services where possible.

Enjoying these posts? Subscribe for more

Great! Check your inbox and click the link to complete signin.
Please enter a valid email address!
You've successfully subscribed to Cloudy With a Chance of Rain.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.