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.
Por qué importa
Después de unos años, casi toda organización que migró a la nube descubre lo mismo: la factura crece más rápido que el negocio. No porque la nube sea cara, sino porque nadie apaga lo que ya no se usa y nadie tiene el incentivo de revisarlo.
Mi lectura pasa por quién ve la factura. En las organizaciones donde el costo de nube le llega al equipo que lo genera, el gasto se ordena solo. Donde la factura la ve únicamente finanzas, el gasto crece y la discusión se vuelve un recorte a ciegas cada fin de año.
Lo que suele salir mal
Donde suele romperse es en las capacidades del equipo. La plataforma es nueva pero la gente aprendió sobre la marcha, sin tiempo y sin acompañamiento. Terminan replicando en la nube las mismas prácticas del centro de datos, con lo cual se pagan precios de nube por beneficios que nunca llegan.
Qué mirar
- Qué pasa cuando el proveedor tiene una caída, porque la va a tener, y qué queda operando mientras tanto.
- El costo total a tres años con crecimiento real, no la promoción del primer año.
- Qué tan difícil sería salir o mover una parte a otro proveedor, que es el poder de negociación futuro.
Cómo leo esta entrada
Si esto entrara en una decisión de infraestructura, yo pediría el costo total a tres años con el crecimiento real puesto adentro, no el del primer año con descuento de entrada. La mayoría de las sorpresas de nube están en el año dos, cuando el descuento se acaba y el volumen ya subió.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
