An Introduction to Multicloud Strategy

Companies turn to a multicloud strategy to let them pick the best cloud service for their particular needs. But figuring out how to make such a strategy work is harder, and more rewarding, than simply hiring a consultant to come in and wave multicloud pixie dust on your application infrastructure.

SEE: What Is Multicloud Architecture? (TechRepublic)

Table of Contents

An overview of multicloud strategy

Enterprises have been multicloud almost from the beginning, but not always intentionally. Just as shadow IT has for decades resulted in enterprises deploying an unmanageable mishmash of databases, operating systems, and app servers, so too has the easy availability of cloud services resulted in one team embracing Google Cloud while another uses AWS and still another runs Microsoft Azure. This isn’t strategy, it’s just enterprise IT.

Increasingly, though, enterprises are becoming much savvier and intentional about running multiple clouds to get best-of-breed services, lower costs, and greater flexibility to move services more geographically proximate to users.

SEE: Hiring Kit: Cloud Engineer (TechRepublic Premium)

Common use cases for a multicloud strategy

By far the most common reason enterprises choose a multicloud strategy is to take advantage of particular services only available on a given cloud. This is also the best reason to pick a multicloud approach.

Other use cases include a desire to improve resilience and reliability, but this is often harder to implement in practice than to argue in theory. The reason? With one cloud you need to worry about uptime for that cloud, but with two or more clouds, “now you have to worry about AWS, GCP, and the unholy plumbing between them,” argued Honeycomb co-founder and CTO Charity Majors.

SEE: Multicloud vs Hybrid Cloud: Which One Is Right for Your Organization? (TechRepublic)

How do you develop a multicloud strategy?

Moving to a multicloud architecture is not a decision that should be entered into lightly, as it can introduce significant complexity. Enterprises that want to reduce that level of complication can turn to SaaS providers that take care of the burden of managing databases or other infrastructure across diverse clouds. However, they need to keep in mind that successful deployments depend upon architectures that span application and data tiers.

To see how multicloud strategy has been deployed most successfully, it pays to check out how the richest, most sophisticated companies operate, as SADA CTO Miles Ward has written. What do X (formerly Twitter), Snap, Uber, and others have in common? Among other things, they’ve moved from monolithic architectures to microservices. This allowed them to optimize for developer freedom, even while limiting the blast radius of when services failed.

It also made it easier for them to pick and choose the best cloud for a particular service. For Snap, it has become a cardinal design principle to “make the services as narrow as possible” to make it easier to back those microservices with particular cloud infrastructure.

In fact, several key Snap design principles provide solid footing for any company’s multicloud strategy:

Secure by default: Authentication, authorization, and network security should be defaults, not optional, within the platform.
Clear separation of concerns between services’ business logic and the infrastructure. We want loose coupling, so each side can iterate independently.
Abstract the differences between cloud providers where we can. We want to minimize deep provider dependencies so it’s feasible to shift services between AWS, GCP, and other cloud providers.
Centralized service discovery and management. We want all service owners to have the same experience for owning a service, regardless of where the service is running.
Minimal friction for creating new services. An intern should be able to stand up a productionized service by lunchtime.

Of course, most enterprises will lack the resources to build exactly as Snap does. For mainstream enterprises, it can be useful to start small, perhaps choosing a SaaS provider that handles the multicloud complexity for you, or simply beginning by rearchitecting a monolithic app to be microservices-oriented. One benefit of this latter approach is that it puts the enterprise in a good position to push your cloud provider to compete for the right to run individual microservices.

In embarking upon a strategy, it’s also important to consider different aspects of your application infrastructure. Some cloud services are pretty standard across clouds, others are very particular to a distinct cloud. And then there are still other services that may be mostly the same between clouds, but will require engineering work to bridge the gap between.

You’ll need to determine how much you’ll want to depend upon higher-order services within a particular cloud. The more you depend on a service, the more dependent you become on that cloud. At the same time, the more you’re able to depend on a cloud’s value-added services, the less your developers will need to spend time innovating in that area. There’s no right or wrong answer — just a series of multicloud choices to make.

SEE: A Brief History of Cloud Computing (TechRepublic)

Key success metrics in a multicloud strategy

Looking back to the Snap design principles, enterprises should develop and rigorously monitor network performance, security, and application availability. Enterprises should also track costs to know, for example, whether a microservice running on AWS would be more affordably backed by Microsoft Azure. Ultimately, however, the best way to tell if your strategy is working is whether you’re able to affordably run the best services for your customers.

SEE: What Is Public Cloud? (TechRepublic)