I was setting up Application Gateway for Containers (AGC) as the ingress layer for a project cluster. The AKS add-on makes it look straightforward in Bicep - enable it, deploy your Gateway and HTTPRoute manifests, done. What I ran into instead was a version deadlock between two managed add-ons that left the Gateway stuck at PROGRAMMED: Unknown for twelve hours and Front Door returning 504 the whole time.

This is what happened, why, and how I got out of it.

I had been building out a Fan Intelligence proof-of-technology for the FIFA World Cup 2026, and one of the things I wanted to get right from the start was the deployment model. When you have millions of fans receiving real-time notifications during a live match, the last thing you want is a bad deploy taking down a region.

The default approach for a lot of Kubernetes projects is kubectl apply and hoping for the best. That works for a dev cluster. It does not work when your RTO is measured in minutes and your blast radius spans multiple continents.

This post covers the ringed deployment pipeline I landed on: Azure Developer CLI (azd) for infrastructure and app deployment, Bicep for the infrastructure layer, Helm for the application layer, and ArgoRollouts for canary releases. No manual kubectl apply in the deployment path, automated rollback on error spikes, and a full audit trail from commit to running pods.

Even though the examples come from a Fan Intelligence workload, the pattern is platform-agnostic and can be reused for any AKS-based service that needs safe progressive delivery.

With the FIFA World Cup 2026 underway, I thought it would be a good chance to develop a World Cup 2026 fan intelligence platform in a regional deployment stamp pattern, but could also be scaled globally across other regions and locales.

This blog articles, covers the architecture, the 12 AI agent types, the Drasi event pipeline, the AKS configuration, that I used! This solution is also open source and you can deploy/modify and learn it from it all from scratch with azd (note it won't be cheap to run due to the resources deployed and needed, I was aiming for full production sizing and resourcing vs small proof of concept).

I've been spending time with LiteLLM and wanted to see how far I could take it as a self-hosted LLM gateway on Azure Kubernetes Service. The goal was simple: build a deployment that you can spin up with a single azd up command, with all the production bits - private networking, Redis caching, PostgreSQL for spend tracking, and a proper ingress with automatic TLS.

Turns out it works pretty well. Here's what I built and what I found.

A lot of Azure programmes can answer one question pretty quickly: what did we deploy?

• Landing zone. Done.
• Workloads migrated. Done.
• Monitoring enabled. Done.
• Tags and budgets configured. Done.
• Security baseline applied. Done.

Those are all useful things, and I am not downplaying them. They are part of getting cloud adoption right. But they are not the whole story.

The harder question is usually this one:

What is measurably better because we adopted Azure?

That is where the conversation shifts from cloud adoption to value realisation.