What cloud infrastructure taught me about building billing systems
For years, I thought of billing as a domain I would have to learn from scratch. Ledgers. Taxes. Proration. Regulations. Money. After 11 years building cloud datacenter management systems, I assumed my infrastructure experience would take me only so far. I was wrong.
For years, I thought of billing as a domain I would have to learn from scratch. Ledgers. Taxes. Proration. Regulations. Money. After 11 years building cloud datacenter management systems, I assumed my infrastructure experience would take me only so far. I was wrong.
A few years ago, when I began working on billing, what surprised me most wasn’t how different the domain was. It was how familiar the hardest engineering problems felt. I found myself thinking about the same things I had spent years thinking about in infrastructure: state machines, lifecycle transitions, retries, partial failures, reconciliation and the gap between what a system believes and what is actually happening.
A provisioning system answers questions like: What exists? What changed? What happens when a transition fails halfway through? A billing system asks the same questions, with money attached. The domain was new. The engineering was not.
The important difference is what happens when you get the state wrong. In infrastructure, a lifecycle error can waste capacity. In billing, the same kind of error can charge a customer. That distinction turns familiar distributed-systems problems into financial ones.
Nobody who has built infrastructure resource provisioning systems believes in just “create.” Create is a journey: validate the request, reserve capacity, allocate resources, configure, activate. Each step can fail, and when one fails halfway through, you are left with something that is neither quite a resource nor quite nothing. Half-created objects are a fact of life in provisioning systems at scale. The code that finds, finishes or sweeps them is where much of the real engineering lives.
In context
- Topic: Cloud y Arquitectura — Nube pública, híbrida, costos y decisiones de infraestructura.
- Source: InfoWorld
- Published: 05/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
After a few years, nearly every organisation that migrated discovers the same thing: the bill grows faster than the business. Not because the cloud is expensive, but because nobody switches off what is no longer used and nobody has the incentive to check.
My reading goes through who sees the bill. In organisations where cloud cost reaches the team that generates it, spend organises itself. Where only finance sees the bill, spend grows and the discussion becomes a blind cut every year end.
What usually goes wrong
Where it usually breaks is team capability. The platform is new but people learned on the fly, with no time and no support. They end up replicating data-centre practices in the cloud, which means paying cloud prices for benefits that never arrive.
What to watch
- What happens when the provider has an outage, because it will, and what keeps running meanwhile.
- Three-year total cost with real growth, not the first-year promotion.
- How hard it would be to leave or move a piece to another provider, which is future negotiating power.
How I read this entry
If this fed into an infrastructure decision, I would ask for the three-year total cost with real growth built in, not year one with the entry discount. Most cloud surprises live in year two, when the discount ends and the volume has already gone up.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
