Everyone’s in love with multicloud these days. You can hardly read a tech blog or attend a tradeshow without hearing about how multi-cloud architectures increase flexibility and reliability while lowering costs.
In theory, at least, those promises hold true. But in practice, there is a significant obstacle preventing many businesses from actually reaping the potential benefits of multicloud architectures. That obstacle is the fact that tooling has yet to catch up with the multicloud age.
In other words, despite all of the intense interest in multicloud and the fact that many organizations have started adopting multicloud architectures, the way we discover, launch, and use tech tools is predicated upon the assumption that developers still go all-in on one cloud. From the perspective of tooling, the idea that you might want to use more than one cloud at the same time remains an afterthought.
Let me explain the nature of this problem and what it will take to solve it.
Multicloud conundrums in a single-cloud world
Let me start by making one thing clear: When I say the tech ecosystem has not yet caught up with the multicloud phenomenon, I don’t mean that we lack tools that can work with multiple clouds.
That’s obviously not the case. It’s not as if you need to use one APM or security monitoring tool for AWS and another for Azure and GCP, for instance. In most cases, any modern third-party tool supports every major cloud platform.
However, what is different depending on which cloud or clouds you use is the process of setting up and using a third-party tool. Typically, you have to go through a different set of steps to connect a given tool to each cloud that you want to include in your multicloud architecture. What’s more, you need to juggle different cloud identities, API keys, and so on for each cloud that you use. And you need to repeat the integration process whenever your account information changes.
Additionally, the process of using a third-party tool on one cloud could be different than on another cloud. You might need to configure different types of rules within the tool or customize the data collected from each cloud.
And if your multicloud environments include additional layers running on top of the underlying clouds (like Kubernetes), that adds yet another set of integration steps and custom management that you need to deal with.
All of the above means that achieving the flexibility and reliability benefits that multicloud theoretically confers can be a real challenge. You end up spending so much time installing and customizing your toolchain for each cloud that you lose the ability to operate in an agile fashion across multiple clouds.
Dreaming of a better multicloud world
How can we fix this state of affairs? The basic answer is simple: Build an abstraction layer that lets developers find and set up cloud services on top of a multicloud architecture in a way that is agnostic toward the underlying clouds.
Developers and IT teams shouldn’t have to download or launch each tool that they want to use with their multicloud environments from a separate place. They should be able to find them all in one location. Once launched, the tools should automatically configure themselves to work with whichever cloud or clouds compose the users’ infrastructure, saving the need for custom provisioning within each cloud.
You may be thinking, “That sounds great, but public cloud providers are never going to collaborate to make it happen.” That’s a fair point. It’s unlikely that AWS, Azure, Google, and other major public cloud vendors are ever going to come together and build some cloud-agnostic abstraction layer that would standardize tool deployment across all clouds. There is little financial incentive for one cloud provider to help customers use its cloud along with competitors’ clouds.
Such an abstraction layer is possible to achieve in another way, without relying on the cooperation of cloud vendors. What needs to happen to make it a reality is for tool vendors to change the way they approach application deployment and management. Instead of requiring developers to come to vendors’ websites to find tools, or to look for them in app repositories that are built into each public cloud, vendors can make their tools available from cloud-agnostic marketplaces.
In a cloud-agnostic marketplace (which is the opposite of a cloud-specific market, like AWS Marketplace), development teams could easily discover any tool that they need to deploy on any clouds within their multicloud architectures. Also, tool vendors could abstract-away the deployment and configuration processes for their tools in such a way that the deployment could be initiated directly from the marketplace, then automated to apply to each cloud that the development team wants to target.
This approach would solve the problem of having to follow a different discovery, setup, and configuration process for each cloud that you need to support. It would bring us closer to a world where teams can fully capitalize on the opportunities provided by multicloud architectures.
A change of this nature might sound far-fetched. But I’d argue that it wouldn’t require as much radical change as you might assume, given that it’s not just cloud users who would benefit. Tech vendors, too, have good incentives for adopting a cloud-agnostic marketplace model. It would make their tools easier for their customers to find and set up, while also making it easier for the vendors to support multiple public clouds using a centralized interface. Vendors would no longer have to maintain separate portals for each cloud they support.
When the needs of users and vendors align, change happens. That’s why I think we’ll see the era of the single-cloud ecosystem come to an end, as tool vendors make it much easier for the developers who use their products to deploy and use their tools on multiple clouds at once.