Companies move to the cloud to take advantage of a wide variety of benefits, but building your infrastructure on a public cloud also comes with risks. Chief among them is vendor lock-in and the fear of being at a single cloud provider’s mercy, locked in behind what would be the months or years of work necessary to switch to a different cloud.
But operating across multiple clouds at the same time is technically difficult and often prohibitively expensive. Many companies have embraced a different way of mitigating the lock-in risk: cloud portability.
What is cloud portability?
Cloud portability refers to the ability to quickly move things – applications, workloads, data – between cloud environments. It can mean moving from a private cloud to a public cloud (or vice versa), or it can mean moving from one public cloud provider to another.
For example, imagine an application is deployed to AWS, but the company has decided to move to GCP. An application that has been architected with cloud portability in mind would be able to make this shift relatively quickly and seamlessly, with minimal downtime and minimal need to refactor code. Migrating an application from one cloud to another is never going to be painless, but cloud-portable architectures and tools help to minimize that pain.
In contrast, an application that has not been architected with cloud portability in mind will likely require significant time and effort to shift, as elements of the application will need to be refactored and tools may need to be swapped out to ensure compatibility with the services offered by the new cloud. Depending on the size of the company and the application, this is likely to require months or even years of effort.
This is because while the major public clouds look more or less feature-identical in a “squint test,” each has its own idiosyncrasies when you get down into the nuts and bolts. Google Cloud Functions, for example, may offer a very similar end product to AWS Lambda, but swapping your application from one to the other is still quite a bit more involved than simply copy-pasting code.
The aim of cloud portability, then, is to make that sort of move as simple as reasonably possible.
Cloud portability vs. cloud interoperability
The term cloud portability is often used in tandem with cloud interoperability, but they mean slightly different things.
Cloud interoperability refers to the ability of systems to work together across multiple clouds. Cloud portability, again, is about moving something from one cloud to another.
In other words, for example:
Cloud interoperability: “We want to be able to run our database on AWS and our application on GCP.”
Cloud portability: “We want to be able to move our database from AWS to GCP.”
In an ideal world, companies would have both, but maintaining interoperability and portability across every level of an application is both difficult and expensive. Interoperability, in particular, may not be needed unless you aspire to build an application with a multi-cloud architecture such that some of your services will need to communicate and coordinate operations across multiple cloud deployments.
Multi-cloud interoperability is a different and complex topic; in this article, we’ll focus on portability.
Why do companies want cloud portability?
There are a number reasons why cloud portability is appealing, even to companies who want to maintain a single-cloud deployment and are happy with their current cloud provider:
Maintaining flexibility. Being cloud-portable means being able to shift quickly in response to market forces, and take advantage of opportunities such as better pricing or discounts on a competing cloud provider.
Mitigating risk. Without cloud portability, you are locked into a single vendor, which represents a strategic risk to the business. If a cloud vendor raises their prices, or makes changes to services or support that are critical to the business, a company without cloud portability will not be able to respond quickly.
Increasing leverage. Even if they don’t plan to change clouds, being easily able to do so can give a company significant leverage when negotiating contracts with their cloud vendor.
Fostering innovation. Maintaining cloud portability makes it easier to experiment with new cloud products and services as they arrive so that you can quickly determine whether they offer advantages for your business.
In truth, if you’re building a net-new application from the ground up, there are very few reasons not to architect it with cloud portability in mind. However, achieving cloud portability is more complex in the context of existing applications. Let’s take a closer look at how a company with an existing application can move towards cloud portability.
How to achieve cloud portability
Sadly, there’s no one-size-fits-all solution to achieving cloud portability. Unless you’re architecting from the ground up, it’s likely to be a gradual process that you approach workload-by-workload. And while the specifics of how to achieve cloud portability can vary quite a bit based on the specifics of your application or workload and the clouds you’re looking to be able to move between, there are some general best practices to follow:
Adopt cloud-agnostic tools and technologies
While the public clouds offer a full suite of services including databases, cloud functions, and more more, these services are proprietary. Using them will make it more difficult to move to another cloud. Instead, embrace third-party cloud-agnostic services that can operate on multiple clouds.
For example, let’s say that your application runs on AWS, and you use Aurora for your important OLTP workloads. But the costs associated with operating those workloads are significant, so you’d like to make your database cloud-portable to enable you to switch if you’re ever able to find better pricing elsewhere. Or perhaps you just have some leverage in your negotiations with AWS. How can you achieve that?
Well, all of the major cloud providers offer their own flavor of proprietary distributed relational database – you can get similar features from Spanner on GCP, for example. But switching from Aurora to Spanner requires migrating your database, and learning the intricacies and performance tricks for a new piece of software. That means that you won’t be able to change clouds quickly. Trying to migrate an important production database quickly is a recipe for disaster. You don’t get the advantages of flexibility and cloud portability if it’s going to take you weeks or months of careful planning and testing to be able to move a workload from Aurora to Spanner (and migrations of this sort generally do take months).
RELATED
How to Choose a Deployment Option
Instead, then, the best approach might be to migrate to a cloud-agnostic database such as CockroachDB now. CockroachDB can be operated self-hosted or using a DBaaS model across all three major public clouds. So even if you want to stick with AWS at least in the short-term, migrating to CockroachDB now allows you to stick with AWS while adding the flexibility of being able to swap quickly to another cloud in the future when the need arises. This kind of change is much quicker because you’re not actually migrating databases. The software stays the same, you’re just moving your data onto the same database on a different cloud.
(In fact, CockroachDB actually supports multi-cloud deployment, so you could even run the same database across multiple clouds at the same time if you wanted, although because of cloud egress costs and networking challenges between the clouds, this type of deployment probably isn’t the right choice for most use cases).
We’ve focused on the database here as it’s the example we’re best familiar with, but cloud-agnostic tools and technologies exist across all layers of an application. If you’re interested in cloud portability, a good first step is often to figure out what proprietary cloud tools and services you’re relying on, and find out whether there are comparable cloud-agnostic solutions you could leverage.
Test and experiment
Needless to say, it’s best to have a good understanding of what switching clouds will entail before you actually need to do it. So if you’re looking to make a specific application or service cloud portable, another good first step is to begin portability testing to develop a thorough understanding of what’s required for your specific use case, and what technical or logistical challenges you’re likely to encounter.
This will allow you to address those challenges before a change in cloud is required, by doing things like switching to cloud-agnostic tooling and/or building automation and leveraging orchestration tools to smooth out the more challenging elements associated with moving data or services between your clouds of choice.
Design for portability going forward
The advantage of making a particular workload, service, or application cloud portable must always be balanced with the costs associated with doing so, and there are certainly circumstances in which the benefits don’t justify the time that would be required to make something cloud portable.
When designing new applications, products, and services, though, there are few reasons not to architect with cloud portability in mind, even if you intend to deploy to a single cloud.
So even if you determine that it doesn’t make financial sense to push for cloud portability with your existing application, making that a part of your design plan for new products and applications can help give you more flexibility over time.
