Multi-Cloud: When It Makes Sense...and When It Doesn’t!
This blog is a group effort from Contino, many thanks to the other contributors: Aaron Brock, Greg Patmore, Dan Petty, Joe Bennett and Jason Lutz.
Multi-cloud refers to the use of more than one public cloud provider. This is not to be confused with hybrid cloud which is the combination of public and private clouds interconnected with each other.
According to various internet sources, upwards of 80% of enterprise organizations that have adopted public cloud services are working with two or more providers.
Some organizations have organically become multi-cloud through acquisitions or as a result of different teams or departments having the option to choose, while other organizations have made conscious decisions to be multi-cloud for various reasons.
The benefits must be carefully weighed against the complexity and challenges associated with multi-cloud. A conscious decision to use multi-cloud should be based on a strong reason or solid business case, and should start with a carefully planned multi-cloud strategy.
In this blog, we will provide guidance on when multi-cloud makes sense, and when it really doesn’t. Below is a preview, followed by a deep dive into each.
When Multi-Cloud Makes Sense
- When you want to exploit best-in-class features of multiple providers, and have the culture and skills to do so effectively
- When you need multi-cloud to meet certain laws and regulations
- When you become multi-cloud through acquisition and migration is too costly
When Multi-Cloud Doesn’t Make Sense
- When you want to avoid vendor lock-in
- When you are implementing Disaster Recovery
- When you want to save money
When Multi-Cloud Makes Sense
1. When you want to exploit best-in-class features of multiple providers, and have the culture and skills to do so effectively
High-performing organizations using modern technology and practices with a strong culture of innovation may be well-suited for a multi-cloud strategy that takes advantage of the strengths of various cloud providers.
These organizations have an appetite for and are willing to invest in experimentation. Their systems and applications are highly decoupled, using microservices and container technology, built with interoperability in mind. They look to create provider agnostic strategies that will allow each application stack to be deployed on the most appropriate provider based on feature or performance requirements.
If pulled off successfully, going multi-cloud in this context proves a powerful tool. You can mix-and-match the different services of each cloud provider to provide the optimal palette of tools for your developers. This setup can be a great solution for developers who want platforms to meet the specific needs of individual applications or services.
For example, a company running an e-commerce application on a Microsoft tech stack (SQL, AD, .NET) may choose Azure as their primary cloud provider due to both compatibility as well as Azure’s interoperability with other cloud platforms. But they could then choose GCP for their customer analytics workload, collecting data from multiple channels into a common marketing data warehouse, and using GCP’s ETL, analytics, machine learning and visualization services to help drive product roadmap and offerings.
Regardless, these organizations must enter into multi-cloud with a plan to make sure it adds more value than it costs.
- How will security and compliance be enforced, monitored and managed across multiple platforms?
- How will costs holistically be planned, monitored and managed?
- How will infrastructure and environments be managed across the platforms?
- What are the core requirements and SLAs a provider must meet to be engaged?
- What is the impact of integrating systems or applications across platforms?
- What is your workload placement strategy? (ie. design principles, practices, standards to ensure continued interoperability)
- What is your data replication strategy?
WARNING! Going multi-cloud for this reason is a difficult road and your organization needs to make sure it is prepared, or it will end up costing you a lot more than you get from it. For example:
- The cost of integration between cloud providers. A key penalty that occurs at these integration points is the cost of egress data. The cost of integration and data transfers may outweigh the benefit of best-in-class features.
- The cost of talent. It is usually difficult to find people competent in one cloud let alone two or more. If you do find them they tend to be expensive to maintain and difficult to retain. This also translates to additional cost associated with managing multiple vendors and consulting partners that have platform-specific expertise.
Alternatively, consider a ‘roll your own’ approach that takes advantage of best-in-class features without going full out multi-cloud.
The most successful organizations we’ve seen typically choose a primary cloud provider based on the needs of their most critical application systems, and then work to design more customized, ‘roll your own’ versions of ancillary systems using a mixture of open source, commercial, and SaaS-based solutions. Cross-provider integrations should be careful to limit data transfers in order to reduce costs.
The main takeaway is that there is an investment in making multi-cloud work for your organization and having some form of governance to ensure that the plan doesn’t fall off the rails as your organization grows.
2. When you need multi-cloud to meet certain laws and regulations
Compliance is a critical priority when considering cloud providers, and in specific instances may dictate the need for multiple cloud providers.
INDUSTRY REGULATIONS
Your system may be subject to a variety of laws, regulations and standards depending on industry vertical and the sensitivity of your data, such as FISMA and FedRAMP (US government systems), HIPAA (healthcare), GBLA (financial) or PCI DSS (credit card).
For example, you need to build a new system that will be used by the US government and must be FedRAMP compliant. Your existing systems are hosted on a platform that does not have a robust FedRAMP-compliant suite of offerings, or may not provide a FedRAMP-compliant region at all. In this case, a multi-cloud strategy is a necessity, at least in the near term.
DATA SOVEREIGNTY
Additionally, your system may be subject to a variety of data-related laws depending on the citizenship or residency of individuals or customers represented in your data, and where you store and process your data. For example:
- Countries such as Russia, China, France, Indonesia and Vietnam have laws that require their citizen’s data to be stored physically within the country’s border. If you are a multinational company doing business within one of these countries, you have to use a cloud provider that has data center(s) in those locations.
- China’s “Great Firewall” regulates the internet in China, blocking access to selected foreign websites, as well as slowing down cross-border traffic, which makes it difficult for US-based cloud providers to offer some services in China.
BEFORE MAKING A DECISION, DO YOUR RESEARCH:
- Make sure you understand what regulations apply to your data.
- Review cloud provider SLAs and compliance with applicable regulations.
- Review cloud provider’s global infrastructure. Major cloud providers have data centers in multiple regions and countries, and are always expanding into new locations.
- Ask your cloud provider if they have options that will address your specific needs. For example, AWS provides options that may help with websites in China.
When multi-cloud is necessary in order to be compliant, be sure to develop a strategy for the management of security controls that may vary by location, and for ensuring compliance as well as being able to prove compliance.
3. When you become multi-cloud through acquisition and migration is too costly
A company can become multi-cloud organically when it acquires another organization that is using a different cloud provider. The choice is then to migrate one cloud to the other, or to stay multi-cloud.
Staying multi-cloud is often a good choice as the cost of migrating everything from one cloud to another often does not outweigh the benefits.
Consider the following to make a “migrate” or “stay the course” decision.
- Will the acquired system need to be integrated with existing systems? If so, roughly how many integration points are expected?
- What is the effort required to migrate into your current platform?
- If you do choose to migrate, how long will the current platform need to run in parallel before cutover to the new platform?
- Does the benefit outweigh the cost of migrating? Also consider opportunity cost, the benefit forgone by taking this course of action.
- Does your current staff have the necessary skills to maintain the application in the current environment and to migrate to the new?
When it doesn’t make sense to migrate, apply the following strategies to successfully integrate multi-cloud systems.
- Proactively plan your multi-cloud strategy, to include staffing and skills, centralized vs. decentralized management of security and compliance, and visibility.
- Across all organizations regardless of cloud provider, adopt cloud-agnostic engineering principles and practices to pave the way forward. This should apply to the development of applications using modern technologies (such as microservices, APIs, and containers) and infrastructure (through use of cloud-agnostic provisioning tools such as Terraform for instance).
- Employ the use of a multi-cloud cost management tool like Cloudability and a multi-cloud compliance and governance tool to provide cross platform visibility to enable data-driven insights and decision-making.
- Conversely, avoid comprehensive multi-cloud management brokers that provide service abstraction through use of a service catalog, and other functions such as multi-cloud integration, cost and compliance management. CSBs introduce yet another layer of cost and complexity and often frustrate engineering teams that use them. They may also lead to a least common denominator approach where only the basic services common to multiple providers are made available to developers.
In most cases, the cost of migration will outweigh the benefits, so instead of migrating, invest in a multi-cloud strategy to pay the way forward.
When Multi-Cloud Really Doesn’t Make Sense
1. When you are trying to avoid vendor lock-in
The most common reason that organizations choose multi-cloud is vendor lock-in.
The vendor lock-in problem in cloud computing is the situation where customers are dependent on (i.e. locked-in) a single cloud provider technology implementation and cannot easily move in the future to a different vendor without substantial costs, legal constraints, or technical incompatibilities.
Below are some examples of the risks of vendor lock-in.
- You lose control of application features and performance. Imagine you have an application on a cloud, but there is a limit in the underlying vendor service that prevents certain new features from being added or prevents performance goals from being achieved. The vendor promises an upgrade, but you have no control over when that’s going to happen, and as a result, you lose control over your application’s features and performance.
- Your service is deprecated. The vendor may discontinue support for a service, forcing you to migrate, upgrade, or rebuild, causing extra cost. Or the vendor might undergo corporate actions such as M&A or bankruptcy, causing service disruption, which in this case is beyond the vendor’s control. Laws and policies, which can impact availability of certain services, can change too.
- Inferior or lacking services or features. In addition, the lack of competition means you might miss out on potentially more cost-effective, higher performing competing services from other vendors, and the vendor might lack incentive to improve their service.
While these are real and valid risks, they in themselves do not justify a decision to go multi-cloud. The costs almost always outweigh the benefits.
There are other ways to mitigate these risks:
- Select a well-established cloud provider with a wide range of services, steering clear of immature services or services that lack competition.
- Architect systems to be as decoupled as possible using modern technologies such as microservices, APIs, and containers, allowing for easier portability between providers should there be a compelling reason to switch.
- Consider building custom functions in house hosted on an IaaS offering vs. using bespoke cloud services unique to one vendor.
2. When you are implementing Disaster Recovery
Besides vendor lock-in, the next most common reason that organizations choose multi-cloud is for Disaster Recovery (DR), the practice of keeping systems running and available for its intended users, in the face of a disaster.
Why doesn’t this make sense?
- Major cloud providers have DR capabilities built into their system, offering services in multiple regions, and provide the building blocks for a customer to add cross region failover capabilities to their applications. For example, if you configure Disaster Recovery for a database across two regions, in the event of a natural disaster taking down the primary region, your database can recover from a replica in the secondary region.
- It may be tempting to use multiple cloud providers to achieve greater separation between the regions your application is deployed to, however in reality this benefit is negligible to non-existent since Cloud Service Providers already go to great lengths to enable each region to run independently.
- There are many practical downsides to a multi-cloud disaster recovery approach, for example increased cost and complexity of maintaining and testing such a system. You may need to recreate many of the DR capabilities that are already built into most cloud providers, for example AWS’s RDS disaster recovery capability.
In summary, due to the added cost, complexity and loss of feature set, one should avoid the use of a multi-cloud strategy for disaster recovery.
3. When you want to save money
While savings can be found through a multi-cloud strategy, there are hidden risks and costs.
- A multi-cloud organization will need to hire and train personnel to manage a larger spectrum of possible resources. This brings with it not only the cost of maintaining more experienced staff, but also the challenge of monitoring and managing spend and resource allocation across the desired cloud platforms.
- The cost of cloud resources can change between the various providers. Moving resources between providers to save money creates unproductive work for those managing infrastructure resources. Service offerings from different cloud providers that seem similar at first glance are likely to have performance or functional differences that make provider migrations more difficult and time-consuming than anticipated.
- Cloud providers also charge significantly higher data ingress/egress rates for data leaving the region/provider, which can have a significant impact on the cost of a multi-cloud strategy depending on the quantity and direction of data flow. Similar cost savings can often be found through the use of resource reservations, spot-type instances, serverless infrastructure, and discount agreements with single cloud providers due to large accounts.
A single cloud strategy with proper capacity planning can have lower cost than a multi-cloud strategy, while avoiding unnecessary complexity.
Whatever You Do: Plan Wisely
In summary, we often see clients who have entered into multi-cloud for the wrong reasons.
They are struggling to manage integrations, infrastructure, security, compliance, costs, skills and support. They are sampling multiple cloud providers and making little progress in any one because of the lack of skills and necessary guardrails to confidently migrate on-prem workloads into them. Or they are using multiple platforms with little or no governance over costs and compliance.
Multi-cloud can be effective and even optimal if entered into for the right reasons and if well-planned and executed. It is however important to assess your organization’s readiness. A certain level of maturity as well as an investment in a solid multi-cloud strategy is generally an indicator of how well multi-cloud will work for a particular organization.
The best plan for success regardless of single or multi-cloud is to adopt engineering principles and practices that are cloud agnostic, providing guidance and best practices for any engineer who wants to consume any cloud platform, allowing for greater interoperability between providers.
