Supercloud? Metacloud? The race is on to name the emerging layer of abstraction and automation that will remove the complexity of multicloud.
A few years ago, I pointed out that multicloud is really not about the public clouds it’s built on. What I did not do is attempt to name it in an effort to claim myself as the creator of a new buzzword.
Not that I won’t pat myself on the back in all my narcissistic glory. Indeed, I’ve created buzzwords that turned out to be billion-dollar industries. However, I also know that when you give something a name it allows others to define it, which brings its usefulness way down. You end up defining a concept before it’s had a chance to evolve with use. Certainly, architecture patterns, such as the one that’s emerging above multiclouds, are something you don’t want to limit just yet.
Cloud watchers are seeing the emergence of a technology layer that sits above the collection of public clouds; this is really what multicloud is becoming. This layer of application development, operations, observability, security, governance, and other things exists above the public cloud providers that are bundled together to make a “multicloud.”
Terms that are beginning to emerge, such as “supercloud,” “distributed cloud,” “metacloud” (my vote), and “abstract cloud.” Even the term “cloud native” is up for debate. To be fair to the buzzword makers, they all define the concept a bit differently, and I know the wrath of defining a buzzword a bit differently than others do. The common pattern seems to be a collection of public clouds and sometimes edge-based systems that work together for some greater purpose.
The metacloud concept will be the single focus for the next 5 to 10 years as we begin to put public clouds to work. Having a collection of cloud services managed with abstraction and automation is much more valuable than attempting to leverage each public cloud provider on its terms rather than yours.
We want to leverage public cloud providers through abstract interfaces to access specific services, such as storage, compute, artificial intelligence, data, etc., and we want to support a layer of cloud-spanning technology that allows us to use those services more effectively. A metacloud removes the complexity that multicloud brings these days. Also, scaling operations to support multicloud would not be cost-effective without this cross-cloud layer of technology.
Thus, we’ll only have a single layer of security, governance, operations, and even application development and deployment. This is really what a multicloud should become. If we attempt to build more silos using proprietary tools that only work within a single cloud, we’ll need many of them. We’re just building more complexity that will end up making multicloud more of a liability than an asset.
I really don’t care what we call it, and I really don’t care if I put my own buzzword into the mix. However, this does not change the fact that metacloud is perhaps the most important architectural evolution occurring right now, and we need to get this right out of the gate. If we do that, who cares what it is named.
