Superclouds and Portfolio Thinking
What is a Supercloud?
Just as organizations were getting a handle on multi-cloud, the tech industry has moved another level higher in the stack.
“Superclouds” represent the next stage of abstraction in the cloud adoption game — a unified, comprehensive cloud environment that marries multiple disparate cloud and edge resources into one. Where multi-cloud is operating across more than one provider or using more than one provider’s managed services, supercloud brings them together into a seamless whole and exposes a single point of interaction for users.
Supercloud users don’t need to know the particulars of the underlying infrastructure, they simply deploy and the supercloud handles all the fiddly bits behind the scenes.
“There is a recognition that all businesses are or will eventually become multi-cloud. And there is a recognition that we need an architectural approach to delivering the right types of consistency and optionality across that multiple clouds.”
- Kit Colbert, CTO of VMware
Of course, this is all much easier said than done. While in theory a supercloud is the simple, accessible answer to the fragmented nightmare of multi-cloud, in practice it’s a whole jumble of tooling and frameworks that no one can quite agree on. Supercloud also variously includes edge, bare metal, and on prem resources and no two “superclouds” look alike, making it even more difficult to say with any degree of certainty what is or isn’t a supercloud.
We won’t pretend to be the ultimate authority on superclouds (or metaclouds, or multi-cloud services, or whatever terminology the industry finally settles on) but for the sake of this article we’re going to establish the basics of what a supercloud does rather than how it does those things.
What A Supercloud Does
- Operates in a layer above the clouds
- Removes vendor lock-in
- Seamlessly combines multiple cloud providers
- Folds in non-cloud resources including edge, bare metal, and on prem servers
- Removes the burden of infrastructure management from app-level developers
- Provides a single point of access and control for administrators
The goal of a supercloud is to provide a common service layer that’s easy to use and removed from the underlying mix of infrastructure. Anything deployed on a supercloud should be able to move across that supercloud in a way that optimizes for business-level goals like end user performance or cost without requiring manual interference. This implies some number of included services (like routing, autoscaling, and load balancing) but we’re going to stop short of naming them as requirements.
Superclouds and Portfolio Thinking
While the details of any given “supercloud” or supercloud-style solution may differ, the trend speaks to the same underlying worldview.
Clouds, edge, bare metal…they’re all resources, resources that need to be optimized and managed just like any other resource. Few enterprise applications rely on a single resource, meaning many organizations are relying on a mix of infrastructure. That mix, which may have started as a haphazard result of acquisitions, has become more deliberate with time.
“[Organizations] want multicloud by design, not by default”
- Mindy Cancila, VP of Corporate Strategy at Dell
The ways we conceptualize and manage infrastructure are more sophisticated than ever before. Due to advances in cloud services, orchestration, DevOps, platform engineering, and tooling, the sky is the limit. Moving across clouds is possible. Marrying different managed services is possible. Infrastructure is not inert.
Now, a company’s infrastructure mix can do more than just deliver applications. It can be optimized and optimize itself for cost, performance, and availability. In short, an organization’s infrastructure mix can look and act like an investment portfolio.
Diversification, Risk, and Performance
When cloud, edge, and bare metal resources are treated as utilities, balancing the mix looks like investment portfolio management. It sounds pat, but it’s true: when you can use resources interchangeably, the decisions you make with those resources become more strategic.
At Seaplane we consistently return to basic mean-variance analysis when building our network. Our view of the cloud (and edge and bare metal) is holistic. We don’t look at just one resource’s risk and return, we look at the overall risk and return of our entire resource portfolio for ourselves and our customers.
This same logic is present in concepts like supercloud and multi-CDN deployment. When you have the opportunity to diversify, you have the opportunity to optimize. Some resources are more or less expensive, and more or less available, in different contexts. Optimizing for performance and availability per dollar invested is not only possible, it’s just good business!
A diverse portfolio minimizes risk and protects against individual losses. If one stock tanks you have more. If one cloud provider goes down, you have more. It’s why we support every major public cloud, and why multi-cloud is “a thing”: turbulence is inevitable and everyone wants to minimize risk where possible.
Building Supercloud Style Solutions
So, assuming we buy into the idea of a portfolio approach to infrastructure management, we need to discuss implementation.
Given the intense ambiguity of our supercloud explainer, this section may come as a shock. It’s hard to prescribe a solution when the very definition of that solution is so fluid, but examples of superclouds abound. Infrastructure pain is common, especially for the 81% of organizations that are currently multi-cloud, so it follows that solutions are just as common. The overlap between superclouds and other emerging solutions is stark, especially when we strip out the particulars of how they achieve their common goals.
We’re not saying the concepts below are all superclouds by any other name, but we are saying they share the same DNA.
Platform Engineering and Internal Developer Platforms
Seaplane is full of platform engineering fans. We write about it, we host events about it, we build communities about it — so of course we need to talk about how it connects into the burgeoning supercloud movement.
Platform engineering (the process) exists to produce and maintain internal developer platforms or “IDPs” (the product). The idea is to make DevOps self-service, abstract away infrastructure orchestration and management for app-level developers, and allow for configurability on the organizational, rather than individual, level. Many of the same things a supercloud seeks to accomplish.
Because most organizations are multi-cloud already, their IDPs check the “combines multiple providers” box, technically elevating them to the status of “supercloud.” However the intensely customizable nature of an IDP stops us from calling every IDP a supercloud as a rule. The point of a platform team is to solve the last mile problem for developers, the final bit of wiring and customization that needs to happen to make disparate managed services usable by developers, and not all organizations are multi-cloud. Meaning, because IDPs are so custom and not all organizations are multi-cloud, not all IDPs are superclouds.
The IDPs of the future will inevitably fall under the supercloud umbrella due to multi-cloud adoption (or maybe vice versa) but for now they remain separate but linked concepts.
Global Control Planes and Developer Control Planes
Global Control Planes and Developer Control Planes typically function as part of an organization’s IDP, covering cloud mobility and resource optimization. It’s a bit of a squares and rectangles situation — IDPs (generally) include a global control plane in some form, but a global control plane doesn’t necessarily include all the customized functionalities of an IDP. There is a lot of overlap, and the boundaries are pretty loose, but we’ll try to draw some lines for you.
The main difference between an IDP and a global control plane is one of scope. An IDP is meant to be a one stop self-service shop for an organization’s developers, and will often include custom tooling built and wired together by that organization’s platform engineering team.
A global control plane usually works right out of the box and is more focused on simplifying infrastructure management, acting as a layer above cloud, edge, and bare metal resources. A global control plane turns these disparate resources into a seamless continuum, allowing developers to deploy globally without having to manually provision or worry about infrastructure. Some critical services may be folded into a global control plane (Seaplane’s Managed Global Compute, for example, folds in load balancing, autoscaling, and automatic rescheduling) and they typically have high level controls for managing data localization and compliance.
We sometimes use the terms “IDP” and “Developer Control Plane” interchangeably, while treating “Global Control Plane” as an adjacent but separate concept. The jargon is constantly evolving, so it’s difficult to say if this will always remain the case.
Industry Cloud Platforms
The industry cloud platform (ICP) is another new category emerging to cope with the perils of diverse infrastructure, but this time the emphasis is on solving cloud pain for entire industry verticals rather than individual organizations. In a way, these are like IDPs but with less surface area and more standardization.
“In effect, industry cloud platforms turn a cloud platform into a business platform, enabling an existing technology innovation tool to also serve as a business innovation tool…They do so — not as predefined, one-off, vertical SaaS solutions — but rather as modular, composable platforms supported by a catalog of industry-specific packaged business capabilities.”
- Gregor Petri, VP Analyst at Gartner
The focus on expressing business logic is a hallmark of the ICP, though arguably an IDP seeks to do something similar as an extension of its other functions. All told, ICPs feel more like carving out space in the larger IDP market than as a strictly unique or separate concept.
Metaclouds
“Metacloud” is usually another word for “supercloud.” The industry’s multi-cloud vocabulary is still so new that it’s not uncommon for numerous terms to spring up around the same basic concepts.
“The metacloud is really a cross-cloud service layer that exists so we won’t have to define specific technologies for each public cloud that’s part of our multicloud.”
- David Linthicum, Chief Cloud Strategy Officer at Deloitte
Metacloud may refer specifically to the points of intersection between clouds, whereas supercloud is more about the sum total of all the clouds together, but that’s splitting hairs. In truth, there is no consensus about the difference (if any) between metaclouds and superclouds.
Multi-CDN Deployments
A multi-CDN deployment is basically multi-cloud but for CDNs. There’s a great NS1 article that dives into the details, but as a quick summary: a multi-CDN deployment is what it sounds like — deploying across multiple CDNs for optimization purposes. Combining specialized CDNs improves functionality, while having more than one CDN improves global performance and availability. It’s all the same benefits as multi-cloud but in the context of content rather than whole applications.
Adopting Supercloud Solutions
Applying portfolio thinking to infrastructure is free, but actually adopting solutions that enable the practical application of that mindset is not.
Whether your team needs a platform engineering team, or a multi-CDN, or any other supercloud style solution really depends on your specific needs and the resources at your disposal. We encourage every team to weigh all their options and consider everything from the team’s current cloud skill level to total cost of ownership.
Regardless of how your choose to implement “supercloud” style solutions, you’ll be moving in the right direction. The paradigm is shifting. Instead of working for your infrastructure, with the portfolio approach your infrastructure can start working for you.
