Multicloud is one of those deployment models that most enterprises already use but do so without having purposefully intended to move to multicloud. In other words, multicloud architecture by accident.
I’m noticing some emerging patterns around the purposeful use of multicloud and its benefits. These architectures are derived from the business value of leveraging multicloud, not the result of random decisions that result in multiclouds. There is a huge difference.
Here are three emerging multicloud architectures and what you should know about them:
Data-oriented multicloud architectures. Multicloud typically means that the data is coupled to the cloud provider running the applications. Thus, SQL Server may be bound to Azure-based applications, whereas MySQL may be bound to AWS-based applications.
This is not optimal, considering that the public clouds become islands unto themselves as far as data goes, not working or playing well with other databases and applications that exist on other public clouds in a multicloud architecture.
A data-oriented multicloud means that the focus is one common data source shared among the different public clouds. There is a single source of truth for core data, such as customers and sales.
Data virtualization tools, data integration tools, and metadata management tools are key to success with data-oriented multicloud deployments. In essence, we’re binding the heterogeneous clouds together at the data level.
Service-oriented multicloud architectures. These are often data-oriented as well, but they focus on cloud providers sharing services, including standard services and microservices. The idea is that services built on a single cloud are available for reuse on other public clouds as well.
This requires centralized service/API governance, perhaps not existing on any single cloud. In some cases, it’s better on-premises. In essence, we’re binding the clouds together at both the data and service levels.
Process-oriented multicloud architectures. This is the highest order for multicloud and is typically also service-oriented and data-oriented. We’re binding the applications and data together through abstract processes that span public clouds.
The power of this architecture is that you’re able to create processes that ride on top of application services and data, such as meta applications capable of defining higher-level processes leveraging existing behavior and data. For example, you can integrate ERP data and services running on AWS with the sales order entry system running on Azure and the predictive analytics system running on Google.
Again, although these process management systems can run on a single cloud, they are also good candidates to run on-premises or with managed services providers, as long as the host is neutral.
Of course, there are many other patterns as well—I could easily fill a book. However, they are still emerging, and the patterns we leverage in three years may be very different from the patterns and best practices of today.