At the end of my street, there’s a beautiful and much-admired garden with vibrant flowers and a well-manicured lawn. Next to this splendid garden is an abandoned vacant lot, long-neglected and overgrown with weeds. Every time I walk by, I think about how this neglected space could be transformed into something magnificent (like this garden), but no one wants to take responsibility for it. Similarly, many CIOs and CTOs have “discarded vacant lots” to deal with in their own work lives: The problem of cloud lock-in.
Cloud lock-in can be a significant headache for business leaders. Even the UK’s communications sector regulator, Ofcom, has expressed concerns about the issue. Earlier this year, Ofcom announced that it would refer the UK cloud market for investigation to the Competition and Markets Authority, highlighting barriers to interoperability and concerns about high egress fees charged by the cloud hyperscalers.
But organizations shouldn’t just wait (and hope) for regulators to solve this problem. As a true believer in harnessing the full benefits of the cloud, I propose two practical ways to combat cloud lock-in.
The Upside of a Technical Approach
The first option is straightforward: Have an honest conversation with your cloud service account leader. Express your concerns about lock-in and negotiate more favorable terms and conditions. This approach might yield some results, but it’s not a guaranteed success. So, there’s a more effective strategy: Adopt a technical approach that empowers you to avoid vendor lock-in altogether, without costing you an arm and a leg.
Imagine that, instead of trying to turn your neglected space into a garden alone, you could access a ready-made gardening community, where multiple people work together to create something amazing. The same principle applies to cloud databases. Rather than relying exclusively on one hyperscaler’s technology stack, you can opt for platforms that offer portability and flexibility across different cloud providers.
Let’s consider databases, a critical underlying component of many mission-critical business applications. Each cloud hyperscaler will offer a range of SQL, NoSQL, and graph database options, which cater to various types and scales of technical problems. The challenge is to avoid getting locked into a single cloud stack, which hinders your ability to switch between clouds if and when needed.
One viable solution is to choose “vanilla Postgres” – the basic open source version of PostgreSQL available from postgres.org or any cloud provider. This will certainly provide initial flexibility, but you are likely to encounter limitations as your application grows and requires enterprise-level features.
The real benefit of the cloud lies in modernizing your data layer to fully exploit cloud-native features like scalability and resilience.
To achieve this, you need databases that run across different public clouds and share common APIs. Born-in-the-cloud technologies, designed from the ground up for cloud environments, offer the most flexibility and benefits.
Examining your current cloud vendor’s offerings is natural, as you’re already on their platform. However, keep in mind that these services are customized to their specific cloud environment only, so this could limit your future growth. If you decide to change cloud providers or adopt a multi-cloud strategy, moving across the cloud database “matrix” can be cumbersome due to the inconsistent APIs.
If you were restricted to a single set of gardening tools when trying to transform that discarded space into a beautiful community garden, it would be nearly impossible and would not be fit for purpose.
You need to realize that these services and their functionality will always need to be customized in some way to the specific cloud environment. AWS’s fully managed relational database engine, Aurora, is compatible with MySQL and PostgreSQL, but it was specifically designed to run on Amazon. This means it can’t run on-prem, and it certainly won’t work in GCP (Google’s cloud).
As a consequence, you will have to make time-consuming and costly changes to your application to accommodate a bespoke version of PostgreSQL that will run efficiently in the cloud environment of your hyperscaler partner. You’re going to be locked into that version of the application because it can’t really work anywhere else. The same applies to the Google equivalent of vanilla Postgres (CloudSQL for Postgres), or the Microsoft version (Azure PostgreSQL).
If you truly want a multi-cloud strategy, you need to consider how you go, for example, from mid-range Google to low-end Amazon. Scaling is much discussed, but surely one of the main selling points of cloud is that you can go down as easily as you go up.
The Business Advantages of Multi-Cloud are in Reach
To achieve the advantages of multi-cloud, you need to consider databases that offer common APIs and portability across clouds. There are several open source PostgreSQL-based database options available, which enable you to keep your cloud database options open and avoid the trap of cloud vendor lock-in.
The wait for regulatory intervention might be long and uncertain. Taking proactive steps now to mitigate cloud lock-in is crucial.
Adopt a scalable open source PostgreSQL option to immediately enjoy many of the benefits of multi-cloud. Embracing this strategy now can spare you potential panic moves when and if regulatory changes come into play.
By freeing your business from the shackles of cloud lock-in, you can unleash the true potential of multi-cloud environments. Just like that “discarded vacant lot” waiting to be transformed into a beautiful garden, your applications can blossom in a multi-cloud ecosystem, which allows you to easily scale up or down and enjoy the best that each cloud provider has to offer.
So, don’t wait for someone else to fix the problem. Take action today and start cultivating your multi-cloud future.
