What is Multicloud?

An organization takes a multicloud approach when it uses cloud services from more than one provider. That might seem obvious from the name—it’s multiple clouds, after all—but the reasons for choosing a multicloud approach can be as varied as the cloud platforms themselves.

Because “cloud” has become such a broad and all-encompassing category, a multicloud environment might include, say, Microsoft 365 SaaS for productivity apps, Google Drive for storage, and Amazon AWS for compute services.

On the other hand, organizations might have a reason to turn to multiple cloud providers for the same function or purpose. And public cloud services are so cheap and easy to get started with that large organizations (or organizations that don’t have tight centralized control over IT) might find themselves in a multicloud situation without ever intending to.

What is the difference between multicloud and hybrid cloud?

Before we discuss the pros and cons of multicloud, it’s important to differentiate multicloud from a similar-sounding term with a different meaning.  A hybrid cloud deployment is one that straddles both public clouds and a private cloud component hosted on-premises.

An enterprise could be hybrid multicloud if the infrastructure includes services from multiple public cloud vendors—in fact, this is a fairly common hybrid cloud use case. But unless there are multiple public cloud vendors involved, it’s not multicloud, even if you’ve got public and private components.

What are the benefits of multicloud? 

The concept of multicloud might seem counterintuitive. After all, isn’t it better to keep things simple by sticking with one cloud vendor? But sourcing cloud services from multiple vendors has a number of advantages:

• Flexibility: While most cloud vendors pitch themselves as a total cloud solution, the truth is that each major offering has strengths and weaknesses, and companies may not want to commit to one vendor if they have multiple cloud use cases.

For instance, an organization might use Microsoft’s Azure cloud for its analytics capabilities, but Amazon’s AWS to develop Alexa Skills applications. Even workloads developed to be theoretically vendor neutral may see better performance on different cloud platforms.

• Proximity and network performance. The whole notion of the cloud entices you to think of a cloud server as being somewhere “out there,” unconstrained by the limits of physical reality. In practice, some cloud vendors are going to be able to offer cloud servers that are physically closer to your users and customers than others, or that have a network connection to them with lower latency. You might want to turn to those providers for mission-critical, high-performance needs while using others as appropriate.

• Keeping your eggs in multiple baskets. If your cloud provider were to suffer a massive and prolonged outage, that would have major repercussions on your business. While that’s pretty unlikely if you go with one of the hyperscalers, it’s possible with a more specialized vendor.

And even with the big players, you may discover annoyances, performance problems, unanticipated charges, or other issues that might cause you to rethink your relationship. Using services from multiple vendors makes it easier to end a relationship that feels like it’s gone stale without you having to retool your entire infrastructure.

 It can be a great means to determine which cloud providers are best for which workloads. And it can’t hurt as a negotiating tactic when contracts expire or when you’re considering adding new cloud services.

What are the multicloud challenges?

There are a number of challenges and drawbacks associated with the multicloud approach:

• Complexity: This is the number one problem with multicloud. One of the promises of a single-vendor cloud setup is that you can simply spin up more cloud resources in a seamless way that doesn’t require additional work or rearchitecting on your part.

 If you add more cloud resources by adding services from a different vendor, you’ll need to put in extra effort to get the two clouds to play nicely together, a process that can range from “annoying” to “impossible.” Even after bridging the divide, there’s administrative overhead involved—it’ll be harder to keep tabs on data protection and privacy, for instance, and you’ll need to track cloud usage and the associated costs for multiple vendors.

• Network bandwidth. Many vendors make it cheap and easy to move data to and within their cloud, but might make you pay a premium to export it. If your workflows require sending big files back and forth across cloud providers, you could find yourself paying more than you expect.
• Interoperability: The reality is that commercial cloud services aren’t just abstracted generic white box servers. They each have their strengths (which is probably one of the top reasons why you’re choosing a multicloud strategy to begin with) but they also each have their quirks, and complex applications will have to be tailored to a specific cloud environment to a certain degree. In other words, you can’t just move your code from one cloud provider to another on a whim.

• Skills gaps. It’s not just code that doesn’t necessarily port across different cloud services; your human programmers and admins also probably have cloud platforms they prefer, or at least are more familiar with. Anyone can learn new skills, of course, but juggling different platforms will mean a learning curve for your team, and may make it difficult to hire folks who can jump in quickly with both feet.

How to address multicloud security

One final multicloud challenge deserves special consideration: security. A multicloud environment represents a large and complex attack surface. Any cloud rollout creates risks of opening up vulnerabilities to attackers: you’ve got data going back and forth between cloud and on-prem systems across the internet, and you’re storing and working on that data on a platform you don’t fully control.

Adding more public cloud providers to the mix means more network connections that need to be secured. And while most cloud platforms include security tools, the tools from all your providers won’t necessarily work with one another.

In short, you’ll need to ensure that all users are following safety best practices at all times, put together a comprehensive data governance policy in advance of any rollout, and use whatever tools you can to gain full visibility into your sprawling, multicloud infrastructure.

What are multicloud design considerations?

One of the keys to designing a multicloud architecture is building up a common technology stack and development toolchain that can be ported to as many of the public clouds you use as possible. A good strategy is to focus your efforts on using open source software packages, as these generally are portable across any public cloud vendor—and to use the most generic “vanilla” version of the tools that best fit your need. Simplicity and portability are key.

You’ll also want to unify infrastructure-wide policies to the extent you can. When possible, do this by building front-end code that can interact with your platforms’ APIs to abstract your policies away from specific implementations on specific platforms.

In this process, you’ll need to figure out if you want to come up with a common set of features that you’ll use across all your public clouds that can be manipulated via APIs. Doing so makes management easier—in many cases your users won’t need to know which cloud platform they’re dealing with at any given moment—but you also lose the unique capabilities of each cloud that may have you driven you to a multicloud environment in the first place.

There are commercial multicloud orchestration platforms that can help you keep everything running smoothly once you’ve rolled it all out, and choosing one should also be part of your planning process. Flexera Cloud Management Platform and BMC Multi-Cloud Management are two leaders here, but many more offerings are available.

How to deal with shadow IT

No matter how you plan for a multicloud rollout, it’s critical that you do, in fact, have a plan. But the truth is that many organizations may already be multicloud shops, without any planning and without even being aware of it, thanks to what’s known as shadow IT—when individual departments or business units procure their own tech services without consulting the IT department.

It’s very easy and not particularly expensive to sign up for a cloud account, and many departments will do it if they feel that IT practices act as a productivity barrier. For instance, IT may roll out Google Cloud enterprise-wide for storage and file-sharing, only to discover that the  legal department has been using Dropbox for these purposes for years, is comfortable with it, and doesn’t want to give it up.

To avoid this sort of problem, you need carrots and sticks: set company-wide cloud policies on what individual department can and cannot do when it comes to creating new cloud accounts, but also listen to those departments to find out what they need, and try to figure out how the tools they’re comfortable with can be integrated into your larger cloud or multicloud strategy.

In the long run, getting everyone on board is the key to success for a multicloud rollout.