← back to work

Global online gaming and sports-betting platform · 2022–2025

A Multi-Cloud Strategy That Was Not About Clouds

Multi-cloud framework architected for cost-effective, scalable, resilient big-data infrastructure; eight-figure savings over a decade modelled in.

Theme Strategy, Vision & Transformation · Also Cost

In brief

Situation. The company was running on a hybrid of on-premises infrastructure and a single cloud provider. Both data volumes and AI ambitions were growing faster than the existing setup could absorb.

Complication. Doubling down on a single cloud meant single-vendor risk and rising costs. Splitting across clouds without a plan meant operational chaos. Neither option was good. A real multi-cloud strategy, diversified, integrated, with a coherent data mesh, was needed, but it was a multi-year initiative with significant up-front cost.

Resolution. Under the CTO’s guidance, I co-led the Multi-Cloud Strategy with the Director of Technology and Infrastructure, drawing on Gartner research and partnerships with Google, AWS, Microsoft, and Databricks. We defined strategic objectives, built a comprehensive technical roadmap, ran an MVP to establish performance baselines, and aligned partners on integration, scalability, cost, and pricing.

Impact. A robust framework capable of scaling efficiently, controlling operational expenses, and supporting sustained growth. Long-term foundation laid for cost-effective, scalable, resilient big-data infrastructure.

The longer story

Multi-cloud strategies are usually pitched as a technology decision. They are not. They are a political decision dressed in technology clothing.

Choosing a single cloud means giving one vendor an enormous amount of leverage over your future cost base. Vendors know this, and over time the bill rises in ways that have nothing to do with your usage and everything to do with their leverage.

Multi-cloud, properly done, is not about having two of everything. It is about having a credible threat. The vendor who knows you can walk negotiates differently to the vendor who knows you cannot.

The interesting design question was therefore not “how do we use two clouds?” but “how do we architect things such that any workload can credibly move?” Workloads that can move are workloads that get good prices. Workloads that cannot move are workloads that get expensive.

The strategy was, in essence, a decade-long bargaining-position upgrade. We modelled it, scenario-tested it, and laid the rails. Whoever inherits this will save the company eight figures over the next decade, mostly without anyone realising it.