All of the “Big 3” Cloud Service Providers Are Officially Strategically Multi-Cloud, And What This Means For The Industry

Photo by C Dustin on Unsplash

With a recent announcement from Amazon Web Services (AWS), each of the Big 3 Cloud Service Providers (CSP) are now strategically geared towards multi-cloud, which includes AWS, Microsoft Azure, and Google Cloud Platform (GCP).

Originally built as public cloud only service offerings, each of the Big 3 observed that the vast majority of their customer organizations and business partners were not able to fully exit the data center, as many workloads are not public cloud suitable. This trend drove many organizations to adopt a hybrid cloud strategy and invest in on-premise private cloud stacks while also moving to public cloud. As a result, each CSP evolved to offer hybrid cloud tools and services primarily meant to achieve technology stack consistency in the data center (e.g. AWS Outposts), as well as cloud peering solutions (e.g. VMware on AWS).

Most recently, those offerings have further evolved to include the beginnings of multi-cloud models that are supportive cross-CSP vendor as well as to the data center. We are still in the early stages, but each vendor now provides services, tooling, and even technology stacks that abstract and commoditize differences services in such a way that they can be orchestrated and managed across both data center and cloud environments.

Public cloud service providers are delivering both cloud-based and on-premise offerings that are environment consistent to promote hybrid & multi-cloud

The figure on the left depicts hybrid cloud models that generally enable “data center to cloud”, such as VMware on AWS. These offerings are generally anchored bringing the data center to the cloud, and oriented around use cases that reduce the friction to public cloud adoption, as well as integrating legacy or private cloud ecosystems with public cloud. Use cases here include data center extension, data center closure, VMware cloud migration, public cloud services on-premises in the data center, Independent Software Vendor (ISV) and software compatibility, and edge computing.

The figure on the right depicts both hybrid and multi-cloud models. Offerings such as AWS Outposts enable the “cloud to data center” model by bringing CSP-native services and offerings to an on-premise data center or co-location environment in a standardized way for a truly consistent hybrid cloud experience, although it is accomplished with a single CSP vendor environment.

Offerings such as GCP Anthos enable the “cloud to cloud” model by providing CSP-native services that both extensible to, and integrate with, other CSP environments. These offerings are early innovations that are enabling “true multi cloud” in an automated and orchestrated fashion.

To better understand the difference between hybrid and multi-cloud architecture and operating models, and the significance of this evolution, read more here on the 2020 trends driving deliberate, strategic adoption of hybrid and multi-cloud.

What is the history of the cloud vendors that led to a multi-cloud landscape?

So how have we arrived at this multi-vendor, tool and cloud landscape? One key reason is the overall product and service maturity of public cloud that has been over a decade in the making:

“The inevitability of cloud, and therefore multi-cloud. Cloud computing has passed the inflection point of being a technical certainty. With such rapid adoption of cloud, more and more organizations are now operating in more than one cloud platform for a variety of reasons — to meet regulatory requirements, diversify risk, avoid vendor lock-in, etc. These organizations want solutions that provide a consistent experience across cloud platforms, giving the edge to startups against native offerings from the major cloud providers.” — Ali Ghodsi, CEO, Databricks (1, a16z).

A number of trends and major cloud infrastructure developments have led us to where we stand today. The figure below shows a high-level view of the history of cloud computing, highlighting some of the major milestones that have contributed toward the multi-cloud landscape:

Cloud-native history and evolution (2, CNCF)

If you orient to the milestones noted at the bottom of the figure, a number of them have heavily contributed to and influenced where we are today and where the market is headed:

The rise of public cloud infrastructure and commodity compute & storage.

With the initial release of AWS commodity compute and storage in 2006, AWS was first to market with a modern cloud infrastructure service when it launched Amazon Elastic Compute Cloud. Initially, these services were limited to foundational infrastructure services (e.g. compute, storage, networking) and primarily geared for isolated use cases such as large scale data processing (e.g. the early incarnation of Google Compute Engine in 2012, which eventually developed into what is now Google Cloud).

Definition of open standards & cloud-native standards, and vendor agnostic IaaS & PaaS offerings.

After years of product development and service maturity, it was very clear that public cloud had progressed into an ecosystem where an entire IT environment could be sustained and operated, but many of the CSP vendors operated in ways where foundational services that appeared common and commodity at the surface, such as storage, compute, and network, in actuality were architected and operated very differently cross-CSP vendor and environment.

At this point, cloud native industry standards started to take hold in the community, including resources like the Cloud Native Computing Foundation (CNCF), 12 Factor Application principles.

The Cloud Tools Reference Architecture shows an array of offerings that emerged to enable CSP and environment agnosticism

Additionally, vendor agnostic offerings started to emerge that were capable of residing upon and integrating with any cloud or data center environment, including infrastructure and platform offerings (e.g. OpenStack, OpenShift), IT operations, provisioning and monitoring tools (e.g. Splunk, ELK, Terraform, Chef, Puppet), an orchestration and management tools (e.g. Mesos, NGINX, Envoy). These products and services made it easier to abstract away the differences in each environment and create better integration to eventual hybrid and multi-cloud environments.

Innovation of container-based computing (e.g. Kubernetes, Docker).

Also in the same timeframe, Google invented and released Kubernetes in 2014. Kubernetes is the first to market in creating production-grade container orchestration for automated container deployment, scaling, and management (read more here on the difference between Kubernetes vs. Docker, and containerization vs. orchestration).

Additionally, CSPs have also established their own native service offerings for container engines and worker nodes (e.g. Amazon EKS / ECS). Yet again, these cloud-native offerings, as well as the ability to “do it yourself”, both are highly promoting of the multi-cloud model:

“From monolithic apps to microservices. Kubernetes has allowed apps to be distributed across clusters, across clouds, and with an edge that is close to customers for better scalability and availability. As more organizations move from small, proof-of-concept deployments to running critical workloads in Kubernetes environments, almost every capability has to be reinvented for the new cloud-native world. Architectural transformations don’t happen overnight — but, just as virtual machines replaced on-premise servers, logically centralized, globally distributed containerized apps are the future, already transforming gaming and financial services, with ecommerce, media, and other industries not far behind.” — Thomas Graf, CTO & Cofounder, Isovalent (1, a16z).

The release of CSP multi-cloud services & tools.

… as you can see here, the general trend shows incremental innovation and offerings that have set up the opportunity for CSPs to embrace and release native tools and services, such as GCP Anthos (see section below for the current strategy and service offerings for each vendor). We can now explore how each vendor is reacting to customer demands for multi-cloud enablement, and the services that have been built upon this foundation.

Why wasn’t this possible before, and what blockers have been removed?

Years prior, many organizations had tried, and failed, to achieve the multi-cloud architecture and operating model. However, the new wave of CSP-native tooling and services was not available, and many other reasons inhibited the adoption of multi-cloud, including:

Lack of available tooling. Today, the friction to adoption of multi-cloud is significantly lower with container-based offerings, orchestration tools, and each CSP now providing services and tooling that promotes a more open and modular ecosystem. Many organizations attempted, failed at multi-cloud, and rolled back to hybrid cloud models and even “multiple cloud” models where disparate environments were managed separately.

Multi-cloud requiring unrealistic talent and skill requirements at enterprise scale. At the time, the CSP landscape was so nascent that it was hard enough to go all in with a single CSP, much less multiple vendors, without the enterprise talent model and skills in place. Now, most organizations operate in multiple CSP infrastructure and SaaS environments and have more of the skills required to build and operate a cloud-native ecosystem, although this still remains a constant challenge.

“The juice wasn’t worth the squeeze”. Given the lack of tooling, bespoke solutions attempted by many organizations proved that the uplift in resiliency, disaster recovery planning, and workload mobility was offset by the cost and maintenance overhead of the full stack and cross-environment interdependencies with bespoke solutions.

What is the current strategy and product set with each specific cloud vendor?

The CSP vendors maintains a set of hybrid cloud products and services that have evolved toward multi-cloud in reaction to the trends described in previous sections:

Each CSP vendor maintains a set of hybrid cloud products and services that have evolved toward multi-cloud

Google Cloud Platform (GCP).

GCP Anthos was first announced in 2019 initially as a hybrid cloud solution, and is generally considered first to market in the expansion to support for multi-cloud models. Per Anthos documentation, the stack is intended to be environment agnostic but primarily geared currently to run on AWS and on-premise Anthos clusters on VMware infrastructure, per Anthos technical documentation.

Microsoft Azure.

Microsoft was early to the hybrid cloud trend with the release of Azure Private Stack, enabling . Since then, the offering has expanded to Azure hybrid and multi-cloud solutions which include Azure Arc for enabling a single control plane cross-environment, Azure IoT for extending workloads to the edge, and numerous supporting services that underpin the multi-cloud ecosystem (e.g. Security, Data, Identity, Network).

Amazon Web Services (AWS).

For a number of years, AWS was primarily public cloud-native and eventually evolved into hybrid cloud with the AWS Outposts service offering. More recently, announcements have been made that have shown the AWS-native container services from Amazon will be expanded to support multiple environments and even other CSP vendors. It is not apparent yet if Amazon ECS Anywhere and EKS Anywhere will offer as high of a degree as the Azure and GCP product sets for enabling multi-cloud in its 2021 release. However, it is a big step in the same direction and embrace of the shift of many customers towards a demand signal of multi-cloud support.

What does this mean for the industry and its future trajectory?

Now that these new services and offerings are available to us, the Hybrid & Multi-Cloud Adoption Continuum provides a good point of reference for the various degrees of cloud adoption and their architectural and operational tradeoffs:

The key considerations for multi-cloud she be made within the context of the Hybrid & Multi-Cloud Adoption Continuum

Choose the right cloud “anchor” for your enterprise technology ecosystem.

For many organizations, this still remains as the data center for mission critical business and enterprise workloads and services (e.g. identity, encryption and key management), which are federated to public cloud environments. For other startups, digital and cloud natives, public CSP ecosystems are often where greenfield environments are born and also supports both mission and business critical workloads as well as enterprise IT services.

Understand what is commoditized for cross-CSP vendor services against what is differentiated.

When designing mission critical systems, one must not only look at features but also critically review resiliency. Two critical considerations should be factored in:

  1. CSP-native service selection: Which services should be selected for intra-CSP and what is their default failover profile (e.g. zone / region)? If additional design is also required by the vendor then the appropriate resiliency must be built in. It is key to note that in the spirit of the well known cloud best practices of the Shared Responsibility Model and Well Architected Framework, the onus is on the CSP vendor for adherence to SLA performance for commitments including service uptime and durability. Additionally, the architecture, usage and configuration of those services the failover and resiliency model of each service must be understood by the customer and how it supports the broader application architecture necessary for that system’s failover requirements (e.g. Active-Active, Active-Passive, Pilot Light).
  2. Cross-CSP or environment selection: Which services (or entire app / data sets) should be candidates for cross-CSP or environment failover. If CSP-native service selection will not meet all of the needs of your application architecture, consider your options with cross-CSP vendor environments and tooling, as well as the enterprise data center in a hybrid arrangement.

Factor in your resiliency planning and how multi-cloud can address your requirements.

Disaster recovery is not easy. It is more complicated to fail back post-recovery. With easier availability of cloud infrastructure resources, many companies have DR infrastructure setup and ready to go (e.g. Warm Failover, Pilot Light models). However, many organizations do not practice cloud-native BC/DR, or alternative models in multi-CSP or data center environments. BC/DR should be a top priority and backed into cloud product design, engineering & operations Automating your recovery processes is one of the best investments you can make to protect your business from unscheduled events. Automation reduces DR testing hesitation, reduces risk increases the frequency of tests. Chaos engineering comes up often as a technique to test resiliency; we have yet to see this applied in practice outside of big techs.

It is also critical to understand the key risk areas with each model and how to mitigate them, such as latency, data residency and security policies. Physical proximity of data center and cloud regions, the data residency and encryption implications of hybrid and multi-cloud tooling, and security orchestration of the same are all often high barriers to compliance and entry with many organizations

Read more here to better understand maintaining operational resiliency in a hybrid & multi-cloud world.

Make balanced cloud architecture choices that maximize control while leveraging the benefits of cloud.

Both cloud-native & cloud agnostic tooling and services will be imperative, and with recent CSP developments, commercial and public sector organizations now have the tools to succeed.

Detailed in Figure 5 above, there is a continuum of adoption that spans everything from an extreme desire for CSP agnosticism, control, and workload portability, to a full embrace of one or more CSP vendors and everything their environments have to offer. The recommendation is to carefully assess the posture of each adoption model against the broader technology strategy and make balanced cloud architecture and CSP service choices the underpin the vision for your environment and solution strategy.

Many organizations have arrived at hybrid or multi-cloud ecosystems “by accident”, rather than by deliberate strategy, and are going through the process of understanding their current data center and cloud footprint to assess the best model for operational resiliency, among other business demands. In the figure below, a wide spectrum of choice spans fully cloud-native, CSP embedded ecosystems as well as cloud agnostic solutions. Each model can fully enable hybrid & multi-cloud architectures, but vary in vendor engagement as well as tool and service selection to build the service fabric that is disaster tolerant.

Our observations in the market show a wide range of adoption patterns across each architectural model, with respective technical and operational trade offs. Cloud agnostic models are generally designed with bespoke DR solutions cross-CSP and data center, whilst using public cloud services heavily in the IaaS stack, often requires open standards and vendor agnostic platform tools that can reside in any cloud environment.

Restoration of data systems is complicated. When thinking of cloud services and their resiliency, keep your data architecture in focus. Data consistency, data traversal cost, latency between your primary and backup sites are key considerations when designing highly available mission critical applications in the cloud.

In the CSP-native models, organizations generally go “all in” with the cloud and instantiate the appropriate cross-region, and even cross-CSP controls to ensure operational resiliency.

Understand where the lines of demarcation are starting to blur and address them.

There is a new demand and need to get closer to the customer, endpoint, or wherever the data is collected for any given use case. CSP’s have noticed this trend and are establishing global edge locations, such as Amazon CloudFront for content delivery. The demands for fog and edge computing are increasing for a number of use cases that require compute capacity closer to the endpoint, which is increasingly presenting itself with innovation in Internet of Things (IoT) use cases like transportation management and autonomous vehicles in commercial organizations. Mission critical agencies (e.g. Aerospace and Defense) have to also solve for global disconnected operations and cross domain solutions for highly sensitive communications, workloads and data.

References cited.

1. The Enterprise in 2020 — what 24 company builders had to say. A16z.

2. Cloud-Native Computing Foundation:| Cloud Native and Container Technology Landscape

Other & embedded references:

1. Hybrid and Multi-Cloud Perspectives: 2020 trends driving deliberate, strategic adoption. LinkedIn.

2. Cloud Service Provider (CSP) service disruptions: lessons learned on maintaining operational resiliency in a hybrid & multi-cloud world. LinkedIn.

3. The Twelve-Factor App.

4. Multi-Cloud Architectures for the Enterprise: Part 1. Medium.

5. Cloud computing in the real world: The challenges and opportunities of multicloud. ZDNet.

6. Cloud Native Computing Foundation.

7. How AWS Came To Be. TechCrunch.

8. Announcing Amazon Elastic Compute Cloud (Amazon EC2) — beta. AWS.

9. Kubernetes vs. Docker. Microsoft.,production%20in%20an%20efficient%20manner

10. ZDNet. What is edge computing? Here’s why the edge matters and where it’s headed. Scott Fulton III. August 9, 2019.


1. AWS just went multi-cloud … and it’s only the beginning. A Cloud Guru.

2. Amazon EKS Anywhere. AWS.

3. Introducing Amazon ECS Anywhere.

4. AWS quietly enters the multicloud era. Protocol.

5. AWS Outposts. AWS.

6. Hybrid Cloud with AWS. AWS.

7. Introduction to AWS Outposts. AWS.

8. Amazon CloudFront.

Microsoft Azure:

1. Azure services now run anywhere with new hybrid capabilities: Announcing Azure Arc. Microsoft Azure.

2. Azure Hybrid and multicloud solutions.

3. Azure and AWS for multi-cloud solutions.


1. GCP Anthos.


3. Hybrid and multi-cloud patterns and practices. GCP.

4. Hybrid and multi-cloud architecture patterns. GCP.

5. Hybrid and multi-cloud network topologies. GCP.

6. How Anthos And Multi-Cloud Are Transforming Enterprise IT. Forbes.

7. The economic benefits of Anthos. GCP.

8. Anthos technical overview. GCP.

9. Setting up Anthos on multi-cloud. GCP.

10. Anthos in depth: What new AWS multi-cloud support means for you. GCP.

11. Introducing Anthos: An entirely new platform for managing applications in today’s multi-cloud world. GCP.

12. Application modernization and the decoupling of infrastructure services and teams. GCP.

13. How computing has evolved, and why you need a multi-cloud strategy. GCP.

14. Is Anthos the edge Google needs in enterprise cloud? ZDNet.

15. Google Compute Engine. Wikipedia.

16. The History of Kubernetes on a Timeline. Rising Stack.

Boston Consulting Group | Army Officer - #Cloud #Cybersecurity #Cryptocurrency #BCG #Army

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store