Do you hear that rumbling in the distance? See the concentric ripples spreading outwards, Jurassic Park-style, in your mug of cloud complacency?

That would be the pre-re:Invent rumor, stomping ever closer, that cloudosaurus rex Amazon Web Services is going to announce some sort of multi-cloud management tool before year’s end.

This sounds utterly far-fetched! It can’t be true! AWS has been gaslighting us for years about the very existence of other clouds. They’ve even dictated Orwellian newspeak to their partners in which “multi-cloud”, “cross-cloud”, “any cloud” must disappear down the memory hole.

The idea of AWS building a cross-cloud dashboard is so axiomatically silly that Corey Quinn leads his standard rant by making fun of it.

And yet I believe it’s happening. If not at re:Invent 2020, soon.

And if you’re confused about why, you’re probably still thinking of “multi-cloud” the way vendors tried to sell it to you in 2016: as a hedge, subtle or not, against big bad AWS lock-in.

That’s not how real people are using multi-cloud on the ground. It never was. And AWS knows it.

Multi-cloud is here to stay … at a macro level

Look, I’ve joined the multi-cloud mockers before. I’ve called multi-cloud “a problem in search of a problem” and thrown shade at vendors who strip their solutions to the lowest common denominator in a doomed attempt to outflank provider-native services.

But Lydia Leong nails it when she says that multi-cloud is inevitable in most organizations. (I’d love this to be formalized as Leong’s Law, because it’s going to keep sounding insightful for the next decade.) Past a surprisingly low point of critical mass, you’re pretty much destined to have Azure and AWS and GCP all sprinkled around in your organization - and it doesn’t have to be because you’re making some hare-brained “strategic” choice to play the providers off each other. It could be because you acquired another company, or some team needs a service that one of the clouds provides and the other doesn’t, or (most likely!) you just don’t have any kind of top-down plan at all. Heck, if you operate with Jeff Bezos’ low-communication, high-autonomy 2-Pizza Teams mindset, double- or triple-clouding it at an org level is probably guaranteed.

In fact, when we surveyed 26,000 cloud builders this summer at A Cloud Guru, about 75% of them identified AWS as their company’s primary cloud. But basically the same number said they also have some workloads running on Azure or GCP. Again, nobody is doing this as a strategic choice, it’s just reality. 3 out of 4 cloud shops are cheating on AWS.

So how can Leong be right that multi-cloud is inevitable, while Ben Kehoe also correctly insists that problems solved by multi-cloud are like cow tipping (you know it’s not real because there are no videos of it on YouTube)?

It’s because they are operating under two different definitions of the word.

Multi-cloud at the organization level is what’s inevitable, and not even a bad thing. Multi-cloud at the workload level is marketing-driven fantasy.

Multi-cloud has changed meanings

James Governor of RedMonk put his finger right on the button of this problem a few months ago, observing that what people are doing (successfully! reasonably!) under the umbrella of the term multi-cloud doesn’t bear much relationship to how vendors are trying to sell it. He spends awhile in that piece casting around for a better term to describe “best-of-breed service selection that mixes and matches between cloud providers and other SaaS vendors”, but doesn’t really come up with anything sticky.

It turns out that there is a term floating around out there that attempts to make this exact distinction, and that word is “polycloud.” I used this word in my book, but honestly, I don’t expect it to stick either. We already have a word that does not sound like a progressive romantic relationship. It sounds exactly like what real builders want it to mean: that they are using services from multiple clouds. Multi-cloud.

Come to think of it, all the kerfuffle around multi-cloud reminds me very much of the forever war for the soul of the word “serverless”. Yes, we know there are servers! And yes, we know that we are running individual workloads on single clouds, we would be dumb not to! But “serverless” has stuck, all semantic distractions aside, because it feels right. “Serverless” is what building on FaaS feels like. And “multi-cloud” is what VPs feel like they are doing when they see a bit of Azure on the BI team and a dollop of GCP on the R&D team.

If we all became more comfortable with descriptivist approaches to language, this would be an easier conversation. But I’m not holding my breath.

So why is AWS finally (maybe) playing the multi-cloud game?

If you’ve paid attention for awhile, you know there are basically two echelons of AWS services:

• The services AWS wants you to use, which are engineered from the ground up to deliver the kind of performance, scale, and (of course) deep integration that define the AWS way of doing things. EC2 fits in this category, as does DynamoDB. IAM, Lambda, S3, Kinesis, ECS. QLDB is a recent entry to the canon. It’s easy to spot these “AWS-native” services because they’re often dogfooded by Amazon retail.

• The … other services, like Amazon MSK (Managed Streaming for Apache Kafka), which sometimes seem to exist only because a customer asked for them. AWS doesn’t necessarily want you to use Kafka instead of Kinesis, or EKS instead of ECS, but they’d hate it even more if your lust for Kubernetes lured you onto Azure or GCP, so they’ll meet you where you are.

Now, take that logic far past what we all thought was the logical limit. AWS can no longer operate in a bubble that only acknowledges Azure and the gang long enough to make fun of their market share in re:Invent keynotes. If their enterprise whales are sending signals that they need tooling to manage multiple clouds (and they surely are! Multiple clouds are the devil to manage, it’s been the knock on them all along!), then AWS will give it to them eventually. It’s in their DNA. It’s how they win.

Put it this way: AWS built ECS because they have great engineers. They sell EKS because they are smart. They are so, so smart. They are the velociraptors of cloud, and as long as they are willing to cannibalize their own offerings in the pursuit of customer value, they will remain hard to beat.

“Multi-cloud is the killer value prop AWS just can’t compete with” is no longer the only safe bet in startup land. Every dinosaur in the virtual re:Invent expo hall is just asking to get hit with an asteroid. Brace for impact.

Links and events

A couple of weeks ago, I walked into a random Barnes and Noble and found my own book sitting on the shelf. It’s hard to put into words what that feels like. The only word that comes to mind is gratitude: for my editors at Wiley, for my technical reviewers and my longsuffering family. And also for the humans, dogs, cats, and amigurumi who have read it and left kind reviews.

If you happen to have read and enjoyed “The Read Aloud Cloud”, would you also consider leaving a quick Amazon review? I’m told this is helpful to the publisher, and I’d be very grateful, one last time. If you did not enjoy the book, of course you can keep that nonsense to yourself.

If you haven’t bought it yet, now’s a great time to knock out Christmas shopping for your non-technical friends and family…

Other links:

• I’m starting a new blog and video series at A Cloud Guru called “Dear Gurus” where I provide career advice for people looking to get into cloud. This series has already produced my all-time favorite YouTube comment: “It wasn’t all BS.” I’ll take it!

• The Cloud Resume Challenge has found sustainable life as the monthly #CloudGuruChallenge, and you can tackle the November edition now (machine learning! Build a Netflix-style recommendation engine!) with special guest Kesha Williams.

• I’ll be keynoting the Cloudunity summit at cloudtamer.io next week. The subject: Cloud in the time of COVID. I’ll leave you with what I’m going to open that talk with …

Just for “fun”

Famous Tech Laws, updated for the pandemic

- Conway's Law -> Conway’s Quarantine Corollary: Eventually, your system quality will mirror that of the remote whiteboard software used to design it.

- Moore's Law -> Moore’s Lament: The number of days in 2020 doubles roughly every two months, while the amount of useful work accomplished in them decreases by half.

- 2-Pizza Team -> One-Screen Team: If you can’t see all your coworkers on the same screen in video chat, your team is too big.

- Murphy's Law: Whatever can go wrong, will go wrong. (This one did not need to be updated.)