A lot of hype is swirling around the new ‘metacloud’ or ‘supercloud’ buzzword. Let’s just focus on what should go into a cross-cloud technology stack. I’m often taken aback by the lack of details we get these days around concepts that are important to enterprise computing. With hybrid cloud and multicloud, for example, you’ll get different answers depending on who you ask and their own bias. This is why I always make time to define something before I discuss it. The notion of cross-cloud services to support a multicloud (perhaps including on-premises traditional legacy systems) is beginning to be understood as an important layer that we need to define. I view this concept as the next focus of cloud-based technology, and for good reason. I covered this topic a few weeks back, and it received more attention than I expected. Keep in mind that I’ve been focusing on this space for some time. Enterprises and technology providers seem to finally understand that multicloud is not about clouds, it’s about what’s between and above clouds. And what’s between and above clouds is the metacloud or the supercloud, depending on what term you’re going with (I vote metacloud). A cross-cloud service layer 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. It solves a few problems, such as reducing complexity so that we’re not doing redundant things such as working with specific native security technology within each cloud provider. It uses common abstraction and automation layers to deal with operations, governance, and security with a single pane of glass and single set of APIs so that these systems are much easier to manage. With the metacloud, we’re not dealing with infrastructure services such as storage and compute using the specific interfaces that the public cloud providers provide. Instead, we can deal with each specific system using a unified dashboard or unified call-level interface (CLI) that’s the same no matter the public cloud provider’s infrastructure service. Thus, everything should be easier and less complex, with much less cost and risk from multicloud operations. Again, remember that the metacloud is a set of cross-cloud services that exist logically above the cloud providers, even perhaps above private clouds and legacy systems that may be part of your multicloud deployment. In other words, the metacloud is an enterprisewide solution. Inside the metacloud It’s easy to determine what should be in this metacloud layer. As a rule, anything that sits in the metacloud layer is likely more focused on cross-cloud operations. Common operations services (such as AIops and cloud brokers) that carry out operations for each cloud provider but do so with a common dashboard and programming interface General operations, such as storage and compute management Specific types of operations such as security (secops), artificial intelligence, database, finops, etc. Data integration layers that move data in and between data storage systems and applications within a specific cloud Cross-cloud orchestration systems, including container orchestration and management, etc. Common database services or a database that spans clouds Devops services Common AI services that provide knowledge-based sharing between clouds These cross-cloud operations tools can be as many as four to six different tools that are able to work and play well together. If somebody attempts to sell you a single operations tool that does it all, they are likely exaggerating the capabilities of their technology. Of course, these services are differentiated from services that exist and run within a single cloud deployment. These can reach across all public clouds and even legacy systems, providing common services that no longer must be deployed within just a single cloud. Catching the theme here? Hopefully, this is not too confusing. Using a metacloud seems very logical to me as a cloud architect who’s looking for the most optimized solutions and normalizing technology so that we’re not solving the same problems for each public cloud that’s part of our multicloud—or any complex cloud deployments for that matter. It does take much more thinking and planning, and thus I hope that we’re ready to make the metacloud something that benefits enterprise IT a great deal. Related content analysis Azure AI Foundry tools for changes in AI applications Microsoft’s launch of Azure AI Foundry at Ignite 2024 signals a welcome shift from chatbots to agents and to using AI for business process automation. By Simon Bisson Nov 20, 2024 7 mins Microsoft Azure Generative AI Development Tools analysis Succeeding with observability in the cloud Cloud observability practices are complex—just like the cloud deployments they seek to understand. The insights observability offers make it a challenge worth tackling. By David Linthicum Nov 19, 2024 5 mins Cloud Management Cloud Computing news Akka distributed computing platform adds Java SDK Akka enables development of applications that are primarily event-driven, deployable on Akka’s serverless platform or on AWS, Azure, or GCP cloud instances. By Paul Krill Nov 18, 2024 2 mins Java Scala Serverless Computing analysis Strategies to navigate the pitfalls of cloud costs Cloud providers waste a lot of their customers’ cloud dollars, but enterprises can take action. By David Linthicum Nov 15, 2024 6 mins Cloud Architecture Cloud Management Cloud Computing Resources Videos