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 que importa
Depois de alguns anos, quase toda organização que migrou descobre a mesma coisa: a fatura cresce mais rápido que o negócio. Não porque a nuvem seja cara, mas porque ninguém desliga o que já não se usa e ninguém tem incentivo para revisar.
Minha leitura passa por quem vê a fatura. Nas organizações em que o custo de nuvem chega à equipe que o gera, o gasto se organiza sozinho. Onde só o financeiro vê a fatura, o gasto cresce e a discussão vira um corte às cegas todo fim de ano.
O que costuma dar errado
Onde costuma quebrar é na capacidade da equipe. A plataforma é nova mas as pessoas aprenderam no caminho, sem tempo e sem acompanhamento. Acabam replicando na nuvem as mesmas práticas do centro de dados, ou seja, pagam-se preços de nuvem por benefícios que nunca chegam.
O que observar
- O que acontece quando o fornecedor tem uma queda, porque vai ter, e o que segue operando enquanto isso.
- O custo total em três anos com crescimento real, não a promoção do primeiro ano.
- Quão difícil seria sair ou mover uma parte para outro fornecedor, que é o poder de negociação futuro.
Como leio esta publicação
Se isto entrasse numa decisão de infraestrutura, eu pediria o custo total em três anos com o crescimento real embutido, não o do primeiro ano com desconto de entrada. A maioria das surpresas de nuvem está no ano dois, quando o desconto acaba e o volume já subiu.
A notícia original está publicada em outro idioma; o trecho é citado como o veículo o entrega e o comentário é escrito em português.
Comentários
Ainda não há comentários. O primeiro pode ser o seu.
Está vivendo isso na sua equipe?
Abra o chat e me conte como estão lidando com isso. Tenho interesse em comparar notas.
