Cloud

Why multi-cloud isn’t  always a strategy — it’s a symptom

Stuart Scott explores how multi-cloud adoption is often a reactive symptom of organisational challenges rather than a deliberate strategy.

We’ve all been there. Someone says they want to go ‘multi-cloud’ to spread risk and improve flexibility.

There are good reasons to go multi-cloud. Using multiple providers can provide access to lots of specialised tools and new technologies. And by strategically choosing different clouds for specific workloads, firms can tap into the best-in-breed. It can also improve resilience and business continuity – minimising the disruption caused by an outage.   

It sounds wise – and it is. But more often than not, ending up with a bunch of different clouds isn't part of any grand plan. It just happens, often by accident.  In many cases, multi-cloud isn’t a strategic decision. It’s a by-product of organisational dysfunction or poor planning. 

And when there is no strategy driving this change, multi-cloud can easily become a hinderance rather than a business edge. There are benefits to a multi-cloud plan: but rarely if it happened by accident.  

We’ve become multi-cloud by mistake!

The world is a messy place – and so are companies. There are lots of ways multi-cloud happens without a clear plan. There are four in particular that I think are most common.  

First, are mergers and acquisitions. Company A buys Company B, and suddenly you’ve got  Company B's whole cloud setup to deal with, even if it's totally different from yours. This happens a lot and can be an integration headache.   

Second, shadow IT: teams pick whatever cloud seems easiest or works best for their project, without anyone in charge knowing or caring. You have probably read all about ‘shadow AI’: which is staff using large language models without permission. But it’s happening in the cloud, too.   

Third, vendor lock-in avoidance: bosses – who rightly worry about risk attached to overreliance on a single vendor – might demand a multi-cloud policy. But sometimes that comes without a clear plan for how to make that work.  

And finally there are times when a company genuinely needs something a specific cloud offers, or need to use a certain cloud because of where its data needs to live. This is especially true with GDPR rules.  

Whatever the reason, becoming multi-cloud without a clear strategy and vision can cause problems.  Trying to manage different clouds with different rules and tools is tough.  Not least of all because of compliance problems, which can quickly multiply. A 2021 report by HashiCorp found that 59 per cent of organizations using more than one public cloud reported increased operational complexity.  

That in turn can cause a drain on your already overworked IT team, who now have to learn a load more cloud systems. (One recent study found that three quarters of organisations reckon skills gap is a major challenge working across clouds).  

But perhaps the most surprising cost of accidental multi-cloud adoption is, well, the literal cost.  According to research by IDC, organizations that lack a consistent multi-cloud management strategy can overspend on cloud resources by up to 30 per cent, partly because you lose the benefits of bulk discount. And besides – trying to build and release new stuff when your processes are all over the place takes longer. Which again means more cost.  

What a real multi-cloud strategy looks like

There is a proper way to do this: and it's not just about having accounts with a few different providers. My idea of the perfect mutli-cloud strategy would involve several, very carefully thought through elements.  

First it would mean building things so they can run pretty much anywhere – often called vendor-neutral architecture. Things like using Docker and Kubernetes that hide the cloud-specific bits.   

It would also involve cross-cloud observability, security, and governance. In other words – it should make things easier to manage in one place. Imagine having one dashboard for all your clouds, like a super-SIEM. (A SIEM, or Security Information and Event Management system, is like a -detective that works across all your computer networks and systems. It logs all activity and tries to look for unusual or suspicious activity).  

And the teams building and running your stuff? They should be using the same ways of working everywhere – something we call ‘unified DevOps practices’. Essentially the people who develop software and the people who operate the software should be working closely together: the same tools, the same automation processes – regardless of which cloud they are using.

The US bank Capital One is a case in point. In 2020 it became the first US bank to fully migrate its operations to the cloud, closing eight on-site data centres, and shifting to Amazon Web Services and Microsoft Azure. The results of this carefully planned move are impressive: it has helped the company become faster, more secure, and better at keeping in line with regulations. For example, it dramatically sped up its software releases—from monthly updates to multiple releases per day. Capital One uses Open Policy Agent to automate rules across all systems, which covers several hundred development teams. The result is significantly fewer security incidents as a result of misconfigurations. 

But the truth is, I rarely see the perfect set up. It’s not easy to do – especially when the driving force for so much cloud adoption is not the strategic needs of the firm, but the desire to try different AI tools.  

From ‘everywhere’ to ‘just right’

The best way to do multi-cloud is when it's a deliberate choice that makes sense for your business, not just something that happened. It's about being ‘cloud smart’: picking the right cloud for the right job, not just trying to be on every cloud at once.  

So, have a good hard look at your cloud setup. Did you choose to be multi-cloud, or did it somehow choose you?  

If it's the latter, don't panic. You can still sort things out. Maybe it's time to consolidate where you can – there are plenty of guides on how to do that well.  You might also look at getting multi-cloud management tools to get a better handle on everything: things like CloudHealth by VMware or Flexera Cloud Management Platform. And it’s definitely worth getting your teams trained up on how to actually manage multiple cloud properly.  (We at QA can help with that.)  

Multi-cloud can be a highly beneficial move: but only if you go into it with a clear plan and know what you're doing. It shouldn’t be a side effect, a vanity project, or a series of piecemeal decisions. And never be afraid to admit it’s not working. The sooner you do that, the sooner it can be resolved.

Related Articles