Thoughtworks weighs in on multi-cloud

Multi-cloud simply won’t go away. Amazon Web Services (AWS) spent years trying to avoid it, with persistent messaging that multi-cloud was more exception than rule. 

Former CEO Andy Jassy was fond of saying, “the vast majority don’t end up choosing to be multi-cloud. They predominantly use a single provider.” 

However, it’s becoming clear that multi-cloud is simply how enterprise IT gets done in 2022. At Temenos’ big event this past week, the banking software giant cited survey data from The Economist Intelligence Unit, which revealed that 81 per cent of respondents believe that multi-cloud will become a regulatory prerequisite.

Not a nice-to-have. A requirement.

That’s the financial sector, sure, but we’ve already heard similar rumblings from other parts of the market such as Europe, where new regulations are being considered to force multi-cloud as a path to greater reliability. Never mind that such regulations seem misguided; we may get them anyway. Honeycomb Cofounder and CTO Charity Majors can tell you why they're unlikely to work.

This is why a new post by Thoughtworks executives Sunit Parekh and Rashmi Tambe is so timely.

The why of multi-cloud

One of the best reasons to embrace a multi-cloud approach, say Parekh and Tambe, is to access best-in-class services. AWS, Microsoft, and Google Cloud are each innovating in areas like artificial intelligence / machine learning, data services, and more, not to mention in “basic” things like compute and storage. 

And although each cloud would love to have you use nothing but what they have on offer, the reality is that no cloud has all the right answers for any particular organisation.

Even if you want to use one cloud for all your needs, select services may not be available. As the authors point out, “Until 2019, [Amazon] EKS was not available in AWS Mumbai (India) region. Many companies therefore considered GCP for containerised workloads.” 

It’s convenient to think of the cloud as a homogeneous utility that companies tap into no matter where they are to get the same services. That’s not always the case, and latency might make a particular cloud a smarter choice even if a certain service is available. For instance, it may be available but in a region that is too geographically distant to yield good application performance.

Just as with enterprise IT during the past 20 years, some enterprises will go “all in” on a particular vendor (becoming an “IBM shop,” for example). But these are more exception than rule. Most enterprises have long managed heterogeneous IT environments. The cloud hasn’t changed this.

The why not of multi-cloud

Just as with traditional enterprise IT, the proverbial “single pane of glass” is a bit of a pipe dream. Many tools claim to provide a single view of services running on different clouds, but Thoughtworks notes that cloud service providers “are launching new services and variations at rapid speed and it is impossible for the tools to keep up.”

If someone is trying to sell you simplicity in management, know that this is exactly what they’re doing: selling—and not necessarily delivering. Most of the best tools are cloud-specific or at least better tuned to a particular cloud.

Given that tools won’t magically make multi-cloud a success, it becomes critical to invest in people who can help navigate those clouds. As I’ve written, finding such people is decidedly difficult, if not impossible. Over time, these multi-cloud masters will become more common, but for the near-term future, expect to pay up for that expertise.

It’s also not simple to deliver true application portability across clouds. Yes, Kubernetes can deliver a “cloud-agnostic workload deployment layer.” But this quickly breaks down if the enterprise (wisely) embraces serverless architecture. That Azure function helps you be productive on Azure, but it’s not going to get you very far on Google Cloud. 

Is the right solution to go with lowest-common-denominator services to maximise portability? Not really, according to Thoughtworks: “Opting for an always-on, cloud-agnostic architecture is costly and effort-intensive.”

The list goes on. “Sharding, sharing, and replicating data across [clouds] is the tricky part of cloud architecture implementation and requires considerable time and effort.” 

I happen to work for a company that does this work for you, but what if you choose a different database? You can embrace open source technologies such as PostgreSQL, but if you’re running a cloud’s particular version of it (say, AlloyDB on Google Cloud or Aurora on AWS), you’re not going to be able to run that on multi-cloud.

Does this mean “abandon hope, all ye who enter here”? No, of course not. But enterprises that want to embrace the hype of multi-cloud need to balance it against the reality. Multi-cloud is reality, but that doesn’t mean it’s easy. Successful enterprises will be smart about how they approach it. Be one of those.