Just how good an idea is multi-cloud? If you follow the topic in online tech sites, you’d think that everyone was totally committed to multi-cloud, and that it was therefore the preferred approach. My own data, as I’ve noted in a prior blog, doesn’t agree with popular reports, and my own experience in hybrid and multi-cloud consulting and research suggests that there are issues with multi-cloud that often catch enterprises by surprise. Most of them could be significantly mitigated by simply planning properly.
Part of the problem with multi-cloud is deciding just what it means. To most, “multi-cloud” means the use of two or more public cloud providers, with “public cloud provider” meaning a provider of a cloud service. Since SaaS is a cloud service and Salesforce’s offerings are widely used, this tends to make everyone who uses another public cloud, like AWS or Azure or Google or IBM, a multi-cloud user. I don’t think that’s a helpful definition, so what I propose here is that we ignore SaaS in the determination of multi-cloud. SaaS should be, from a security, integration, and operations perspective, be considered separately anyway.
According to my research, and mindful of my definition above, multi-cloud usage divides sharply based on motivation. The largest multi-national corporations tend to use multi-cloud because they can’t properly cover their global market area with a single cloud provider. Among this group, comprising perhaps a thousand companies globally, multi-cloud is almost universal. The other motivation is for backup, and here there are perhaps another two thousand companies spread across a wider size range.
A universal issue in multi-cloud is security. As THIS Light Reading piece notes, there are security issues associated with multi-cloud, but they emerge from multiple sources and have to be addressed in different ways depending on cloud usage.
The universal security issue for multi-cloud is increased attack surface. An “attack surface” is the number of places where possible attack exposure exists, and obviously the more clouds you have, the more attack surface you have. Every cloud provider has security risks, so the more providers you have, the more risks you’re exposed to. It’s almost always possible to mitigate some of these risks, but not all of them. An internal flaw in a cloud provider’s own shield compromises users, and can’t be fixed easily by those users.
A second fairly common multi-cloud security issue is differences in cloud provider architecture can make it difficult to create a common secure framework across provider boundaries. If you write some components for optimal performance in AWS, the differences in how the web services are invoked and managed will mean that the same code almost surely won’t run on Azure. There are now two versions of the code, and that means two places where you have to deal with security and two different ways that has to be done. The cloud-specific code problem bites in other areas, as we’ll see.
A related problem is that shedding cloud-provider web services to promote a common code set across clouds (sticking to vanilla IaaS and adding in your own middleware for containers, IoT, and so forth) puts a greater security burden on the user. All platform tools have the potential to open security holes, and if users have to supply everything above a naked virtual machine, there are plenty of places they could mess up. Thus, the user is often forced to choose between using cloud-provider web services and accepting the higher cost and loss of code portability, or rolling their own platform toolkit and accepting a risk they’ll fail to consider security and operations challenges.
The other common problem with multi-cloud is operations and code compatibility. As I suggested above, multi-cloud users are often stuck with a choice between building their own cloud middleware and then deploying it across multiple clouds, or keeping different application versions to account for the difference between web services in Cloud A and Cloud B.
Companies who adopt multiple clouds for multiple geographies alone will often be able to maintain independent code for each cloud, because there’s no expectation of redeploying components of applications across cloud boundaries. Even in cases where one cloud is expected to back up another, enterprises say it’s often possible to maintain separate application components for each cloud, either because no cloud-provider features other than basic hosting are used, or because the cloud components aren’t changing rapidly enough to create a development bottleneck. Things are more complicated if multiple clouds are seen as a part of a common resource pool, allocated freely as needed.
As we get into more complex cloud-native applications, it’s going to be very difficult to maintain multiple application versions. Many experts agree that the future of cloud computing is a unified cloud resource pool to which everything contributes, including enterprise data centers and multiple cloud providers. Even bare-metal hosting providers are likely to get enveloped in this concept, but it poses pretty significant challenges.
The most obvious challenge is the need to define a single application platform (a PaaS, in a real sense) that can be deployed onto everything, so application components can be hosted freely on whatever is best, without changes in the code or in operating practices. Container architectures (Docker, Kubernetes, and the rest of the ecosystem) are the best underpinning for this sort of thing, since virtual machines provide too much latitude to customize middleware, making application portability problematic.
Even with containers and the whole of the Kubernetes ecosystem, there’s still the problem of those web services offered by cloud providers. Every cloud provider knows that basic IaaS is a commodity, meaning it’s under tremendous price pressure and it offers no “stickiness” in holding a customer in once they’ve committed. Adding custom web services encourages applications to depend on them, so making the applications portable is the opposite of the cloud provider goal.
We are moving, slowly and irregularly, to develop a set of tools that are cloud-provider-independent. Knative is a deployable serverless toolkit that at least somewhat replaces cloud provider serverless/functional computing services. We also have deployable database and cloud storage options that replace cloud provider tools, and there are even specialized tools for IoT and other applications. The problem with all of these is that they need to be integrated, which even large enterprises find difficult.
The net of this is that multi-cloud can’t reach its full potential unless there’s a single, integrated, alternative to cloud-provider web services, a suite. That can come only from a software vendor who builds out from the Kubernetes ecosystem, and who has credibility with enterprises as a platform provider. The obvious contenders are IBM/Red Hat, VMware, and HPE. Other up-and-coming possibilities would include Suse, who just acquired Rancher.
The major suite players are already striking alliances with cloud providers, creating a hybrid cloud framework that’s actually a multi-cloud web service suite in disguise. If Cloud A and Cloud B can host OpenShift, for example, and so can enterprise data centers, then ultimately Cloud A and Cloud B can become commoditized by the loss of their own web-service differentiators. This could be the way that the suite vendors gain cloud ascendency.
Or not, of course. There’s a lot of work to be done turning the limited cloud suites of today into full-blown web-service alternatives for hybrid and multi-cloud. The fact that the reward for success here would be truly enormous, even transformational to the industry at large, means that it’s very likely that every suite vendor will take a shot, and at least one might succeed.