Responding to your feedback on ‘metacloud’

I’m not big on social media. Yes, I think it’s helpful to repost blogs and articles I’ve written so they can be publicized on social media and in other forums. Otherwise, some people interested in the subject matter might not have access to the information. However, I rarely hang around for conversation. I would love to—I just don’t have the extra time.

I did manage to check out the comments on the major social media sites on my last post, “The next frontier in cloud computing.” It generated a bit more buzz than usual, perhaps because of the title. I wanted to share some of the feedback from the discussions. Here goes.

Some companies are already selling the ‘metacloud’

This was the most common comment. First, I must point out that the metacloud as it exists today is an architectural pattern, not a specific product or technology. Granted, there is a lot of “meta” confusion these days, generated by Facebook’s recent rebranding of its popular social media platforms and conglomerates (Facebook, Instagram, WhatsApp, etc.) under one umbrella, Meta Platforms, Inc. This is not the metacloud.

Today’s metacloud is formed by any product, technology, or architecture standard that works across two or more public clouds’ products that address security, storage, networking, or whatever. Although the product can certainly be part of a metacloud architecture, the product unto itself is not a metacloud, at least not the concept that I presented. 

The metacloud needs a primary cloud services provider

Most of the major cloud service providers (CSPs) held this view. They are half right. Keep in mind that the metacloud, or whatever you want to name it, is a layer of technology that logically operates on top of two or more public cloud providers. The keyword there is “logically.” A metacloud dashboard could logically operate cross-cloud security, cross-cloud operations, cross-cloud governance, cross-cloud common storage systems, etc.—anything that provides abstraction from the native or proprietary cloud services that only work in the walled gardens of the specific cloud providers. The metacloud architecture/technology stack may “physically” reside on a specific cloud provider’s platform, or even on many different cloud providers’ platforms, while it “logically” controls systems on many different cloud providers’ platforms with no issues regarding where it actually runs. 

This is a bit confusing since we’re looking for cloud-agnostic technology to drive the metacloud, but the stuff must run somewhere, and that’s typically on a major public cloud. If you deploy much of what drives a metacloud, meaning cross-cloud systems that mostly reside on a specific provider, then I agree that you can consider your cloud provider as your primary metacloud services provider. I’m not sure it makes much difference in the outcome since the solution can physically run on any platform that can operate across clouds. You just pick the best platform for your solution set.

Adding a layer above multicloud deployments does not remove complexity, it just hides it

Another common comment, and plausibly a correct one. However, multicloud complexity is a result of selecting many different types of cloud services from different cloud providers. It typically happens when those charged with driving innovation prioritize best-of-breed cloud services that will more closely meet a project’s business requirements over the impacts those decisions will have on the complexity of the conglomerate systems. Complexity and heterogeneity are the results.

Complexity can be avoided when IT organizations restrict the use of all but a small number of approved cloud services. This does limit your developers’ and innovators’ access to best-of-breed technologies to drive the development of core intellectual property, products, and services. The key is to determine how much technological innovation would benefit a specific business need versus how much complexity it would create. Once you’ve done that, identify the optimal junction of the two.

For complex systems already in place, hiding architectural complexity stemming from poorly designed systems is not a best practice. This kind of complexity is different from complexity created by on-boarding cloud services that drive best-of-breed values. If complexity results from poor design, the business will be better off if you fix it rather than hide it.

My point is that complexity is the most likely outcome of using multicloud. We deal with an overabundance of choices that do have a core business benefit; thus, complexity will show up at some point. Leveraging abstraction and automation layers provides the ability to operate, secure, and govern complex multicloud deployments in an optimized way. Abstraction and automation layers can also require the same or fewer human and system resources to operate than a single public cloud deployment. Abstraction and automation hide certain types of complexity. This approach works and it can scale.

Using an abstraction layer causes latency

The final frequent comment was that if we add another layer between the native interfaces and those who ultimately consume that service, then there will be a delay in request and response time. 

For instance, let’s say an enterprise uses a storage interface abstraction that provides a common interface for all public, cloud-native storage systems. The developers do not need to write to each specific, sometimes proprietary API for each public cloud provider because the interface writes to a single abstract API/CLI that uses automation to deal with the differences. Yes, there are some latency trade-offs because additional processing and I/O need to occur. In most cases, it won’t be noticed by the developers, testers, or users. 

Of course, for the metacloud it’s not that simple. Metacloud is about the abstraction of storage and compute instances to allow for easier and more portable ways to interact with many different types of cloud services that exist in many different types of public clouds. 

Most of what makes up a metacloud are abstractions around operational processes such as security, core operations, governance, metadata management, and other things that would be overly complex and laborious if we had to deal with them using each native system in each cloud. Instead of working with one storage operations layer, we would have to deal with four or five. Making sure you have the skills on staff for each public cloud provider and the local cloud services is costly. You can count on paying three to four times more for multicloud operations where there is no common abstraction layer for any operations, meaning no cross-cloud operational abilities.

Most of the comments and questions about my metacloud article were based on sound logic. It’s important to question any new concept and weigh its pros and cons. I thank all of you who had an interest in the article, and I appreciate the feedback. Let’s continue the discussion.