Multi Cloud Strategy Do You Really Need More Than One Cloud?

Based on the recent discussions I had with many people over on LinkedIn (connect with me if you want to follow these threads as they happen), I think it is time to tackle one particular topic.

Should you use one cloud or many? And if one, should you worry about vendor lock-in?

Let’s talk multi-cloud!

To be clear: I’m not convinced that multi-cloud is the right strategy for the majority of companies. In my opinion – more than 90% of companies don’t actually need it! (My bet, not based on any facts or research.)

At the same time, it might be the right approach for you if it meets your goals. As it happens, based on Flexera 2020 Cloud State Report, 86% of companies use multiple public cloud vendors.

Shared under CC BY 4.0 license

What do we mean by “multi-cloud”?

It is good to define things before talking about them.

Multi-cloud – what is it? It is an approach where a company is using cloud services from more than one vendor. Simple as that.

For example, you might use Azure and AWS at the same time to host your resources.

As simple as it looks, it is a complex topic if you want to adopt a multi-cloud approach as a strategy. Why?

1. You need to think about the goal for your multi-cloud strategy.
2. What will your strategy be? How will you approach it?
3. How are you going to build it at your organization? With a single team? Or multiple teams?

Let’s talk about these points.

What is the goal of your multi-cloud strategy?

It should be the first question you ask yourself. Why do you want to follow this path?

Here are two most common reasons I hear from people (in a random order, but I hear them about the same).

“I’m afraid that once I go in on one vendor, they will increase prices, using it as leverage”

Believe it or not, this is one of the most common points raised in such discussions.

Let me ask you a question: How many times have you seen mobile providers raising their prices? Doesn’t it seem like they are always offering a promotion, sales, more free minutes etc.?

Exactly. Why? Because they are in the commodity business, and they need to compete in the commodity market. At the same time, they will try to charge you extra for something new and novel – think the time Apple introduced Apple Watch. Some customers paid a premium to get it.

It is precisely where the current cloud vendor market is. The majority of services are in the commodity market. Each vendor has their version of them. Each of them is trying to build something of more significant value, where they charge a premium.

As the recent history of cloud computing shows, over time, prices go down. Why? All vendors provide a similar set of services and compete. It will always drive the base service cost down.

Which, of course, doesn’t mean that you should not pay attention to cloud cost (remember our discussion about Financial Operations).

“I’m afraid of vendor lock-in”

Strong vendor lock-in! It is probably the most common point raised as a reason for looking at a multi-cloud approach.

Is going all-in with one vendor a risk? What actual risk is related to it? It is good to do your analysis.

The majority of companies are already in some kind of lock-in: think all the business software you’ve invested in (SAP, Oracle… you name it). Think long-term support agreements with off-shoring companies.

From this perspective, cloud providers give us options to get out of such lock-in in the long run and have more choice!

When trying to protect your organization from vendor lock-in, what are you afraid of?

• Vendor going out of business and leaving you with nothing?
• Vendor taking advantage of you going 100% in on a contract and financial agreement?

Valid points, but this is why you should invest in building FinOps capabilities to prevent it at the contract level. Again, I don’t think vendors like Microsoft or Amazon will follow those practices for individual customers. Why not?

• It is not a viable approach for them for doing business in the long term
• Let’s face it, at their scale, they are not operating on a single account basis.

The best way to avoid vendor lock-in is to be well educated on the cloud (I hope I’m helping you a bit on this front) and have precise goals and strategy for cloud adoption.

Those are the TWO most common points raised regarding a multi-cloud approach. Now we covered them, let’s talk a bit about how you can go multi-cloud (if you decide to do so).

How to approach a multi-cloud strategy?

Before we begin, let’s repeat it: if you want to consider the technical approach of going multi-cloud, think about, and clearly state your goal of doing it!

Then, consider this goal in terms of what will be needed in your organization:

• managing two (or more) different relationships with vendors
• understanding the financial models of two (or more) services
• understanding and developing operational skills in two (or more) cloud environments
• integration and tooling across two (or more) cloud environments
• understanding and developing security operations for two (or more) cloud environments
• keeping separate technical teams for two (or more) clouds or mixing them.

It is by no means a complete list. Please note that it does not include strict technical skills and capabilities. Those still need to be covered.

So, how to get started with multi-cloud? Here are three models I see most often at companies adopting multi-cloud.

Running separate solutions on different clouds

In this model, you choose where to deploy each solution. When you build a new application, you decide it will be made on, say, Azure or AWS, and then go all-in for this solution on a given cloud, using its native services.

How to make a decision which one to choose? It is beyond the scope of a single article and also cannot be judged without your specific context:

• required technical capabilities
• financial models
• geo-location of services
• environmental footprint (yes, it is a factor as well).

Use different cloud services from different vendors

You can go for cloud services to Amazon, but for a productivity suite, you choose Microsoft 365 or Google. IaaS and PaaS to build your applications are in one nest, but your productivity or CRM solutions are in another.

Here, the distinction is clear – the type of cloud offering.

What often connects these environments is security, as people do not like to maintain separate credentials and access methods to different solutions.

Cherry-picking the best services depending on the task

You can cherry-pick the best approach for specific tasks and define what is given to which vendor. Here are a few examples from the real world:

• A retail vendor is hosting infrastructure on AWS but the entire data analytics solution is being built in Azure (reason – an integrated solution across full data services and end-user environment)
• Cloud workloads are across AWS and GCP but security services are provided by Azure AD (the client uses Office 365 as well).

Some degree of integration is required, but this is often at an interface or network level. You still have to pay attention to the tasks mentioned at the beginning of the list but the dividing line is clear.

Those scenarios find confirmation in the report I cited earlier. Apps siloed on separate clouds make up 55% of all multi-cloud deployments.

Shared under CC BY 4.0 license

Approaching multi-cloud the wrong way

Here are TWO approaches, which I don’t think make sense for a multi-cloud environment.

Keep everything in the infrastructure to be able to move it around

One approach, typically targeted against vendor lock-in, is to keep building everything as an infrastructure service. It means building all services on top of VMs or in containers and avoiding using any cloud provider services.

While it might make sense for some specific cases, for the majority of us, it doesn’t. For the benefit of shifting the VMs from one vendor to another, you forego all the benefits of using cloud services.

You have all the operational pains (maintaining configurations, monitoring etc.) of infrastructure, plus vendor-specific configurations; you have to keep all your teams on standby for some distant, possible move between cloud vendors.

It slows you down, and actually – it is not removing your cloud lock-in issue. Over time, you are getting more and more attached to specific tooling or operations of a particular vendor. Moving out will not be a flip of the switch. Forget it.

Split-app model, aka “let’s build on the cloud to not touch the cloud at all”

This also happens. You develop your app to abstract it from the cloud vendor model. You incorporate some abstraction to every interface. Why? E.g. to be able to change Azure Storage for AWS S3 or another service quickly.

What’s the problem with it?

You burn your time on something which has no business benefit. You limit yourself in speed (time spent on abstracting) and agility (ability to try out new things based on vendor services). This approach, over time, will slow you down and kill all the benefits of using the cloud.

In the meantime, you will invent and develop plenty of brilliant engineering solutions, which will have no use outside of your business in this specific, multi-cloud context.

The variation of this approach is to build an application based on “two legs”, i.e. using two clouds at the same time. Here is a good example from Auth0 of why it doesn’t work in the long haul – Auth0 Architecture: 5 Years In.

There is no better summary of this topic, than the brilliant Forrest Brazeal’s article Code-wise, cloud-foolish: avoiding bad technology choices, and his picture from this article:

I tried, but I can’t write a better summary than Forrest’s drawing. Be cloud-wise!

If multi-cloud, then how?

Well, I’m afraid there is no silver bullet for it that I can give you right now. What I can do is highlight a few factors, which are crucial to success in your multi-cloud strategy.

1. Understand your goals for going multi-cloud and be aware of additional operations and skills you need to maintain to support it.
2. Understand and adopt some of the Ops we talked about earlier:

• DevOps as a delivery culture
• FinOps to maintain visibility into costs
• DevSecOps to ensure security of your deployments.

3. Align the architecture of your solution with your goals. Be cloud-wise, not “code-wise, cloud-foolish.” Architect for change in the future, but do not let this stop you from leveraging the advantage of cloud services.

What’s your story with multi-cloud?

I am curious about your multi-cloud adventure. Are you using a single vendor? Multiple vendors? What were the reasons for choosing the latter, and how do you use them?

Contact me or leave a comment below. I will make sure to read it. Maybe we can find something to use and educate others together on how to implement the cloud the right way.