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?
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.
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?
Let’s talk about these points.
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).
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).
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?
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?
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).
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:
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.
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:
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.
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:
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.
Here are TWO approaches, which I don’t think make sense for a multi-cloud environment.
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.
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!
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.
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.
Sometimes it feels like I'm pushing too much with security and software development, but then you prove me wrong. Rec...
We talk a lot about perimeter security, zero trust, etc. And there’s a good reason for it. Malware attacks don’t jus...