One Codebase, Five Clouds: Designing Out Vendor Lock-In
Cloud & Engineering · Case study
One codebase, five clouds: designing out vendor lock-in
A central government department asked a deceptively simple question: could its lakehouse run unchanged on any major cloud, and on-premises, without rewriting a line? We built the reference architecture two ways — once on Databricks, once on Snowflake — and compared what each would actually cost the department in freedom of movement.
Why the department asked
UK government is committing to public cloud at a scale that changes the negotiating arithmetic. On a single day in December 2023, three central government departments signed three-year hosting contracts with the same hyperscaler, worth £894m between them. To put that in proportion: those three contracts alone are worth more than the provider had earned across the entire decade-plus life of the G-Cloud framework they were procured through.
Contract values and framework comparison reported by Computer Weekly, January 2024.
Each contract can be defended on its own merits. Taken together, they describe a procurement pattern that quietly narrows the buyer's position — and lock-in is what makes that narrowing hard to reverse.
Lock-in is rarely a single decision. It accumulates. A team picks a managed ingestion service because it integrates cleanly with the storage layer they have already chosen. The warehouse is selected because it shares an IAM model with the rest of the estate. Dashboards, notebooks and governance tooling settle into the same provider's ecosystem, because doing otherwise means rebuilding integration plumbing from scratch.
By year three the platform is no longer running on a cloud. It is the cloud. Migrating away would mean rewriting ingestion pipelines in a different dialect, re-implementing security controls in a different IAM model, retraining engineers, and retiring years of dashboards built against proprietary SQL extensions. The exit cost is so high that the renewal conversation is over before it starts.
Lock-in levels reflect Rplus Analytics' own assessment, based on platform work across UK central government since 2012.
What we built
The design principle was that the valuable parts of the platform — the data, the transformation logic, the governance model, the access controls — stay portable, even where some operational glue is provider-specific. In practice that resolves to a single rule: one codebase, deployed unchanged to every target.
Concretely, that means storage in open table formats on object storage rather than proprietary warehouse-internal formats; transformation logic written against portable engines rather than provider-specific dialects; a unified governance and catalogue layer that travels with the data; and decoupled storage and compute, so each can scale — or be replaced — independently.
The layer-by-layer method behind this architecture is set out separately in our reference architecture for a cloud-agnostic lakehouse.
Portability is not an architecture preference. It is a commercial instrument. It gives a department a credible position at renewal: if the pricing is not right, the workload genuinely can move. That credibility is the negotiating leverage.
The two patterns, compared
Cloud-agnostic is not a single design. We built the architecture twice, on the two lakehouse platforms the department was realistically choosing between, so the trade-offs could be seen rather than argued about.
Both patterns satisfy the brief across the four hyperscalers. They diverge at the fifth target. Because the Databricks pattern rests on Spark and an open table format, the on-premises deployment is the same stack running on different infrastructure. The Snowflake pattern has no on-premises form: an environment that cannot reach the public cloud has to run something else, which reintroduces a second codebase — the exact condition the architecture was designed to eliminate.
That is not a verdict on either platform in general. It is a specific consequence of a department that needs on-premises capability alongside cloud, which many public sector organisations do.
Governance that travels
The portability argument fails if governance is rebuilt per environment. In both patterns the catalogue, data quality rules, governance policies, master data management and data marketplace sit in a single plane spanning every deployment target, rather than being reimplemented inside each provider's native tooling. Moving a workload moves its policies with it.
This is also what makes cross-departmental sharing tractable. Government increasingly needs data to flow between departments — fraud detection, benefits administration, public health, policy evaluation. When two departments standardise on different hyperscalers, every cross-departmental analysis becomes an integration project rather than a query. A governance layer that already abstracts across providers removes most of that friction.
Where to start
-
Audit your portability ratio
What percentage of the platform — by code volume, by storage cost, by user-facing surface — would survive a provider migration unchanged? Most teams are surprised by the answer.
-
Move new workloads to open table formats first
Don't try to migrate everything. Let new pipelines land on Delta or Iceberg from day one, and let the proprietary estate run down naturally.
-
Centralise governance before centralising compute
A governance layer that already abstracts across providers makes everything downstream easier — including the migration you may never need to make.
Working with Rplus
Rplus Analytics has supported UK central government data platforms since 2012. We help public sector organisations design cloud architectures that preserve negotiating power, support cross-departmental data sharing, and survive contract renewals intact.