Tl;dr: the Supercloud Uncertainty Principle dictates that as more effort is expended to define “supercloud”, the less sense it makes.
Reader Relevance: this is “super” niche.
The “supercloud” svengalis are very proud to have an explicit definition for their brainchild (perhaps my goading about this egregious omission for nine months provided motivation). Brace yourself:
Supercloud is an emerging computing architecture that comprises a set of services abstracted from the underlying primitives of hyperscale clouds (e.g., compute, storage, networking, security, and other native resources) to create a global system spanning more than one cloud.
Before we parse that definition, some kudos are in order. There is actually a sentence that begins “Supercloud is…” without the traditional hesitancy or equivocation (except for “emerging”, but we’ll let that go, for now). Hurrah! And the document has a most orderly structure! Bravo!
But, alas, this “v3 definition” is not even remotely the breakthrough required to make “supercloud” a thing. It barely differs from the previous wording modulo the improved formatting (this latest small delta deletes “which are” and changes “tooling” to “resources”).
The definition remains vague and unhelpful in identifying what is and isn’t “supercloud”. “A set of services” as the essential core of “supercloud” is a complete punt (for soccer fans, that means the dereliction of aspiring thought leadership duty by neglecting to speak in terms of distinct and relevant capabilities, and instead wave one’s hands while humming “services”). By this definition SnapChat, and anything that touches more than one cloud, could be “super”.
Which brings us back to:
And if “supercloud” really is a “computing architecture”, it is an architecture-less architecture, as none has been illustrated. The author admits he is unqualified to define an architecture.
Basically we are told “supercloud” is multi-cloud stuff, a concept for which we already have a term, yet somehow better and newer and cooler! They still have not managed to precisely carve out and describe some particular set of multi-cloud solutions that warrants its own subclass.
PaaS. You’ve (still just) discovered PaaS.
Change just a few words (bolded) of the latest definition and it passes for PaaS:
Platform-as-a-Service is a computing architecture that comprises a set of services abstracted from the underlying primitives of hyperscale clouds (e.g., compute, storage, networking, security, and other native resources) and can span more than one cloud.
The fact that one of the three “essential properties” of “supercloud” is a “purpose-built SuperPaaS layer” makes this point even more explicitly than I do (but I will belabor that more below).
The accompanying FAQ attempts to clarify the distinction between “plain Old PaaS” and SuperPaaS with some (unsatisfying) word salad:
Isn’t plain Old PaaS already supercloud?
Supercloud and its corresponding superPaaS layer gives the freedom to store, process, manage, secure and connect islands of data along a continuum with a common developer and operational experience across clouds. This is different from traditional PaaS offerings from cloud providers.
The “supercloud” spawners want to contrast their offspring to hypercloud PaaS services (presumably because they are not multi-cloud, but even that isn’t true), but continue to ignore PaaS offerings that have spanned multiple clouds for over a decade (e.g. PaaS OGs Cloud Foundry, OpenShift).
But the real rhetorical highpoint of the FAQ is the use of “freedom”. I think we all know where this is going. Forget coherence or precision, this is about <cue 🎶patriotic music🎶> freedom! Who can quibble about persnickety details when our most cherished freedoms are at stake? Freedom is slavery. War is peace. Ignorance is strength. “Supercloud” is a thing.
Realizing Mimetic Desires Via Copy and Paste
Perhaps in response to my previous comment that “NIST managed to define IaaS, PaaS, and SaaS in two or three sentences apiece. I await the similarly succinct definition of “supercloud””, the “supercloud” industrial complex, while still struggling with the succinct definition ask, have borrowed NIST’s taxonomy wholesale, and are determined to make it fit, even if it requires some awkward jamming.
The new-and-improved “supercloud” definition comes with a triumvirate of Essential Properties, Deployment Models and Service Models, each in turn, like Gaul, having three parts.
To begin with the Essential Properties (deftly laundering NIST’s Essential Characteristics):
Runs a set of services across more than one cloud. A supercloud consumer can access service elements that run on more than one cloud without requiring specific expertise and knowledge of the underlying cloud infrastructure.
“Supercloud” it seems is a synonym for multi-cloud. We can do the same PaaS substitution on this property as well, while “service elements” are even vaguer than “a set of services”. Is there a periodic table of “service elements”? (If so, I will argue “supercloud” must sit in the column of inert gases). Is it required to run on more than one cloud or is that just an option?
Purpose-built SuperPaaS Layer. A capability that abstracts the underlying primitives of the native PaaS layer within each cloud and creates a common experience across clouds for developers, operators, users and/or ecosystem partners. In addition, the superPaaS layer acts as a cloud interpreter tailored explicitly for the supercloud’s objectives.
“Supercloud” is totally distinct from PaaS, yet requires its own native PaaS layer? Not confusing (or coherent) in the slightest…
Which “supercloud” poster children abstract native PaaS layers (as opposed to sitting on IaaS primitives)? Are there any examples? Why is this important? Or is this further proof “supercloud” is just a GPT-3 generated spoof that lacks internal consistency?
Metadata Intelligence. A metadata capability optimized for specific supercloud services runs workloads efficiently across federated cloud platforms. For example, the supercloud has an awareness of cost, latency, bandwidth, governance, security, data sovereignty, or other attributes in each supported cloud platform and explicitly serves the intended purpose of the supercloud.
This is just a weird hobbyhorse. What are the examples of this property in our nascent (and admittedly ever-changing) set of emerging “superclouds”?
The Deployment Models:
Single Cloud Instantiation. A control plane runs its service on one cloud but supports data plane interactions with more than one other cloud. An example is a Kubernetes cluster management service that runs on one cloud but can deploy and manage clusters on other clouds.
So a Kubernetes control plane is a “supercloud”? (please take a moment to scroll up to view the “everyone’s a supercloud!” meme again). How do you say “super” in Greek? We need a Godwin’s Law equivalent for Kubernetes: the longer a cloud discussion goes on, the more likely Kubernetes will subsume the topic at hand.
Multi-cloud, Multi-region Instantiation. A full stack of services is instantiated on individual clouds and regions. A unified interface supports interactions across more than one cloud. An example is a set of data protection services (e.g., backup, restore, archive, data analytics, data management) installed in multiple clouds and cloud regions and controlled through a unified platform interface. Cohesity is an example of this deployment model.
Global Instantiation. A single global instantiation of services spans multiple cloud provider regions. An example is a data platform that enables governed and secure data sharing across clouds and regions. Snowflake and Oracle Database Service for Microsoft Azure are examples.
Lastly, we have Service Models, where they rewrite the NIST prose and not for the better. But blind pattern matching is kind of the core of the “supercloud” game. “Superclouds” not only span multiple clouds, but evidently also can exist at the IaaS, PaaS and/or SaaS layers (unclear if they can span these layers simultaneously, offering a form of “super” quantum entanglement), making this a serious combinatorial land grab on the 3D chess board:
Infrastructure as a Service (IaaS). The ability to provision a service including compute, storage, networking, security or other computing resources across multiple clouds and on which workloads can be provisioned and managed without knowledge of the underlying cloud infrastructure. An example is a data storage service with a single interface that spans multiple clouds and cloud regions. NetApp’s Cloud Volumes service is such an example.
Platform as a Service (PaaS). DevOps professionals are able to create and deploy applications using programming languages, libraries, services, and tools supported by the cloud provider. The developer and operational experience is identical across clouds with no need to manage the underlying compute, storage, network and security controls of the cloud provider. VMware Cloud Foundation is an example.
If you wanted to demonstrate the “supercloud” swamis struggle to understand PaaS, even as they try to rebrand it, this paragraph would be the prosecution’s exhibit A. In the “supercloud” alternative reality, DevOps professionals create apps at the PaaS layer? And presumably they mean Cloud Foundry, which is a PaaS, not Cloud Foundation, which isn’t. Details, details.
Software as a Service (SaaS). Users access applications from a Web browser or mobile application that invokes services running in more than one cloud. The user has no knowledge or control over the underlying cloud infrastructure. An example is an ERP system that runs on a private cloud infrastructure and invokes analytics and machine learning services from a public cloud provider in a seamless interaction with no user context switching. SAP HANA Cloud is such an example.
SnapChat is “super” too (go visit that meme above yet again).
Still Not a Thing
To reiterate yet again my three “super” questions:
- What is the definition of “supercloud”? The latest submission is still not useful, and they have not managed to reverse engineer a precise definition from the arbitrary collection of solutions they are attempting to characterize. Random middleware pattern matching does not constitute an architecture.
- What does and doesn’t qualify as “supercloud”? This is an important test and we have seen a constantly rotating set of “supercloud” poster children (remember when Goldman Sachs was “supercool”?). Beyond basic set theory, will we ever see a vendor proudly describe themselves as a “supercloud” on their home page or a customer put out an RFP for a “supercloud”? That is the ultimate validation (or repudiation) of the concept.
- How does “supercloud” relate to existing categories, nomenclature, and taxonomies? When you roll in a decade late, you don’t get to ignore what came before you by merely dismissing and disparaging it as “plain old”. #PaaS.
“Supercloud” is an Internet media attention gambit. Not an architecture. Not a category. Not a customer problem. Not a useful concept.
I expect the “super” response to this latest missive will be to once again ignore all the specific questions and comments and implore the “community” to somehow redeem this random term.
