The term “Multi-Cloud” has been popping up in a few places over the past year. Its meaning is muddled along with various other terms such as “Public-Cloud”, “Private-Cloud”, “Hybrid-Cloud”, “Cross-Cloud”, and if you search the Gartner IT Glossary you’ll probably find a few more.

Put simply, Multi-Cloud is the use of multiple cloud providers to provision various services across an IT estate to reduce the reliance on a single cloud vendor.

 

Why Multi Cloud?

Let me start by saying that supporting multiple cloud platforms is not a step that should be taken lightly, especially where there are big compliance or security concerns. There is some effort involved in implementing a multi-cloud strategy, and definitely not a decision that should be made without good reason.

However, organisations invest significant time and effort to abstract their applications away from a single cloud platform so that if the time comes, they’re able to move more quickly and easily than if their applications were tied to specific services.

This often means that the full benefits of some of these services are then lost. For example, using IaaS virtual machines for items that could be quite easily hosted on PaaS features that would remove some of the patching and updating overheads. Hosting across multiple clouds could help alleviate some of these concerns. So what are the reasons for taking this approach?

Mitigate Vendor Lock-In

Large organisations avoid vendor lock-in for various reasons. There may be factors such as cost, influence / leverage, security, financial stability or even the ability innovate.

Interestingly we are talking about some of the largest vendors on the planet here, namely Microsoft, Amazon and Google, but a number of other suppliers are making huge ground with their cloud offerings such as HP, Fujitsu, IBM and Oracle.

Use Application Services Where They Excel

By managing applications across multiple cloud platforms, organisations are able to place an application based on its requirements rather than having to use a cloud platform because its the only one in place. For example, an application with specific storage requirements might want to use AWS S3 for it’s versioning capability and lifecycle policies, whereas an application with image and speech recognition requirements might prefer to use Microsoft Azure Cognitive Services.

By removing (or at least lessening) the limitation on where an application is hosted, developers and architects are able to use what’s best for the application or service itself.

Increased Resiliency Against Failure

There haven’t been any major cloud outages for a while now (touch-wood!) and although there are no guarantees, you would hope that if we were any outages any time soon, that we wouldn’t be unlucky enough for it to affect multiple regions, yet alone vendors.

Research suggests that firms are either confused, or woefully unprepared for a cloud outage.

SLAs with major cloud vendors mean practically nothing compared to the impact of a total service outage of a mission critical application. Usually you would receive a credit of a small percentage of the instance cost. That said, uptimes are pretty good with reports of 100% in some areas of the globe. Using multiple vendors could be seen as “hedging your bets” if an application is critical to a business function, but you would need to think very carefully about what the risks are and balance them against the effort required.

Leave Legacy Apps In Place

Are legacy apps too risky or complex to migrate? Why not leave them in place? These systems shouldn’t stop you from using the best services for your newer applications. By adopting a Multi-Cloud approach, legacy applications can stay where they are, potentially even accessing data or using services from another cloud tenancy without involving a risky migration.

Ability to Use Services Where They Are Cheapest

Amongst the three major cloud providers (AWS, Azure and Google), the cheapest will differ based on the specific scenario. For example Windows machines may be up to 82% cheaper if you can make use of the Azure Hybrid Benefit discount scheme (requires an Enterprise Agreement) or if you’re able to make use of Reserved or Spot Instances in AWS.

How?

Cost / Benefit

The benefits listed above must be balanced with the costs to plan and implement multiple cloud deployments. This certainly isn’t a decision to be made lightly, and businesses need to decide on where their risks are, where they are able to achieve the most agility in their services and applications, and have a solid reason for needing to take this approach.

Acknowledge the Extra Effort Required

Inevitably there will be extra effort, doubling up on infrastructure for example AWS Direct Connect and Azure ExpressRoute for routing connections from on-premise, VPN connections into each cloud tenancy, training for infrastructure staff and development teams. Logging, monitoring and auditing may also be duplicated.

Its important to ensure everything is well-documented, ensuring that everyone knows where key parts of the infrastructure as well as applications themselves are located.

Use the Right Tools

Tooling such as HashiCorp Terraform enables infrastructure to be defined as code. Not only does this mean that application infrastructure can be checked into source control alongside application source code, evolving as the application does, it also means that the same language used to define an AWS infrastructure can be used to define Azure, Oracle or Digital Ocean infrastructure. It’s not quite as simple as changing the name of the cloud platform, but it does mean that a development and operations team will become familiar with both the semantics / syntax and the process used to deploy, regardless of the deployment target.

Chef can also help consistency across cloud VMs, as well as auditing the entire estate ensuring that security requirements are met across all cloud platforms and configuration changes are made when issues such as Heartbleed, WannaCry and Spectre.

Leverage Architecture and Development Design Patterns

With the right patterns in place, vendor specific implementations within code can be abstracted away from business logic, meaning high levels of code re-use and (hopefully) simple configuration changes when deploying across multiple cloud platforms.

This in itself may negate the need for multicloud entirely if the business is satisfied that it’s developers are able to use the correct patterns to ensure applications are easily moved to other cloud platforms as and when a decision is made.

 

In Summary

Adopting a Multi-Cloud strategy can provide a huge amount of flexibility in terms of cost, functionality and resiliency, but it requires careful planning and a pragmatic approach to application features and deployments to effectively leverage its benefits. It also needs careful consideration on if this approach is needed, since there’s a fair amount of additional effort required and many of the benefits can be achieved by other means.