Operations | Monitoring | ITSM | DevOps | Cloud

For years, vendor lock-in has been discussed as a theoretical risk. A concern to acknowledge in architecture reviews. A box to tick in compliance frameworks. A future problem that might need addressing. Our latest research reveals something more urgent. For UK organizations, lock-in isn't theoretical anymore. It's structural. It's measurable. And it's preventing organizations from acting on their own strategic priorities.

In recent years, the conversation about digital sovereignty has focused on data. Where it is stored, who can access it, and which laws apply when something goes wrong. Those questions still matter, but AI is forcing us to think about sovereignty in a different way.

The cloud bill arrives at the end of every month, and somewhere in it sits a line item that nobody outside the infrastructure team really understands. It might be called "data transfer," "egress," or "outbound bandwidth," and it might be 5% of the total or even 25%. Whatever it is, it tends to be the line that finance asks engineering about, and engineering struggles to explain in a way that finance can act on. The problem is that egress is a fee that hides in plain sight. It's not on the marketing page.

The default cloud choice for technically literate teams has shifted. It hasn't shifted dramatically; the major hyperscalers aren't going anywhere, and their enterprise position is still strong, but the conversation that used to start with "which hyperscaler" now genuinely starts with "what do we actually need." That's new.

GPU utilization is one of the most expensive metrics in cloud infrastructure to get wrong. A GPU running at 30% utilization costs the same as one running at 90%, but it's doing a third of the useful work. For workloads measured in tens of thousands of GPU-hours, the difference between average utilization in the 30s and average utilization in the 70s is hundreds of thousands of dollars across the life of the workload.

Sovereign cloud conversations usually center on where customer data sits at rest. The provider points at a UK data center, the contract gets signed, and procurement marks the box. For most workloads, that's a defensible position. For GPU workloads, it isn't.

Training a model is a project with an end date. Inference is what happens for the rest of the model's working life. The two workloads share GPUs, frameworks, and a lot of vocabulary, but the infrastructure decisions that make sense during training are usually the wrong ones in production. Teams that treat inference as "training, but smaller" tend to discover the gap somewhere around their first traffic spike.

Cloud infrastructure has become the backbone of modern business operations. But as organizations deepen their reliance on cloud providers, a critical question often goes unasked: just how dependent are we, and at what cost? For years, the cloud adoption narrative focused on agility, scalability, and cost efficiency. Those benefits remain real. But the landscape is shifting.

AI inference and training are terms you'd run into if you have been around software engineering or even just scrolled through the news. Both are integral to delivering the AI-powered experiences we have come to expect from many of the applications we use daily. According to McKinsey, by 2030 inference will overtake training as the dominant workload in AI data centers, making up more than half of all AI compute and roughly 30-40% of total data center demand.

If you’re prepping for your first AI or MLOps interview, the hardest part usually isn’t always the hands-on element. For me, it’s the vocabulary. Interviewers sometimes lob single-word concepts at you (“what’s quantization?”) and watch how far you can carry the thread. The questions sound clear-cut, but each one is really a doorway into a bigger topic, and the interviewer is judging how cleanly you walk through it.