By Nathan Bennett
Cloud Practice Lead
.In this three-part future-feature journey, we’ll look at the connections between “cloud,” “multi-cloud,” and even more nebulous terms, like “super-cloud.” We’ll start at the basics, talk first about what is meant by “cloud,” and then build on that inquiry so we can better understand the new terms and determine whether they are ‘new’ at all.
We started decrypting “cloud” by its context and criteria in Part 1 of my blog. Then we built on that premise with “multi-cloud” and its multiple cloud solutions for your organization, in Part 2. Overall, my blog focuses on the near future and how that actually looks like our past in many respects.
The result of super-cloud? Orchestration across third parties for your cloud solutions. This may sound like a far-off dream but it’s closer than you think. Super-cloud will connect all the clouds into a single entity.
The difference between multi-cloud and super-cloud is easy to see if you think of simple data transfer. In a multi-cloud solution, you’re just using clouds from multiple vendors so that you can get (consume) the different services you need. For instance, I need databases, so I might use AWS Aurora, but I also need identity, so I might use Microsoft 365, and then I need data analytics, so I might use GCP BigQuery. Multiple clouds, different services — but currently they don’t connect easily. Each cloud is a segmented solution within itself. AWS does databases and nothing else. GCP does data analytics and nothing else. You upload data from one to the other: none of them connect to the disparate cloud service in another location. Super-cloud will solve this by orchestrating the solutions across each cloud.
In the meantime, until there is a super-cloud per se, vendors are developing near-solutions. NetApp allows their premier cloud-storage solution OnTapp to be provisioned on cloud storage, but NetApp configures and syncs the data within its own platform. Another solution could be something like what Prosimo or Aviatrix offer, the ability to link clouds by using their Gateway technologies (Transit Gateway in AWS, Gateway in Azure, etc.). This method creates a networking layer that would allow different services to communicate. (I know, I’m melting these solutions down to brass tacks, but if you look at it all as network + storage + compute, the idea of a “super-cloud” is based much more on what the datacenter is than we think. If there is a solution that allows customers to see “cloud” as the three main components of the datacenter, then we may see more adoption of the cloud, or, should we say, the super-cloud.
Customers are already doing this in the datacenter and have been for years. Bringing all those components under the same roof really started with VMware. VMware succeeded in combining disparate physical technologies and allowing them to be utilized within their platform.
For instance, VMware doesn’t care what network switches or servers or storage you have, as long as it all fits on their list of proven hardware. The physical components in your data center should work on VMware’s platform, allowing you to manage those components together.
Now think of super-cloud in the same way: disparate third-party solutions for network + storage + compute but controlled on a central plane. We’re not there yet, since these third parties are still divergent from each other, but we’re also not that far off. What VMware is doing with their software-defined datacenter (SDDC) and cross-cloud services is very similar to what we think of when we’re identifying super-cloud. In fact, it really is network + storage + compute in each cloud, controlled by a self-service platform right now. If VMware can also combine orchestration to build the network layers and connect these different SDDC’s, then we will have a true super-cloud. We are that close. Closer, that is, to utilizing the same solution we have been using for years— except now in a location where public and private clouds could co-habit, managing the same software, same interface, and same skillset.