Tl:dr: “supercloud” is still not a thing that you could pick out of a police lineup
A note to readers regarding relevance: this post is extremely niche, is most applicable for bored cloud people with an interest in alternative universe ontologies, and who are probably iced in and/or avoiding a pandemic surge (or both, like the author).
In a huge surprise holiday drop, we have 35 new stanzas of “supercloud” scripture to scrutinize. This is an enormous expansion of the “supercloud” canon. They’re now minting elucidation with NFT-esque abandon (though not necessarily with the same immutability)!
My previous questions regarding “supercloud” were simple: What is it? What is actually new? How does it relate to our existing world?
Now I have more questions. Lets go to the cloudestrator:
Over the past several years we’ve been observing a trend whereby platform providers envision capabilities that span multiple clouds delivering an identical developer and user experience. Until recently this vision has been aspirational but we’re beginning to see examples of real-world implementations taking shape.
Wouldn’t this describe both Cloud Foundry and OpenShift, which have been around for over a decade. What makes “supercloud” a new phenomenon?
If “we’re beginning to see examples of real-world implementations taking shape”, why not include even a single example of a “supercloud” in the latest and longest illumination? Useful terminology and unequivocal examples should be inseparable.
We used the term “supercloud” to describe this capability to convey the concept. We explicitly want to go beyond cloud compatibility – i.e. a stack that runs on many different clouds, including on-prem. Rather we wanted to define a capability that spans multiple clouds with a singular experience that adds value above and beyond anything customers can receive from a single cloud.
My comment “PaaS. You’ve invented PaaS” still seems apt. Why doesn’t PaaS “convey this concept”?
We’ve been challenged to better define supercloud and take a run at tightening up the definition here:
We’re all better when challenged…
What is a Supercloud?
Supercloud describes an architecture that taps the underlying services & primitives of hyperscale and other clouds to deliver additional value above and beyond what’s available from a single public cloud provider. A supercloud delivers capabilities through software, consumed as services, and must span multiple cloud platforms, inclusive of on-prem clouds and edge installations.
The first sentence under “What is a Supercloud”, despite following those big expectations, is frustratingly fuzzy: “…describes an architecture that taps…”. Taps? That first sentence still could describe any app running in the cloud. The second sentence makes it multi-cloud. Is “supercloud” synonymous with “multi-cloud”? Is a “supercloud” anything multi-cloud? The multi-cloud term – like it or not – exists: what does “supercloud” add?
Perhaps I have too exalted a standard for the word, but what is meant by “architecture”? Is ”supercloud” a specific, singular architecture or is any multi-cloud architecture a “supercloud”? Should “supercloud architecture” be singular or plural? Where is the architectural diagram for the “supercloud” architecture? You can’t have an architecture without an architectural diagram. You just can’t. It’s mandatory.
A supercloud is an abstraction layer that can hide the underlying complexity of various clouds but at the same time is capable of leveraging these capabilities to add value on top of native cloud primitives. A supercloud may allow developers to tap primitives and native APIs if desired via the PaaS layer. However, the logical developer output of the PaaS layer in a supercloud is functionally identical across all supported clouds.
Finally, a sentence that starts with “a supercloud is…”. But “abstraction layer” does not exactly quicken our hearts or minds. After all the suspense, “supercloud” is just multi-cloud middleware? Are “superclouds” services and/or bits? If “supercloud” is just a software abstraction layer, why is it useful or clarifying to call it a cloud? Does “supercloud” have any other mandatory attributes beyond being multi-cloud?
In essence, we believe over time, all superclouds will include such a PaaS layer that we refer to as “SuperPaaS,” allowing developers to write once and publish anywhere. Container orchestration platforms are logical building blocks for superPaaS. However, the superPaaS will require additional capabilities to handle recovery and other cross-cloud functionality across disparate cloud platforms.
The pivot to PaaS is progressing! How does a “supercloud” differ from PaaS? What makes “superPaaS” more super than plain old PaaS? Does the new term “superPaaS” replace “supercloud”? Is “superPaaS” synonymous with “supercloud”, or a subset? Are there now two members of the Super Ambiguous Pantheon? (Too bad SAP is already taken). Do we really need more “super” lingo? Presumably “superSaaS” comes next? Dibs on the superStack™? Was the S in NIST for “super”?
Does a “supercloud” have to have a “superPaaS”? What distinguishes a “supercloud” from a “superPaaS”? How should we think about “superclouds” that have not yet added “superPaaS”?
Who builds superclouds: IT departments and/or ISVs? The “write once and publish anywhere” developers are in IT and/or ISVs? It can be helpful to specify the user segments for new concepts.
Wikibon regards this as a significant business opportunity for software enterprises that don’t operate a hyperscale cloud platform.
Why is this not also a significant business opportunity for the hyperscale-clouds? They do this kind of stuff today. They are all investing in one control plane to rule them all, and extending their cloud services to the edge. And just because AWS hasn’t shown it is particularly adept at PaaS services doesn’t mean the others aren’t.
A supercloud must include multiple clouds and at least one hyperscale cloud– otherwise, it’s not scalable to the degree that it would warrant a moniker of “super.”
The attributes and benefits of supercloud are:
* Access to all/most cloud platforms and applicable primitives, which over time will increase in number and become more specialized.
Isn’t this the middleware equivalent of land war in Asia, except one where the surface area of Asia is constantly expanding? AWS has 200+ services…
* All cloud platforms conform to a set of common standards that are written and tested independently of other cloud platforms and are “air-gapped” from each other. These standards are utilized by developers where the experience across clouds is identical. Users don’t know or care where the code runs.
This sounds like a utopian dream I’ve heard before (I love how it is just casually slipped in as a bullet item). Why is this time different? Who among us will be chosen to define the “common standards”? Is “superPOSIX” a better name?
* Metadata that understands locality and can optimize or avoid data movement (including edge workloads).
* Reduced cost (i.e. the ability to choose a local or specialized cloud that best meets cost, performance, and/or governance requirements).
* Improved security and value add – (e.g. can avoid cloud resources with security issues & restart with data backed up on other clouds…avoids too much dependence on a single cloud and cloud providers knowing too much about your data, code, customers, and business volume).
Let the record show I exhibited great restraint on this section. But, yay, locality metadata!
This leads to:
* Improved automation across clouds.
* Improved application functionality, especially for real-time applications.
* Improved availability (e.g., avoids total shutdown of a single cloud platform).
* Be a better international player by deploying on local cloud vendor(s).
* The air gap between clouds with multiple architectures reduces the risk/scope of cyber attacks.
* Reduced impact of single telecom failures.
* Allows access to unique clouds via APIs – (e.g. mainframe clouds, Oracle clouds) to avoid conversion of existing mission-critical systems.
* Reduced budgets and better protection from opportunistic cloud price hikes.
* Reduced risk of a cloud platform appropriating your data, code, or customers to provide their own service.
What are typical workloads for “superclouds”? What is being automated? What is “application functionality” and what makes it new and improved? Does a ”supercloud” have to be an execution environment for apps? Do “superclouds” really route around cloud or network outages? Does this happen automatically? How does this work? What is a software “air gap”? (Are you hardware people, is that why this discussion is so exasperating?) Do customers really live in fear of “opportunistic cloud price hikes” but not opportunistic “supercloud” price hikes? Etc, etc.
And WTF is a “mainframe cloud”? Is the “supercloud” a mainframe thing? That actually makes more sense than any of this so far.
In summary, we believe that significant opportunities exist for companies to digitally transform leveraging hyperscale infrastructure. These opportunities are not only open to traditional technology hardware and software companies but rather opportunistic firms across all industries can provide superclouds for their respective domains.
Yay, digital transformation! When “supercloud” airport ads?
Supercloud or Not Supercloud: The Game Show
The superposition of Schrödinger’s “supercloud” is super frustrating. Terminology is much more useful when we can precisely discern what is a thing and what is not a thing. So let’s play “Supercloud or Not Supercloud”, where we try to apply “supercloud” theory to actual things in our universe.
Specifically, which of these are and aren’t superclouds, and why:
Bonus question: when (and why) did Snowflake ascend to “supercloud” status?
Bonus question: to what “varying degrees” are each of these hardware vendors building “superclouds”?
(here is the previous reference from the “supercloud” canon for convenience)
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.
Goldman Sachs Financial Cloud for Data?
Bonus question: why the Goldman Sachs Exemption to allow for single cloud “superclouds”??
(here is the previous reference from the “supercloud” canon for convenience)
And we’re seeing new examples such as Goldman Sachs Group Inc.’s financial cloud running on AWS. So a supercloud to us is not an application or SaaS running on a single cloud, rather it’s an abstracted service that either spans multiple clouds or, in the case of Goldman Sachs, runs on a single cloud as a portfolio of data, tools, software and services made accessible as a service that floats on top of a single or multiple clouds.
AWS EKS Anywhere/Azure Arc/Google Anthos?
AWS Outposts/AzureStack/(whatever the comparable GCP thing is called)?
The CNCF “stack”/logo collection?
Bonus question: compare and contrast the CNCF and “supercloud” concepts of “architecture”?
Bonus bonus question: why hasn’t CNCF done an NFT collection of its menagerie yet?
If you enjoyed this game, qualifiers for the live action show are coming soon to your city!
PaaS is Back!
So PaaS is at long last having its day. Maybe developers are finally realizing futzing with instances is less fun than it seems. Multi-cloud PaaS is a thing (and the whole multi-cloud discussion is far more interesting and relevant at the PaaS layer than the IaaS layer). Multi-cloud middleware could be a thing (albeit a pretty tedious thing — not even CNCF markets it that way). If “supercloud” is one or both of those, why do we need a new term when we have widely understood existing terms that can combined to convey with some precision what is going on? Or maybe “supercloud” is something altogether different and we should await further clarification?. But if the “supercloud” campaign is going to continue, we need a precise definition, examples of what does and does not quality, and triangulations with existing taxonomies.
Otherwise it is just supercloudifragilisticexpialidocious!