If you believe what many vendors and pundits say — “multicloud is the default cloud strategy for enterprises” — then I hope you aren’t in charge of any kind of IT system, be it design, procurement or delivery.
If you believe this multicloud myth then you are complicit, at a stroke, of paying more for an under-performing cloud strategy. Controversial? No. Everyday situation. This article has been written to do two things.
Firstly, I’ll expose the marketing fallacies of the proponents of multicloud. Secondly, I’ll expose the harsh realities of multicloud in terms of opportunity cost, operational cost, and frustration through under-delivery of over-stated expectations.
The goal of this article is to inform everyone in IT that, while multicloud is a necessary evil for some outlier companies, multicloud is a cloud anti-pattern for the majority of enterprises seeking to exploit cloud for business success.
Multicloud is a drag on the agility, resilience, cost, security and innovation opportunities available in the cloud.
Putting down the hammer on the Multi-Cloud Marketeers
Imagine you find yourself hitting yourself in the face with a hammer and causing yourself a headache. What do you do? According the multicloud marketeers, you should keep hitting yourself and buy a headache pill. But it gets worse.
Imagine you are NOT hitting yourself in the face with a hammer and you do NOT have a headache. The multicloud marketeers want to persuade you to buy a hammer and start hitting yourself in the face and get a headache.
Why? Because they want to sell you a headache pill.
The argument for multicloud is often based on surveys of opinions of vague definitions (see Rightscale State of Cloud Report).
Multicloud is variously described as a “strategy” (for extra vagueness). In the same Rightscale report, some respondents report their “vSphere” clusters as being a cloud, showing that some respondents don’t even grasp the basics of cloud.
Multicloud the Bandwagon
In the same Rightscale State of Cloud Report, it’s stated that over 80% of respondents are “doing” multicloud (though it’s not clearly defined what it is), and the message picked up by marketers is, therefore, that multicloud is a mainstream strategy. Everyone’s doing it. Come on in, the water’s lovely. Or it could be lava, who knows.
Multicloud the Red Herring
There are some difficult questions for the purveyors of multicloud.
First of all, they don’t sell multicloud, they sell a widget for it. Therefore they aren’t vested in the success of multicloud, just their bit. Nevermind the complexity of the rest as long as their bit works. Secondly, they never state why multicloud is a desired end state, just that “it is” and we come back to the hitting-ourselves-in-the-face position.
To get rid of the headache we need to stop doing multicloud, stop buying headache pills, and ask better questions.
In the next section we dive into multicloud itself and expose it for what it is, why it’s a problem, why it is sometimes necessary as a journey, but never as a destination at the end of a cloud journey.
The Harsh Business Realities of Multicloud
Every cloud service provider you consume requires you to invest in your part of the shared responsibility model. For the cloud newbies they incorrectly think of CSPs as like your traditional outsourcers doing “my mess for less”. This is not cloud.
In the cloud, YOU are responsible for a large part of the operations and their outcomes such as instance patching, availability, security of YOUR STUFF.
Higher-order cloud services such as AWS Relational Database Services ease that burden as the CSP takes on more operations, but you pay more for this and you still have some administrative burden.
It is an indisputable fact that to be good at just ONE CLOUD, never mind many, you have to invest in trained and experienced people, evolved processes and new tooling and technology. This can cost millions of dollars and months of experience. Some people never get good at one cloud.
Now along come the headache pill sellers saying you need to do many clouds because “everyone else is, and it’s the major enterprise strategy” – which we know is flawed, but not everyone does. You must now ask yourself two tough question
1: How much additional overhead for every additional cloud?
2: How can I go deep/be expert on multiple-clouds if I can’t go deep on one?
The answer you will find is:
1: You will have much higher overheads the more clouds you have
2: The more clouds you have the more shallow you will experience each cloud.
You can measure your success across one cloud and many clouds using five pillars. And my prediction is that your success in each pillar is inversely proportional to the number of clouds you have in your multicloud.
Agility – getting stuff done, apps released, data analysed
Resilience – not just backup, recovery and DR, but responsiveness to events and availability
Security – all clouds have different models and IAM is an example of cloud security that is intimate to individual clouds. No universal cloud security model exists at depth
Cost – Understand the cost models of one cloud is hard, and keeping downward pressure on them is an expert job. Imagine the multiplier of being bad at costs across multiple clouds
Innovation – keeping up with one cloud is hard: keeping up with many impossible. Also, your “multicloud tool” will struggle with API lag, which is keeping up with all clouds. Your tool will likely impinge your ability to exploit cloud innovation
What to Do if You’re Experiencing Multicloud
It could be that you can, individually, do nothing. But generally if you are experiencing multicloud then the overall drive for everyone must be to reduce the number of clouds.
If you are in a multi-cloud situation you need to drive towards one major and one minor cloud provider. The reasons for this are all the opposite reasons why multi-cloud is bad, namely:
With fewer clouds you have less overheads, more focus and can go deeper and get greater value out of better, deeper clouds (more services, more innovation, more cost savings etc)
If you are a practitioner, focus your skills on the major cloud provider, not the minor and not any other. This is in your, and the organization’s, best interested.
If you are in procurement, focus your depth of relationship and benefits (volume discounts etc) on the major cloud provider, and prioritise all cloud purchases to the primary with a strict and difficult exception process including incentives (see five pillars) for the major CSP.
If you are a CTO or an enterprise architect, do not let your fear of lock-in and the costs of that, be paid for today in real terms by the high costs and low performance of multicloud.
You can save a minimum of 20% in a primary cloud from on-demand premium costs, but you can save a hell of of a lot more by focusing. You cannot get these across many clouds. The overhead cost of adding a cloud outweighs any penny savings off an instance price.
All this said: Some organisations do have genuine reasons to have a multicloud strategy. These organizations might have a duty to maintain a two-vendor solution and they might choose to connect these two into a hybrid or multicloud.
They might have such a complex non-cloud estate that their cloud migration makes more sense through a multicloud lense. They might have significant investments in clever technology and effective IT teams that multicloud is doable.
Not all enterprises have these duties or capabilities however — which is why it’s a mistake to extrapolate multicloud as a “default cloud strategy” for all enterprises — but for some it’s reality and in these cases, it makes sense.
This article is from the CBROnline archive: some formatting and images may not be present.
Join Our Newsletter
Want more on technology leadership?
Sign up for Tech Monitor's weekly newsletter, Changelog, for the latest insight and analysis delivered straight to your inbox.