So, “superclouds”, eh?
The term seems to have been coined by SiliconAngle, almost as an aside, in a subtitle, accompanied by the briefest of definitions:
A new cloud architecture takes shape: “superclouds”
Today, any company can have a fully built-out platform in the cloud. Venture capitalist Jerry Chen of Greylock Partners calls this phenomenon “castles in the cloud,” but they might also be considered “superclouds” since they’re built entirely on cloud infrastructure.
So a “supercloud” is a “fully built-out platform in the cloud” that is built “on cloud infrastructure”? Or maybe a rebrand of Jerry’s taxonomy? Afraid we’re not not quite in “new cloud architecture” territory just yet. A follow-up piece elaborates with a slightly expanded definition:
Supercloud describes an architecture that taps the underlying services and primitives of hyperscale clouds to deliver additional value above and beyond what’s available from public cloud providers. A supercloud delivers capabilities through software, consumed as services, and can run on a single hyperscale cloud or span multiple clouds.
That last sentence pretty much describes any app running in the cloud. Before even crisply defining “supercloud”, the piece goes on to commit the first known “supercloud-washing” offense:
We’ve called out Cisco Systems Inc., Dell Technologies Inc., Hewlett Packard Enterprise Co. and IBM on the chart because they all have large on-premises installed bases and different points of view. To varying degrees they are each building superclouds.
The “supercloud” is perhaps a participation trophy?
As you might have guessed, I am not a fan of the term “supercloud”. It doesn’t convey any meaningful difference from a hypercloud, nor highlight any salient part of a new model, much less a new cloud architecture. Superclouds run on hyperclouds and also compete with hyperclouds? The hyperclouds can be superclouds too? Ditto hardware vendors? Is supercloud supposed to evoke the superapp, which suggests convergence, when this model is about best-of-breed fragmentation? An industry drowning in jargon needs a higher bar for new terminology.
There is a broader phenomenon going on that “supercloud” may be an attempt to characterize, though I hope it can be saved from being referred to by that term. I think they’ve discovered the likes of Confluent, DataBricks, Elastic, HashiCorp, Mongo, Snowflake, Stripe and Twilio are viable and growing businesses ($300B+ in capitalization there, so it isn’t exactly a nascent phenomenon), that both build on the hyperclouds and in many cases compete with similar services offered by the hyperclouds. They are best-of-breed, cloud-based platform services consumed by developers (through APIs). And some of them are even open source companies that have made the (often cantankerous) transition from bits to services.
The best forward-looking exploration of this phenomenon I’ve seen is a post by Eric Bernhardsson, though he didn’t actually use the “supercloud” term (and my apologies to him for originally thinking he was responsible for birthing it). It is a great post for this prediction alone: “Kubernetes will be some weird thing people loved for five years, just like Hadoop was 2009-2013, but the world will move on.”
This industry landscape contrasts to a model of developers mostly picking a single, captive stack from one of the hyperclouds (and getting a single bill), which frankly was and probably still is AWS’s dream. In this world, the hyperclouds dominate at the level of infrastructure primitives in no small part because of their unrivaled investment in CAPEX (though there are definitely opportunities to chip away at their edges). A maximalist view even sees the hyperclouds capped at the infrastructure level, with higher level platform services predominantly coming from other specialists. And this dynamic is completely orthogonal to hybrid or multi-cloud which are discussions of where and how many at the infrastructure level. The consumption of platform services from multiple vendors seems like a much more common pattern than the consumption of infrastructure from multiple clouds.
Eric asks if “maybe owning the lowest layer isn’t so bad?” It isn’t at all and don’t worry about the hyperclouds or their stock prices. AWS, Azure and GCP still have huge upside, even if best-of-breed platform services outperform higher up the stack. Most of the platform services will be hosted on the hyperclouds and are among the hyperclouds’ biggest customers (but, yay, repatriation!). While the Redshift team hates Snowflake for embarrassing them on their own platform, the rest of AWS busily invoices them.
The impact on AWS is the most interesting here, both because they are the cloud infrastructure leader and because they haven’t demonstrated they are as good as Google or Microsoft (or others) at higher-level services. It may have something to do with their organizational model, which motivates fanatical obsession at the granular service level, but struggles to span an exponentially expanding number of silos. Two pizza teams are organizationally indistinguishable from Soviet spy cells, which hampers cross organizational coordination and integration. Amazon CTO Werner Vogels’ outburst at re:Invent, while silhouetted against a galaxy of AWS service logos, suggests some awareness of this issue and perhaps its intractability: “You have asked for this. It is basically your fault”.
But the megalomania of being an industry leader, their fundamental “spin up a new service” playbook, and the need to match Google and Microsoft’s breadth of offerings for sales efficiency reasons ensure that AWS will continue to try to move up the stack (success not guaranteed). AWS chieftain Adam Selipsky’s repeated speaking point around re:Invent was to expect them to move up the stack (and again, stressing that this is customers’ fault): “you’ll see us continuing to stress that customers want us to continue to build out these horizontal use cases, as well as industry-vertical, purpose-built solutions.”
There is an interesting historical analogue here, as we look at how industry structure has shifted over time. In the beginning, the computer industry was vertically integrated. Each company built and integrated its own silicon, hardware, and system software. You could choose between IBM, Digital, and a bunch of long since forgotten others. But you went “all-in” on a vendor, and accepted their relative competitiveness at each layer of the stack, because no company was best-of-breed across all layers of the stack.
We saw the industry flip to a horizontal model in the ‘80s and ‘90s, where there was ferocious competition at each layer of the stack. Intel was the big winner in CPUs, Microsoft won with the operating system, etc. “Computer companies” were more numerous than ever, procuring the best components from each layer, but strategically irrelevant packagers.
Cloud computing in its most expansive moments looked like a return to the mainframe days, except in addition to doing their own silicon, they also integrated transoceanic cables and buildings you can see from space into their now globe-bestriding stacks. The cloud vendors have been aggressively moving up the stack into higher level services (AWS, as the joke goes, has never met a database it didn’t like enough to force customers to figure out when and what it might be useful for).
But as we see best-of-breed platform services hold their own against the hyperclouds’ comparable services, we could view this as another switch from vertical to horizontal industry organization. The hyperclouds will play, to varying degrees, at the higher levels, but we’re not going to see a world of just three vertically integrated stacks (or 2.5 when I’m feeling abstrusely pessimistic about GCP). This industry structure does more to ensure a vibrant and competitive cloud market than the all the megatons of marketing malarkey about hybrid and multi-cloud (which is another way of saying, sorry IBM, you bet wrong on where the control point is).
Andy Rappaport wrote a seminal piece in 1991 entitled “The Computerless Computer Company” that characterized the then on-going transition of the computer industry from vertical to horizontal. It’s fascinating to read now in light of today’s industry battles and the reemergence of global technology geopolitics. The examples look shakier after 30 years considering Apple’s improbable reincarnation, Intel’s travails, and the idea of Sun Microsystems as a model to emulate. But the three principles for competing still ring true. Loosely summarized: when in doubt, move up the stack. And the cloudless cloud companies are doing just that (although they miss out on the all the CAPEX fun).
With just a few edits, Rappaport’s opening paragraph still works today:
“By the year 2030, the most successful cloud companies will be those that buy cloud computing services rather than build them. The leaders will leverage fabulously cheap and powerful clouds to create and deliver new applications, pioneer and control new computing paradigms, and assemble distribution and integration expertise that creates enduring influence with customers. So long as companies have reliable access to the cloud—and this seldom means the most advanced hardware—there are fewer advantages and a growing number of disadvantages to building it. The future belongs to the cloudless cloud company.”
Yes, there are cloudless cloud companies. But we don’t need to call them “superclouds”.
