The Most Expensive Game You'll Ever Play
There is a moment in every organisation's cloud journey where someone asks a question that sounds simple and turns out to be anything but: "How much will this cost?"
I have watched senior leaders' faces when they receive their first unforecasted cloud bill. There is a particular expression — somewhere between confusion and quiet horror — that I think anyone who has worked in cloud infrastructure will recognise. The bill is never what they expected. It is frequently not even in the right order of magnitude. And the explanation for why involves a level of complexity that makes the person asking wish they'd never raised the subject.
I built a game about this.
A few years ago, before AI was quite such a thing, I put together a simulation called the Black Friday Game. The premise is straightforward: you're running an online retailer, Black Friday is coming, and you need to configure your cloud infrastructure to handle the traffic spike without either falling over or spending a fortune on capacity you don't use. You adjust the scaling thresholds, the over-provisioning levels, the node startup times — and then you watch your scenario play out, seeing in near real-time how many requests you serve, how many you drop, and how much it all costs. There's a scoreboard. (I am told it is surprisingly competitive for what is essentially a spreadsheet with better graphics.)
I think the reason it resonates is that it captures something genuinely difficult about cloud economics: the relationship between cost, capacity, and failure is non-linear, counter-intuitive, and extremely hard to reason about in the abstract.
The Spaghetti Problem
It seems to me likely that cloud spend is a bit like cooking spaghetti for a dinner party. You know roughly how much pasta one person eats. You think you can simply multiply that by the number of guests. But then you have to account for the fact that the pot takes ten minutes to boil (your node startup time), that some guests arrive early and some arrive late (your traffic profile), that everyone takes slightly different amounts (your per-request resource consumption), and that any pasta you cook but don't serve goes in the bin (your wasted capacity). Oh, and every strand of uneaten spaghetti costs you money.
The temptation is to cook far too much — the cloud equivalent of setting your auto-scaling threshold to 20% instead of 80%. That works, in the sense that nobody goes hungry. But as I noted in a talk I gave on this topic, you could flip that statement around and say that you're targeting to waste 80% of your money, all the time. That might be proportionate if the cost of dropping a request is high enough. But knowing whether it's proportionate requires understanding each component of your system and how it scales — which, in a microservice architecture with dozens of components, is a genuinely non-trivial exercise.
Then AI Arrived
The game I built modelled a relatively simple three-tier architecture: a front end, a back end, and a database, scaling roughly linearly. Cloud spend was already complex enough to warrant a simulation. But the cost models we're now dealing with in the age of AI make that original game look almost quaint.
AI pricing is not linear. It's not even consistently measured. We have costs per token (input tokens priced differently from output tokens), costs per inference, costs per GPU-hour, costs that vary depending on the model size, the context window, the batch size, and whether you're using spot instances or reserved capacity. We have services where the cost of a single API call can vary by a factor of ten depending on how long the response is. I must admit that my own ability to forecast AI costs with any confidence is roughly zero, and I suspect I'm not alone in that.
This is, I think, one of the most underappreciated challenges facing organisations — particularly in the public sector — as they explore AI adoption. The question is not just "can we build this?" but "can we afford to run it at scale, and do we even know how to estimate what that means?"
Trying Before Buying
Which is where I think tools like NDX:Try become genuinely valuable. NDX:Try gives local government organisations free, isolated cloud sandboxes to experiment with — and crucially, those experiments include real cloud services with real cost structures. You can deploy a council chatbot or a document translation service in fifteen minutes, put some realistic load through it, and start to understand what the cost profile actually looks like — all without touching production infrastructure or spending any of your own budget.
However, I believe the real value goes beyond the individual experiment. When we can see how costs behave in a safe environment — how they scale with usage, where the non-linear jumps are, what the baseline overhead looks like — we start to build the kind of institutional understanding that protects organisations from bill shock later. The game taught people about cloud scaling through simulation. NDX:Try teaches people about cloud costs through direct, no-risk experience.
I think that distinction matters. Reading a pricing page is not the same as watching a meter tick up as your chatbot handles its hundredth concurrent conversation. Just as my Black Friday simulation taught people more about auto-scaling in ten minutes than a whiteboard session ever could, deploying an actual AI service — even in a sandbox — teaches you things about cost that no spreadsheet forecast can capture.
Back to the Dinner Party
The spaghetti problem never really goes away. Whether we're scaling Kubernetes pods or provisioning GPU instances for large language models, the fundamental tension is the same: too little capacity and we fail our users, too much and we waste public money. The complexity has increased enormously — AI has added an entirely new set of variables to an already difficult equation — but the approach should remain the same. Model it. Simulate it. Try it in a safe space. Learn before you commit.
Perhaps we should cook a small batch first.
Links
- Black Friday Game — try the cloud spend simulation
- Source code on GitHub — pull requests welcome
- Video walkthrough — the original talk explaining the game
- NDX:Try — free cloud sandboxes for local government
- National Digital Exchange
(Views in this article are my own.)