Supercloudifragilisticexpialidocious V: Everything is Not a Thing

Tl:dr: the “supercloud” is not an architecture or a category – it is a media artifact. When everything is a “supercloud”, nothing is, which makes it much harder to be a thing.

A note regarding relevance: this post is as niche as they come, a minor skirmish in the never-ending and often fruitless battle for coherence and meaning.

After seven months of chanting “supercloud is becoming a thing”, the “supercloud” shepherds have deigned to respond to some of the dozens and dozens and dozens and dozens and dozens of questions previously raised regarding the “supercloud” term and concept.

I will limit myself here to my three primary and oft-repeated questions:

• What is the definition of “supercloud”?
• What does and doesn’t qualify as “supercloud”?
• How does “supercloud” relate to existing categories, nomenclature, and taxonomies?

WHAT IS “SUPERCLOUD”?

This seemingly relevant question was not one of the ten questions addressed in the recent SuperFAQ. Seven months later there still is no precise definition of “supercloud” (it is perhaps an aspiring vibe?). Instead, there are words that appear in answers to other questions that describe “supercloud” in passing. Some excerpts:

And so we introduced this notion of supercloud to describe what we saw as a value layer emerging above the hyperscalers’ “capex gift.”

It was more than infrastructure as a service and platform as a service and wasn’t just software as a service running in the cloud.

It was a new architecture that integrates infrastructure, unique platform attributes and software to solve new problems that the cloud vendors in our view weren’t addressing by themselves. It seemed to us that the ecosystem was pursuing opportunities across clouds that went beyond conventional implementations of multi-cloud.

Rather, it’s a new type of digital platform comprising a combination of multiple technologies – enabled by cloud scale – with new industry participants from financial services, healthcare, manufacturing, energy, media and virtually all industries. Think of it as kind of an extension of “every company is a software company.”

Supercloud is an architecture designed to create a single environment that enables management of workloads and data across clouds in an effort to take out complexity, accelerate application development, streamline operations and share data safely irrespective of location.

And “superclouds” have some pseudo-architectural “salient attributes”:

First, a supercloud runs a set of specific services, designed to solve a unique problem. Superclouds offer seamless, consumption-based services across multiple distributed clouds.

Supercloud leverages the underlying cloud-native tooling of a hyperscale cloud but it’s optimized for a specific objective that aligns with the problem it’s solving. For example, it may be optimized for cost or low latency or sharing data or governance or security or higher performance networking. But the point is, the collection of services delivered is focused on unique value that isn’t being delivered by the hyperscalers across clouds.

A supercloud abstracts the underlying and siloed primitives of the native PaaS layer from the hyperscale cloud and using its own specific platform-as-a-service tooling, creates a common experience across clouds for developers and users. In other words, the superPaaS ensures that the developer and user experience is identical, irrespective of which cloud or location is running the workload.

And it does so in an efficient manner, meaning it has the metadata knowledge and management that can optimize for latency, bandwidth, recovery, data sovereignty or whatever unique value the supercloud is delivering for the specific use cases in the domain.

A supercloud comprises a superPaaS capability that allows ecosystem partners to add incremental value on top of the supercloud platform to fill gaps, accelerate features and innovate. A superPaaS can use open tooling but applies those development tools to create a unique and specific experience supporting the design objectives of the supercloud.

Supercloud services can be infrastructure-related, application services, data services, security services, users services, etc., designed and packaged to bring unique value to customers… again that the hyperscalers are not delivering across clouds or on-premises.

Finally, these attributes are highly automated where possible. Superclouds take a page from hyperscalers in terms of minimizing human intervention wherever possible, applying automation to the specific problem they’re solving.

Supercloud sets out to build incremental value across clouds and above hyperscale capex that goes beyond cloud compatibility within each cloud. So if you want to call it multicloud 2.0, that’s fine.

¯\_(ツ)_/¯

NIST managed to define IaaS, PaaS, and SaaS in two or three sentences apiece. I await the similarly succinct definition of “supercloud”/”multicloud 2.0”/whatever term we are throwing around this week. But until that happens, in the absence of a clear definition, “supercloud” is not a thing.

EVERYONE’S A SUPERCLOUD

One advantage of a precise definition for a concept is you can use that definition to discern which things are and are not instances of that concept.

In the absence of that much-coveted crisp definition, the “supercloud” scribblers have gone with the “we know it when we see it” approach, beloved of Supreme Court justices and the semantically bereft. They find “(s)upercloud is everywhere you look”. We truly live in super times:

“Basically, thanks to the cloud, every company in every industry now has the opportunity to build their own supercloud.”

SaaS as well is a subset of supercloud.

Well, most companies that consider themselves cloud players will, we believe, be building superclouds.

We’ve added some of those nontraditional industry players we see building superclouds such as Capital One, Goldman Sachs and Walmart

We’ve talked a lot about Snowflake Inc.’s Data Cloud as an example of supercloud, as well as the momentum of Databricks Inc. (not shown above). VMware Inc. is clearly going after cross-cloud services. Basically every large company we see is either pursuing supercloud initiatives or thinking about it. Dell Technologies Inc., for example, showed Project Alpine at Dell Technologies World – that’s a supercloud in development. Snowflake introducing a new app dev capability based on its SuperPaaS (our term, of course, it doesn’t use the phrase), MongoDB Inc., Couchbase Inc., Nutanix Inc., Veeam Software, CrowdStrike Holdings Inc., Okta Inc. and Zscaler Inc. Even the likes of Cisco Systems Inc. and Hewlett Packard Enterprise Co., in our view, will be building superclouds.

And we’re seeing emerging companies like Aviatrix Systems Inc. (network performance), Starburst Data Inc. (self-service analytics for distributed data), Clumio Inc. (data protection – not supercloud today but working on it) and others building versions of superclouds that solve a specific problem for their customers. And we’ve spoken to independent software vendors such as Adobe Systems Inc., Automatic Data Processing LLC and UiPath Inc., which are all looking at new ways to go beyond the SaaS model and add value within cloud ecosystems, in particular building data services that are unique to their value proposition and will run across clouds.

So yeah – pretty much every tech vendor with any size or momentum and new industry players are coming out of hiding and competing… building superclouds.

I took the liberty of bolding the host of disparate “supercloud” instances above. I also resisted the urge to point out certain inconsistencies with the “salient attributes”.

“Superclouds” also support a wide range of “workloads & services”:

Analytics. Snowflake is the furthest along with its data cloud in our view. It’s a supercloud optimized for data sharing, governance, query performance, security, ecosystem enablement and ultimately monetization. Snowflake is now bringing in new data types and open-source tooling and it ticks the attribute boxes on supercloud we laid out earlier.

Converged databases. Running transaction and analytics workloads. Take a look at what Couchbase is doing with Capella and how it’s enabling stretching the cloud to the edge with Arm-based platforms and optimizing for low latency across clouds and out to the edge.

Document database workloads. Look at MongoDB – a developer-friendly platform that with Atlas is moving to a supercloud model running document databases very efficiently. Accommodating analytic workloads and creating a common developer experience across clouds.

Data science workloads. For example, Databricks is bringing a common experience for data scientists and data engineers driving machine intelligence into applications and fixing the broken data lake with the emergence of the lakehouse.

General-purpose workloads. For example, VMware’s domain. Very clearly there’s a need to create a common operating environment across clouds and on-prem and out to the edge and VMware is hard at work on that — managing and moving workloads, balancing workloads and being able to recover very quickly across clouds.

Network routing. This is the primary focus of Aviatrix, building what we consider a supercloud and optimizing network performance and automating security across clouds.

Industry-specific workloads. For example, Capital One announcing its cost optimization platform for Snowflake – piggybacking on Snowflake’s supercloud. We believe it’s going to test that concept outside its own organization and expand across other clouds as Snowflake grows its business beyond AWS. Walmart Inc. is working with Microsoft to create an on-prem to Azure experience – yes, that counts. We’ve written about what Goldman is doing and you can bet dollars to donuts that Oracle Corp. will be building a supercloud in healthcare with its Cerner acquisition.

So we’re back to “supercloud” as a participation trophy. Doing something on the cloud? Available to external customers/developers? Congratulations, you’re probably a “supercloud”. Or will be soon.

When everything is “supercloud”, nothing is. And that makes it very hard for “supercloud” to become a thing.

Making club “supercloud” membership exceptionally inclusive makes sense when you realize it isn’t an architecture or a category, but a media construct. (I was invited to this event but declined to participate, having better things to do than try to make the “supercloud” a thing. At minimum, I’d be swimming upstream). The broader the audience, the more prospects there are for events and sponsorships. And nothing livens up panel discussions like the lack of common definitions.

PAAS. YOU’VE DISCOVERED PAAS.

New concepts need to be understood in relationship to existing categories and concepts, of which we are blessed with many. That is the essence of positioning (the most powerful of marketing levers). “Supercloud” is an emerging case study of how not to do positioning.

Where does “supercloud” end (or even start? 😉) and other things begin? AWS, Google Cloud, and Microsoft Azure seem to be the only things in the cloud era that are not super.

PaaS is the most interesting category to triangulate “supercloud” against as there is significant overlap. Many of my dozens and dozens of questions were about the “supercloud” relationship to PaaS. “Supercloud” has even begotten its own “SuperPaaS”, which may or may not be required, but that is unclear due to the characteristic level of imprecision. Again, we’ll go try to parse the latest texts:

A supercloud abstracts the underlying and siloed primitives of the native PaaS layer from the hyperscale cloud and using its own specific platform-as-a-service tooling, creates a common experience across clouds for developers and users. In other words, the superPaaS ensures that the developer and user experience is identical, irrespective of which cloud or location is running the workload.

That was true for OG PaaSes Cloud Foundry and OpenShift a decade ago.

A supercloud comprises a superPaaS capability that allows ecosystem partners to add incremental value on top of the supercloud platform to fill gaps, accelerate features and innovate. A superPaaS can use open tooling but applies those development tools to create a unique and specific experience supporting the design objectives of the supercloud.

Ecosystem extensibility is hardly a new thing. Even those OG PaaSes had it.

Importantly, the sets of services are designed to support the supercloud’s objectives – e.g., data sharing or data protection or storage and retrieval or cost optimization or ultra-low latency, etc. In other words, the services offered are specific to that supercloud and will vary by each offering.

This may be saying some of these services are not full application execution environments and just offer a single middleware service, i.e. are “specific”?

OpenShift, for example, can be used to construct a superPaaS but in and of itself isn’t a superPaaS. It’s generic.

“Generic”? Usually it is me making fun of IBM. But that is pretty cold after they paid $34 billion for OpenShift.

The point is that a supercloud and its inherent superPaaS will be optimized to solve specific problems such as low latency for distributed databases or fast backup and recovery and ransomware protection — highly specific use cases that the supercloud is designed to solve for.

If only we had thought to optimize or tackle highly specific use cases back in the OG PaaS days…

Look at MongoDB – a developer-friendly platform that with Atlas is moving to a supercloud model running document databases very efficiently.

I’d argue that with Atlas, MongoDB is moving to the PaaS model and becoming a more generalized application platform.

My initial statement on the “supercloud” and PaaS was:

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).

The emergence of middleware for the cloud is not a surprise. Like all middleware, it strives for reach (multi-cloud) and to assemble an ecosystem around the platform. And you don’t even have to be middleware to aspire to be a platform (e.g. Capital One, Goldman Sachs, Walmart). Any software can run the platform playbook, regardless of where you are in the stack. Because it is a feature flag, it is hard to argue being a platform is a super new category.

STILL NOT A THING

“Supercloud” still lacks a precise definition. It is still difficult to identify what is and isn’t “supercloud” (especially isn’t based on the latest tract). And we still don’t know how “supercloud” relates to and intersects with the categories and taxonomies that we use to comprehend the cloud.

There is an ultimate Darwinian test for “supercloud” becoming a thing or not. And it isn’t how much hot air gets expended on the topic by the chattering classes (I plead nolo contendere!). The real test is when will companies proudly identify themselves as a “supercloud” right on their home page. Does the concept have enough value and specificity that companies will use it to position themselves to customers? We’re still waiting for that first pioneer.