How to Simplify the Process of Building Multi-cloud Applications

Multi-cloud application deployments are increasingly common. In our State of Multi-Cloud 2024 report, we found that roughly half of the companies we surveyed were multi-cloud, and of those, half had already begun to experiment with complex multi-cloud deployment patterns such as deploying a single workload across multiple clouds.

But these companies often find that building multi-cloud applications is not easy. The major cloud providers may offer "squint-equivalent" services, but the devil is often in the details — even small, minor differences between clouds can make building applications that operate across them surprisingly difficult (and expensive).

As part of our research for the report, we spoke with quite a few expert engineers who have on-the-ground, firsthand experience with building multi-cloud applications. And while we would never say that building a multi-cloud application is easy, here are a few ways that the people who've actually done it say that you can make it easier.

Here are five key strategies for easier multi-cloud applications.

Establish Cloud Relationships Early

Onboarding with a new cloud provider takes time. There will be meetings and sales pitches to sit through. The earlier you can get this process started, the less likely it is that this onboarding red tape will impact your development timeline.

Related:5 Multi-cloud Security Challenges You Can Avoid

Establishing relationships early is particularly critical if you don't already have in-house expertise on the new cloud provider or providers you're planning to build with. Without internal experts, you'll need to rely more heavily on the CSP's support team, and it pays to start establishing those relationships and building trust early.

Hire People Who Know the Gotchas

One of the major challenges associated with building across multiple clouds is the variety of minor differences and idiosyncrasies between them. The engineers we spoke with said that even the CSPs' own support staff sometimes missed these — in one case, a CSP's support personnel signed off on an application design without noticing it would run afoul of that cloud's account limits, resulting in several months of lost time refactoring to address the issue after the fact.

Nobody can be familiar with all of the ins and outs of every cloud, but the easiest way to catch these sorts of things before they become major problems is to talk with people who have experience building multi-cloud applications similar to whatever you're trying to build. True, finding and hiring engineers with significant experience building multi-cloud applications is not easy or cheap, but it can pay major dividends in the long run.

However, following some of the other suggestions in this article may help mitigate the need to hire in-house experts. For example:

Choose Cloud-agnostic Tooling

Not so long ago, building a multi-cloud application meant having to solve a lot of the complex, make-this-cloud-work-with-that-cloud problems yourself. Now there are third-party tools built to support multi-cloud available almost everywhere in the application stack.

For example, Terraform is a cloud-agnostic infrastructure-as-code tool that facilitates management and orchestration of large-scale infrastructures across multiple clouds. Scalr is a cloud-agnostic tool that allows for the use of a single interface for managing resources across any cloud platform. CockroachDB is a cloud-agnostic distributed SQL database.

The best tools for your use case will vary, but there are a wide variety of cloud-agnostic tools available, and implementing them into your stack will often allow you to abstract away some of the complexities of working with each specific cloud.

Opt for Managed Services

Similarly, managed services can be a good option for abstracting away some of the complexities of multi-cloud deployments so that your team can focus on building your product. Managed services come at a cost, of course, but you should weigh this cost against what it would cost you (in terms of both time and money) to manage the service yourself, and what it would take to attain the level of expertise that would be required to ensure it remained performant.

For example, if you're primarily an AWS shop but you have a few database workloads that must be run on GCP, developing or hiring the expertise needed to onboard and manage your GCP workloads in-house could end up being quite expensive. It may be preferable to simply opt for a cloud-agnostic managed DBaaS and let your vendor worry about how to optimize their database's performance on whatever cloud or clouds you need it to run on.

Weigh Migration Carefully; Consider Net-New

It is certainly possible to migrate an existing application from single-cloud to multi-cloud, but such a migration is rarely fast or easy. Particularly in cases where a complex multi-cloud deployment is required — running a single workload across multiple clouds, for instance — it may actually be quicker and easier to simply build a net-new application you've designed from the ground up for this deployment.

Starting from scratch may also make it easier to swap in cloud-agnostic tools in various parts of your stack, eliminating much of the need to deal with the complexity of working between/across clouds.

Charles Custer is Senior Technical Content Marketer II at Cockroach Labs.