When we conducted a survey of 300 technical decision makers (CTOs, senior architects, etc.) at companies in the US, UK, and Germany, we were surprised to find that half of their companies are already multi-cloud. Perhaps even more surprising, more than half of multi-cloud companies are already running at least one workload across multiple clouds.
These numbers could lead one to conclude that companies that aren’t already multi-cloud need to move now, or risk getting left behind by more innovative competitors. But reality is more complex than that. One of the major lessons from our recent multi-cloud report – which is the source of that survey data – is that multi-cloud isn’t right for everyone.
And just as important: even if multi-cloud is on your roadmap, that doesn’t necessarily mean that it’s a good idea to move to multi-cloud right now.
In this article, we’ll take a closer look at why multi-cloud might not be right for you. Note that we’ll be focused primarily on the idea of making your database multi-cloud as that’s our area of expertise, but much of the same logic will apply to other areas of your stack as well.
Need resilience? Availability? You probably don’t need multi-cloud.
Complex multi-cloud deployments are often discussed in the context of availability and resilience. This is particularly true in the context of relational databases, which often power mission-critical application systems and cannot go offline for any amount of time without significantly impacting a company’s bottom line.
But deploying a database across multiple clouds comes with significant technical hurdles. Even highly innovative tech companies tend to measure complex multi-cloud projects in years, not weeks or months. They’re also far more expensive than single-cloud deployments – moving data between different cloud service providers tends to be roughly 4-5x as expensive as moving the same data within a single cloud.
Given the costs in both time and money, you need a really strong use-case to make multi-cloud worth it. For most companies, resilience/availability is not a good reason to go multi-cloud.
For the vast majority of applications, four- or five-nines availability is good enough and achievable within the confines of a single cloud. And while the availability of a single-cloud multi-region database could be increased by moving to multi-cloud, those gains are marginal enough that such a move is typically only worthwhile for technical reasons in the case of mission critical, online-at-any-cost workloads.
So if not for resilience, why are so many companies multi-cloud? That question is answered in much more detail in our report, but the short version is that companies typically adopt multi-cloud for business reasons such as maintaining regulatory compliance or avoiding cloud vendor lock-in.
The database journey: legacy on-prem to distributed multi-cloud
Another reason multi-cloud isn’t for everybody right now is that depending on the current state of your application, trying to move to a multi-cloud deployment might be adding a hard problem on top of several other hard problems, which is a recipe for disaster.
To illustrate, let’s look specifically at databases. Below, we’ve outlined the typical relational database modernization journey we see among customers and prospects:
Not every workload needs to get all the way through to be multi-cloud, or even multi-region. Instead, most workloads and database modernization projects succeed with a one step at a time, crawl, walk, run approach.
That’s because taking each of these steps can be challenging:
Moving from phase zero to phase one typically means moving from an on-prem deployment to the cloud, and adjusting your database schema (among other things) to follow the best practices for optimal performance in a distributed system. CockroachDB is Postgres-compatible and comes with tools to make this kind of migration straightforward, but any migration still requires time and effort.
Moving from phase one to phase two introduces a new set of challenges when it comes to database performance optimization and latency.
Moving from phase two to phase three introduces many of the challenges inherent in working across clouds – there are many small differences between the public clouds that can make running the same workload across different clouds surprisingly challenging.
Jumping straight from phase zero to phase three sounds compelling – you could move from an outdated, legacy database to something that is wholly modern, cloud-native, globally scalable, and extremely resilient! But it would also mean having to solve all of the challenges associated with each step as part of a single project. And while CockroachDB comes with tools and a best-in-class team of support engineers to make traversing those steps as simple as possible, each one still takes time and effort.
Jumping from zero to three is, inevitably, a years-long project. And in our experience, that rarely works. Long, complex projects of that sort get abandoned for all kinds of reasons. Company leadership changes. Priorities change. Budgets change. The internal talent pool changes. So while “zero to three” might be your eventual roadmap, modernization projects are more likely to see success if they take it slow. One step at a time, one challenge at a time.
And it’s worth pointing out that as one moves rightward from phase to phase in that diagram, the benefits increase, but not exponentially, or even linearly.
In terms of resilience, for example, moving from a single-instance on-prem database to a distributed cloud database in a single region (phase zero to phase one) provides major benefits. The gains from one to two and two to three are more modest. Generally speaking, it’s not worth letting the complexity associated with multi-cloud (or even multi-region) prevent you from getting to phase one as fast as possible. Assuming that you’re starting from phase zero, the move from zero to one is likely to be the biggest “level up” of your entire cloud journey, so it’s definitely best to focus on getting that done and into production before trying to grapple with more complex challenges.
A database for your entire cloud journey
Modernization journeys like these are never easy. But one way you can make them easier is by choosing tools that can make the entire journey with you. Migrating from one RDBMS to another is – as anyone who has done one will attest – time-consuming even under the best of circumstances.
One of the great things about CockroachDB is that it’s built to work at any stage in your cloud journey: you can run it on-prem, on a single cloud, hybrid, or across multiple clouds. And because it’s Postgres-compatible and comes with a suite of helpful migration tools, it’s easier than ever to move from a legacy RDBMS to CockroachDB. From there, you can move from phase to phase at your own pace, knowing that CockroachDB will work for where you are now and where you want to go in the future.
