How to Maximise Benefits from Multi-Cloud Adoption

A recent study by Flexera, showed that 92% of enterprises have a multi-cloud strategy. In this blog post I will cover:

• Reasons for adopting a Multi-Cloud strategy
• Risks& Challanges
• Common Multi-Cloud Architectures
• Recommendations

Let’s get to it!

The WHY

Avoid vendor lock-in

Many cite avoiding vendor lock-in as the reason for a multi-cloud strategy. This strategy often drives organisations to use the lowest common denominator to reduce lock-in and improve application portability. There are two issues with this approach. First, using the lowest common denominator will deprive organisations of benefits from the advanced native cloud services, which provide the most business value. You are trading business value for portability.

The second issue, this approach, means you are trading one lock-in for another. For example, many will use VMware virtual machines running on AWS and Azure. VMware in this scenario is the new vendor lock-in.

Use the best of breed

This is one of the most common use cases for Multi-Cloud adoption, I see. Organisation will run certain workloads on one cloud and utilise a native service on another cloud. For example, you see organisations utilising Google’s (GCP) Artificial Intelligence (AI) while using and Machine Learning (ML) their business applications on one Azure or AWS and using GCP for its advanced analytics capability.

Negotiate better pricing

Many organisations believe they can negotiate favourable pricing if they can show they have the option to use multiple cloud providers. Based on my experience, this negotiation tactic hardly ever works. Cloud providers, especially the big three, offer discounts based on volume and commitment. The more you give them, the better pricing they will give you.

Regulatory Compliance

Financial services regulators in the EU, are concerned about the concentration of risk in the form of 3 hyper-scale cloud providers. This concentration of risk is driving organisation to adopt a multi-cloud strategy. However, based on my experience, cloud exit planning is complex and will need a thoughtful strategy and careful execution.

Improve regional performance

Although the big three cloud providers have overlapping coverage across the world, some organisations have unique location requirements. Ali Baba has more locations options in China and it is a favoured choice for those looking to be as close to their customers in that region.

The reasons above do sound appealing enough. However, we need to look deeper to identify risks, constraints, and costs associated with Multi-Cloud.

The WHY NOT

Inflated Costs

Costs fall into two categories: implementation costs and operational costs. Implementation costs for two clouds are 40-50% higher than a single cloud deployment based on my experience. Operational costs are also higher. You have to adopt third-party tools to manage multi-clouds and hire and cross-train your operations teams. All these will increase your operational costs.

Reduced Leverage

The more you spend with a cloud provider, the more volume discounts and attention you receive. Dividing your workloads across multi-clouds will reduce your leverage and result in a higher cost.

Increased Complexity

Multi-Cloud architecture is typically more complex than a single cloud architecture. The added complexity increases the number of potential risks, from a security, compliance, and cost overrun perspective.

Lack of Interoperability

As organisations attempt to move data and applications between multi-clouds, the lack of interoperability becomes a major hindrance. Native services are difficult to replicate on another cloud. Native security and monitoring tools do not work across other clouds. This increases the complexity and cost of operations. You will need to consider deploying third-party tools that span multiple clouds.

Scarce of Expertise

Finding skills for one cloud provider is a challenge in today’s marketplace. Finding experts in multi-cloud strategy, architecture and deployment is a rare find. Before you embark on a Multi-Cloud journey, you need to ensure you have the experts at hand.

Common Multi-Cloud Architectures

Random Multi-Cloud

Often Multi-Cloud Strategy lacks .. strategy. Instead of using a decision framework, the selection of cloud vendors is random. I often see this happen because of the lack of governance and/or persuasive vendor salespeople. In my experience, in these organisations, engineering leads and projects have the final say in the choice of technology.

This random approach can lead to an increase in risks, costs, and operational complexity. This is the one pattern I advise clients to avoid, like Covid-19!

Segmented Multi-Cloud

In this architecture, specific workloads are placed on specific clouds. This approach is superior to the random architecture as it offers a systematic approach based on agreed segmentation criteria. Examples of segmentation criteria I have used with this architecture:

• Running IaaS workloads on Cloud X and PaaS on Cloud Y.
• Running customer facing apps on one vendor and internal applications on another.
• Running customer applications on vendor X and analytics on vendor Y.
• Net new applications on one cloud and legacy applications on a different cloud.

Organisations need to watch out for in this approach is applications dependencies. If you have dependencies between applications running on different clouds, you could end with unexpected costs from egress traffic between the different clouds.

Redundant Multi-Cloud

In this architecture, multiple instances are running on multiple clouds. There are two versions of this architecture:

In this architecture, the workload is continuously replicated between two different clouds. The setup is often active-active where instances on both clouds are in continuous use. The alternative is active-passive, where an application runs on one cloud, and any spike in consumption (batch job), can run on the cheaper cloud provider at the time.

Redundant architecture is increasingly being adopted in financial services in the EU to comply with regulatory guidelines on mitigation against the concentration of risk.

With redundant architecture, testing is a key to ensure cloud X can take over if cloud Y suffers a catastrophic failure.

Amalgamated Multi-Cloud

In this architecture, a single workload’s components are distributed between different clouds. An example is a web server running on AWS while SAP system is hosted on Azure. With this architecture, organisations need to ensure that latency-sensitive components are kept together on the same cloud. With this architecture, there is a higher chance of an outage due to having multiple clouds hosting different components from the same applications. In my experience, no replication can keep data up to date which means in an outage scenario, there will likely be a data loss.

Recommendations

Those involved in Multi-Cloud strategy and architecture should:

• Answer the key question: Why Multi-Cloud? You are about to increase the complexity of your cloud adoption, what are you getting back in return? You need to quantify the value of multi-cloud, such as increased agility and best-of-breed multi-cloud offers.
• Build a business case. Articulate the problem, the opportunities, business outcomes and relevant KPIs. This will help win needed buy-in from the senior leadership in the organisation.
• Idenitfy common grounds between cloud providers. Key services such as monitoring, security, governance, cost management and operations cannot be kept as native services. In my experience, third-party cross platform tools are often used to provide a holistic view of multi-clouds and reduce complexity.
• Balance portabaility with business value. Identify applications that require portability and design them for portability between clouds. Applications that require innovation should be kept on one cloud to take advantage of advanced native services.
• Start with one provider. If an organisation is new to public cloud, then I would strongly suggest it fights the urge to jump straight from on-premise to multi-cloud. A single cloud represents a drastic change in technology, processes, and people. Jumping to multiple cloud from the start is asking for trouble.

The trend today is Multi-Cloud. However, business success, relies on the speed, reliability, quality and innovation of applications that you offer your customers. This should be the driver of technology decisions rather than following a trend.

I hope you have found the post informative and thank you for Reading & Sharing.

Regards,

Nick