What are your architectural drivers for adopting multi-cloud?

Relationship between Multi-Cloud Business Objectives, architecture drivers and patterns

In one of my earlier article, I wrote about growing adoption of multi-cloud across industry and how COVID-19 will accelerate it further. I also referred to ‘Flexera 2020 State of the Cloud Report’, which found that 93 percent of enterprises have a multi-cloud strategy. That is a huge number, which means almost every enterprise has a multi-cloud strategy. However, it is early to see, how many of them are meeting their business objectives of adopting multi-cloud. It is important that technology leaders define their objectives well before starting the multi-cloud adoption. Otherwise, it can become failed investment in another technology buzzword. In this article, I am providing different objectives as architectural drivers, for which, organizations may adopt multi-cloud.

There can be different business objectives for multi-cloud adoption such as avoiding vendor lock-in, better resiliency, flexibility, more options for data sovereignty etc. However, it is not straight forward to translate these objectives while designing the multi-cloud systems. Defining architectural drivers aligned with the business objectives helps in that.      

Generally, when people think of multi-cloud, they expect an application or a workload using services from multiple clouds. However, it need not be always at an application or a workload level. If an organization has enabled multiple clouds and some workloads use one cloud and other workloads use different cloud – that also is a multi-cloud use case, but at the organization level. Hence, I use rather simple definition:

Multi-cloud is the use of multiple cloud providers (two or more) in a single scope, where scope can be an application or a workload, or a group of related workloads or the whole organization itself.”     

When an organization has multiple clouds enabled for consumption, different applications can leverage them in different ways to create different outcomes, which can be classified into one or more architectural drivers. I have described here different ways of implementing multi-cloud as architecture patterns, which in turn are grouped under architectural drivers.  Having such a classification helps your architects and engineers to design multi-cloud systems in ways, which would help in meeting the required business objectives.

Architectural Drivers for Multi-Cloud

Generally, the architectural drives can be classified into the following three categories. Each of these has one or more architecture patterns.

  1. Multi-Cloud for Availability
  2. Multi-Cloud for Portability
  3. Multi-Cloud for Innovation

Multi-Cloud for Availability

Applications are deployed to more than one cloud to increase availability, redundancy, or resiliency. Architecture patterns are:

  • Disconnected Instances: Application Instances in different clouds are completely independent from each other (separate data for each cloud). Such systems are much easier to implement (than connected ones) as you do not have to worry about data synchronization. There can be relatively static master data, a copy of which can be available in each instance.
  • Connected (or Replicated) Instances: Application instancesare connected to each other through some kind of data replication). When connected for a business continuity (or disaster recovery) purpose – different instances can be in active-active or active-passive configurations.

Multi-Cloud for Portability

Applications that need to be deployed in multiple cloud platforms without having to change their code or with minimal code change. For example, independent software vendor (ISV) applications that need capability to run in any cloud fall into this category. Architecture patterns are:

  • Abstraction of the underlying platform: Applications are designed to use more than one cloud by abstracting the underlying platform. It enables developers to consume cloud platform services without worrying about which cloud platform their application will be deployed into. Such an abstraction layer is generally defined using an API layer (in modern applications) or through abstract code libraries (e.g. typical data access layers). However, this might require significant investment either to build the abstraction layer or buy a 3rd party provider who provides the required abstraction.
  • Use of cloud agnostic technologies: Applications are designed with cloud agnostic technologies so that they can be deployed to any platform with minimal change in code. For example, if your applications are deployed within containers (or Virtual machines) – they can easily run on any cloud platform. However, your flexibility to leverage native/proprietary features of selected cloud is considerably limited and reduced to the lowest common denominator (LCD) among all cloud providers.

Multi-Cloud for Innovation

Applications use a cloud because of its native innovations/features, which are not available in other clouds. Even cost effectiveness of a service/feature of a cloud (as compared to others) can be considered under this pattern. Architecture Patterns are:

  • Single cloud for one application, multi-cloud for group of applications: In this pattern, an application would use only one cloud platform. However, the application team can choose the cloud from multiple options (e.g. Azure, AWS or GCP) available. Obviously, the team need to evaluate a cloud’s features with application requirements to make such a decision. In such cases, you would be free to leverage native innovations/features of selected cloud to take maximum benefit of the innovations in that cloud. At the same time, when you look at a group of applications at a department or organization unit level, you will have different applications using different cloud based on their requirements. Hence, at that group level, you are leveraging multi-cloud.
  • Composite Architecture: An application is split across multiple clouds where different application components come from different cloud providers. There can be different kind of scenarios here such as:
    1. API based composition: Application is deployed in one cloud calling a specific API from another cloud (e.g. taxi aggregator application hosted in AWS calling Google Maps APIs).
    2. Supplementary services-based composition: Applications using services from different clouds based on their better functionality/performance or lower cost. For example, an application UI and backend hosted in Azure using custom AI/ML models which are trained and deployed in GCP AI Hub and AI Platform.    


What I discussed here are high level architectural patterns. There are multiple ways and technologies available to implement these patterns. I am sharing some resources from cloud providers that I found useful for designing and implementing multi-cloud systems:

Originally posted at LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *