Skip to content

November 1, 2021

Multi-Cloud vs. Omni-Cloud

By IT Revolution

This post has been adapted from the 2021 DevOps Enterprise Forum guidance paper by Satya Addagarla, Anderson Tran, Mik Kersten, Rob Juncker, Betty Junod, and Sasha Rosenbaum.


Multi-cloud has become the buzzword du jour in cloud infrastructure as either the result of vendor marketing or a reality that enterprises find themselves in organically. In this section, we will provide guidance for evaluating tolerance for lock-in and maintaining focus on the highest value when using multiple clouds.

The reality for the vast majority of enterprises will be, at a minimum, the active use of two clouds for IaaS (infrastructure as a service) and the conversion to SaaS to replace a portion of their existing on-prem independent software vendor (ISV) or custom applications.

Organizations are increasingly working with multiple cloud providers. A recent Gartner survey of public cloud users finds 81% of respondents using two or more providers.

But what are you trying to achieve by using multiple clouds? Should your strategy be designed around avoiding vendor lock-in or to select best-of-breed services? Is it a fad or even worth the effort? Even with the breadth of cloud services available today, most enterprise cloud strategies start with the vendor selection instead of mapping the capabilities needed to the services available.

All-In vs. Lock-In

Avoiding vendor lock-in is a common refrain from vendors as a case for using many clouds, viewed negatively as a vector for financial and technical risk. Meanwhile, using the term all-in is viewed positively to indicate an organization’s commitment to deep specialization in a specific cloud’s infrastructure, APIs, and operating model.

The fear around lock-in is based in the loss of negotiating power and application portability. Lock-in is a more nuanced discussion around the requirements for the application and system components weighed against available services, SLAs, and cost to deploy and operate the application. 

Adrian Cockcroft categorizes a set of business and technical lock-ins in this talk about Vendor Lock In. It is important for enterprises to understand the potential areas of lock-in and evaluate their tolerance and ability to change the state of the lock-ins under their span of control as they consider their cloud deployments.

Understanding the Different Types of Lock-In

Business Lock-In

Not likely to change
once in place.

Technical Lock-In

Can be changed with a varying degree of engineering time and effort.

Soft Lock-In

Systems can be built to avoid being affected by these.

Legal: Regulatory compliance restricts the deployment or data to a specific location or security clearance, limiting the possible providers.

Interface: APIs and query languages differ between components increasing the switching costs.

Implementation: Occurs when the standard interface doesn’t match its implementations. This can be avoided by testing against several implementations.

Political: A business partnership or financial investment prevents the use of certain vendors.

Proximity: When systems make assumptions on how long operations take, leading to latency intolerance, and requires components to be physically close.

Web Service: If some parts of an app are built with a specific vendor’s web service. In this situation, the rest of the application may move, but this specific component will remain and continue to be accessed through the web service.

Financial: When vendor evaluations are negated by existing enterprise license agreements (ELA) contracts with a preferred vendor.

Deployment Architecture: When assumptions are made about a system layout, scale requirements, and special hardware needs that may not be supported across different regions or vendors.

Data: If there is too much data to be moved effectively with the available bandwidth. There are a range of approaches available to address data mobility.

Management: Executive relationships influencing purchasing decisions that override other considerations.

   

Beyond the different types of lock-in, the risk of lock-in should be evaluated by application. For mature and stable applications, where the majority of the engineering effort is focused around maintenance, keeping that application in a single cloud can be the right balance of effort to value. For applications that are in active development and continuously updated with global deployment requirements, more effort to work across different clouds will result in higher value.

Ecosystem Consideration

An area of consideration is around the toolset surrounding your cloud infrastructure. When thinking of a mono-cloud approach, ask yourself if you are artificially avoiding an entire ecosystem by only evaluating those offered by your cloud provider.

While it may be convenient to choose infrastructure and tools from a single provider, the evaluation and use of third-party tools can provide greater flexibility at the cost of more up-front effort.

As an example, investing in cloud agnostic tooling to manage the API layer, CI/CD pipeline, and provisioning automation provides for greater flexibility in using different cloud providers when needed. Additionally, when looking at various app and data components, selecting open-source packages with broad ecosystem support adds to your optionality on platforms and cloud providers.

Portability, Scalability, Consistency

Application portability from one cloud to another is often cited as the multi-cloud utopia, moving running applications as needed to get the best “just in time” cost and performance without disrupting a customer’s transaction. In reality, most optimizations come in the form of right sizing, different types of instances, and contract terms with the provider. The promise of portability is centered around different technical requirements for deployment flexibility and consistency, simplifying scalability, and reliability.

The level of “portability” (aka cloud agnosticity) that you need will dictate the level of technical investment in layers of abstraction and cloud agnostic ecosystem components and tools. Even with this investment there will be differences in many processes to provision, configure, and deploy, as how you configure the infrastructure plumbing is different across cloud providers. It is critical to evaluate the level of need on an app-by-app basis and understand if the resulting value is worth the investment.

The following case studies illustrate three real world scenarios for using multiple clouds, the driver, and the resulting engineering investments

Case Study: Dreamworks

At the KubeCon EU 2019 Panel Discussion Going Multi-Cloud for Realz, Umair Mufti, Data Services Manager at DreamWorks, states that multi-cloud means to their business the ability to hire the talent anywhere around the world and provide them with their custom environment and shared data for the movie or show they are working on. Due to the collaborative nature of the project, consistency in tools and data is paramount among the artists working on the movie. The infrastructure is not the priority. The value is in the content layer that is facilitated by the custom apps which may be deployed on AWS, Google, or a local datacenter.

Case Study: Target

When cloud exits or repatriation happen, they often make the news, as in the cases of companies  like Target and Dropbox. But while they are not common, it is a strategic business decision.

In the case of Target, Amazon’s entrance into groceries turned a vendor into a competitor and fundamentally changed Target’s cloud strategy. They decided to exit AWS and invest in open-source abstraction layers like Kubernetes, Docker, and Spinnaker. This allowed for the ability to deploy and run apps using the application abstraction layer that is common among different cloud providers, providing them the flexibility to deploy their critical customer facing ecommerce and in-store workloads on three platforms as needed. This example highlights the investment in cloud agnostic abstraction layers and their prioritization to high-value applications that directly impact revenue across a very distributed landscape of physical stores and digital (web/mobile) customer experiences.

Case Study: PagerDuty

The use case of running the same production service and data in an active/active state across multiple cloud providers and availability zones that simultaneously accept traffic is an even rarer unicorn in the multi-cloud universe. PagerDuty has spoken publicly about their multi-cloud architecture, engineering investment, and the lessons learned over the years. Running the same service simultaneously across multiple clouds has made the PagerDuty team invest in building, operating, and maintaining the infrastructure plumbing directly so they can have a high level of control versus using the services directly available from each cloud provider outside of raw compute resources.

You will need to consider if the value of your business is in the engineering custom infrastructure in addition to the differentiated value of the apps and services you deliver on top of it.  The answer will vary from company to company and from app to app. When considering the level of cloud agnosticity required, enterprises will need to weigh where they perceive their value is. Is it best served in building application business logic or in building differentiated infrastructure? And which applications require this capability and for what purpose?

Have a Preference but Don’t Be Dogmatic

Our recommendation in pivoting from a multi-cloud to an omni-cloud approach is to consider the cloud utility by application, the objective and key result desired, and its alignment to the business. This allows teams to avoid a “one cloud fits all” or “all clouds fit all” type of dogmatic thinking that limits the decision-making process. Omni-cloud lets the business and application needs drive the infrastructure decisions.

Most organizations should select a primary provider for general purpose infrastructure on which to operationalize processes and then evaluate abstraction layers and ecosystem tools that allow for a level of consistency they would like to achieve across deployments. Having a preferred cloud provider streamlines onboarding, training, and operations. Abandoning dogmatism decreases the flow time from idea to product deployed and  value back to the business.

Select the abstraction layer and ecosystem components that you want to invest in that are common across clouds for optionality with a level of consistency. Investment in cloud agnostic workflow and management tools will preserve the ability to choose best-of-breed services and clouds by application, while still maintaining enough control and governance over configurations and policies.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT on Social Media

No comments found

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Map Camp: Weird Mapping – How to Create a Revolution
    By David Anderson

    A version of this post was originally published at TheServerlessEdge.com. Dave Anderson, author of…

    Serverless Myths
    By David Anderson , Michael O’Reilly , Mark McCann

    The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here…

    What is the Modern Cloud/Serverless?
    By David Anderson , Michael O’Reilly , Mark McCann

    What is the Modern Cloud? What is Serverless? This post, adapted from The Value…

    Using Wardley Mapping with the Value Flywheel
    By David Anderson , Michael O’Reilly , Mark McCann

    Now that we have our flywheel turning (see our posts What is the Value…