A reference architecture for multicloud

Today’s definition of multicloud depends on who you ask. This is not a new trend. Whenever a new technology gets some hype, suddenly there is semantic confusion.

My definition is a bit more holistic than most: Multicloud is a collection of public clouds, private clouds, and legacy systems (yes, I went there). Two or more public or private clouds must be present to be true multicloud. Legacy systems are optional but also good to include.

A charted representation of my definition looks like this:

Something I’ve learned over the years is that frameworks of any kind have to be generic and applicable to different problem domains. My representation includes most of what you’ll find in common multicloud deployments I see today.

If this seems complex, that’s the point. If the goal is to get a healthy multicloud deployment up and running, you’ll need most of these services. That list includes everything from cost governance, storage management, and cloud service brokers, as well as orchestration and process management—and those skills require qualified talent.

You’ll need a few more things, depending on your industry, such as compliance management. Figure on at least 20 percent to 30 percent more services to ultimately meet your business needs.

Note that my multicloud definition includes two core meta-layers:

Data-focused multicloud deals with everything that’s stored inside and outside of the public clouds. Cloud-native databases exist here, as do legacy databases that still remain on-premises. The idea is to manage these systems using common layers, such as management and monitoring, security, and abstraction.

Service-focused multicloud means that we deal with behavior/services and the data bound to those services from the lower layers of the architecture. It’s pretty much the same general idea as data-focused multicloud, in that we develop and manage services using common layers of technology that span from the clouds back to the enterprise data center.

Of course, there is much more to both layers. Remember that the objective is to remove humans from having to deal with the cloud and noncloud complexity using automation and other approaches. This is the core objective of multicloud complexity management, and it seems to be growing in popularity as a rising number of enterprises get bogged down by manual ops processes and traditional tools.

Also note that this diagram depicts a multicloud that has very little to do with clouds, as I covered a few weeks ago. Indeed, the clouds become the source of the services and data, but the tougher problem is how you build systems in and between the public clouds, private clouds, and traditional data centers that can manage how both data and services are leveraged by the applications, depicted at the top of the diagram.

This is a new paradigm for staff who have only dealt with cloud-native services for the past several years. Now we must configure architectures that span technologies and create a more valuable layer to help build and deploy business solutions. This requires a step to define exactly what that architecture looks like at each level.