This blog, part of the Cloud Strategy Unboxed series, looks at a cloud strategy that supports workloads on multiple cloud service providers. Most common are two providers, but some organizations – especially in the telco industry, aspire to support all three major cloud providers and some of the smaller niche or regional ones. Multi-cloud adds considerable complexity and needs to be carefully planned.
Begin with one cloud provider
A multi-cloud strategy significantly increases the complexity and resource requirement of cloud adoption. For example, Cloud Centre of Excellence (CCoE) subject matter experts in each area of responsibility need to be duplicated for each supported cloud service provider (CSP). The cloud platform, its controls and the self-service portal must be expanded to support the different CSPs. Training efforts need to be ramped up with courses provided for each CSP and an expectation that the broader organization become at least familiar with all options.
Because of this, it is more common, and indeed recommended, that organizations start with a single cloud service provider. It allows organizations to focus on selecting and implementing the best possible solution for their needs and gaining some cloud maturity before supporting a more complex, multi-cloud strategy.
Starting with a primary CSP does not rule out becoming multi-cloud when the organization is ready or using other CSPs in the interim. Certain applications will perform better on certain CSPs, and the CCoE can support that with a workload approach on an exception and approval basis for each particular application. When the organization is ready for a multi-cloud strategy, these applications will need to be migrated again into the cloud platform.
Allowing limited workload migrations to secondary CSPs enables some individual teams to gain early experience with an additional CSP. These teams can later be instrumental in developing the capabilities and platform when the organization is ready to add this CSP to its strategy.
Primary CSP selection
CSP selection is primarily a strategic decision driven by less-technical concerns. At a very high level, and for common workloads, the cloud providers offer similar functionality and are actively working to catch up to each other. So, there is limited benefit in basing a decision purely on technology, unless the use case is quite specialized.
CSPs with a local region or planned local region can be better for data transfer, latency, security, and data compliance.
Existing CSP experience should be considered. Teams with experience with the primary CSP will help adoption go smoother and faster. Broader experience will ensure more teams are happy with the choice of CSP, reducing the amount of resistance.
There are some general considerations in terms of the technical strategy. These are ever-changing and evolving, so they should be a lower priority in influencing the CSP decision.
- A current or planned container strategy tends to gravitate towards GCP. However, containers on GCP are becoming more and more proprietary and less compatible with other CSPs and open source. As such, we would look at Azure or AWS to offer a more compatible multi-cloud container strategy.
- A predominantly fully-managed/serverless strategy tends to gravitate towards AWS for its broader range of services.
- If most of the organization’s applications are Windows-based, and strong enterprise Windows and 365 integration is expected, then Azure may be a good fit.
- Analytics workloads do well on all three providers. However, each is stronger in a particular area of data analytics. As such, the organization’s use cases should be well understood and compared with the offerings of each CSP to find the best match.
- Software development/DevOps, especially where local integration is concerned, tends to do well on Azure (visual studio) and GCP (Kubernetes)
- Data streaming and media tend to do well on Azure and AWS
- Many enterprise applications make use of Oracle databases. GCP does not support Oracle well, while Azure has very strong integration with Oracle.
All cloud providers have discounts and financial incentives. While all three are similar, this should be explored and compared as one of the considerations. For example, Azure offers to cover or reduce initial consumption costs, and AWS offers to partially fund the one-time migration and modernization costs of workloads. All CSPs offer volume and pre-paid discounts on their resources, something to compare and consider for the long-term cost implications of the planned workloads.
While a multi-cloud approach provides flexibility, it can also increase costs and security risks. A strategic approach to multi-cloud adoption can help to mitigate these issues, ensure consistency in security and governance across the CSPs, and help application teams deliver best practices on whichever CSP is deemed most appropriate for their application.
One of the primary benefits of multi-cloud adoption is its flexibility in workload placement and business use case alignment. By making multiple CSPs available, application teams can choose the best match for their application profile and requirements. This allows for greater agility and responsiveness, enabling businesses to adapt quickly to changing market conditions. That being said, in most cases a single cloud should be chosen for each workload. Running a single workload on multiple clouds is highly complex and would need a very strong case to justify the investment required. Code and infrastructure configuration for one cloud can not be used for another and will need recreating. Tools such as Terraform can make this easier by using the same configuration language, but still require configurations to be created for each cloud provider. It may be possible to meet multi-cloud disaster recovery (DR) requirements with a simplified version on a secondary CSP to reduce the risk exposure and cost.
Abstraction layers across multiple cloud providers that try and make this easier should be avoided, as their value is rarely justified by the complexity and effort involved. It also leads to using ‘the lowest common denominator’ between cloud providers, usually negatively impacting efficiency, cost, and security.Similarly, workload portability between different cloud providers is often not as easy as it sounds. Even minimal optimization for a particular cloud provider can make it significantly harder to move a workload to another one.
Another advantage of multi-cloud adoption is the ability to address the business, technical, and regulatory factors affecting infrastructure and application outsourcing arrangements based on the target jurisdictions. This helps businesses comply with local regulations and reduce data residency and sovereignty risks.
Maintaining commercial tension between Cloud Service Providers (CSPs) is another benefit of multi-cloud adoption. This ensures optimal commercial outcomes can be reached continuously through established procurement practices. It also enables businesses to negotiate better pricing and service level agreements with CSPs.
While multi-cloud adoption offers many benefits, it also presents several challenges. One of the drawbacks is the increased cost due to the duplication of effort of multi-cloud platform engineering with overlapping capabilities and maintenance overhead for each cloud platform environment.
Another disadvantage of multi-cloud adoption is the increased security risk due to a significantly larger attack and vulnerability surface across multiple cloud environments and the higher risk of knowledge gaps around securing each platform. This requires businesses to implement robust security controls and governance mechanisms to mitigate the risks and provide extensive training for each supported CSP.
Unrealized agility and efficiency gains from badly designed or misunderstood multi-cloud architectures are another drawback of ineffective multi-cloud adoption. This can lead to inefficiencies and duplication of effort, reducing the overall benefits of multi-cloud adoption.
Businesses should take a strategic approach to address the challenges associated with multi-cloud adoption. As with a single cloud adoption strategy, the goal is to remove the burden of effort from the application teams through platform-driven automation. This can reduce complexity, enforce consistency, and enable application teams to focus on delivering value to the business.
The approach to security, best practices, and similar targets differ slightly from a single-cloud strategy. Instead of designing the controls directly for the CSP, the organization should start with creating the directive controls as a single source of truth, applicable to all supported CSPs. The next step is then to determine how each directive can best be achieved on each CSP and identify any additional policies that may be needed for each particular CSP. Lastly, avoid creating soft silos within the CCoE focused on a particular CSP. Ensure such knowledge is spread among the domain-focused teams that must collaborate by design. For example, the security architect’s team should include subject matter experts for each CSP.
A central platform can allow for centralising common functions such as networking, billing, auditing, and security, reducing the onboarding and operational burden of individual applications. In a multi-cloud environment, some capabilities, such as the deployment pipeline and networking, will need to be implemented for each cloud service provider. While other capabilities, such as logging, alerts, FinOps, security operations, and the self-service portal, are often centralized outside the CSPs.
Some organizations consider having deployment pipelines and similar DevOps tooling in a single CSP and deploying to other CSPs from there. This is not recommended as it can incur significant data transfer costs and potentially expose sensitive code to the public internet.
A single deployment pipeline strategy also removes the opportunity to optimize the pipelines for each particular CSP and to embrace CSP-native tooling that may be more effective, especially for modern architectures.
In summary, when it comes to adopting a multi-cloud strategy, it's important to understand the benefits and drawbacks. While it can offer greater flexibility and the ability to choose the best CSP for each application, it also increases complexity, costs, and security risks. It's recommended that organizations begin with a single CSP before moving to a multi-cloud strategy. When selecting a CSP, it's important to consider strategic alignment and existing experience with the CSP, technical considerations are usually a lower priority for common workloads. A central platform can reduce the burden of individual applications, but some capabilities will still need to be implemented for each CSP. Overall, a strategic approach is necessary to address the challenges associated with multi-cloud adoption and to ensure that application teams can focus on delivering value to the business.
Don't miss out on unlocking the full power of the cloud.for a personalized consultation or to learn more.