Perguntas sobre custo em nuvem costumam soar simples.
- Quanto este cliente custa para a gente?
- Qual o custo de rodar essa funcionalidade?
- Quais times ou produtos estão puxando o gasto?
Em pequena escala, dá para responder com estimativas grosseiras. Mas, conforme os sistemas crescem, essas viram, silenciosamente, algumas das perguntas mais difíceis da organização.
Não por falta de dados, mas porque a forma como a infraestrutura moderna funciona mudou.
O custo deixou de refletir a propriedade com clareza
Em ambientes em estágio inicial, o custo costuma andar junto com a propriedade. Um serviço pertence a um time. Um banco de dados sustenta um produto. Um ambiente corresponde a uma função.
Conforme a infraestrutura escala, esse modelo mental quebra.
Os sistemas de hoje são:
- Altamente compartilhados entre times e produtos
- Construídos sobre camadas de plataforma que atendem muitos consumidores
- Cada vez mais multi-tenant por design
O custo já não tem um dono só. Ele se distribui pelos padrões de uso. A partir daí, perguntar "de quem é isso?" deixa de ser a pergunta certa.
A infraestrutura compartilhada esconde o consumo real
A maior parte dos custos relevantes em nuvem está nas camadas compartilhadas:
- Data pipelines
- Plataformas de streaming
- Bancos de dados
- Rede e tráfego entre serviços
- Serviços de plataforma que sustentam vários workloads
Esses componentes raramente têm relação um-para-um com um time, funcionalidade ou cliente.
Em vez disso, absorvem uso vindo de toda a organização, muitas vezes de forma desigual. Alguns times consomem muito mais do que outros, mas esse desequilíbrio é difícil de enxergar.
O resultado é opacidade de custos, mesmo quando o gasto total está à vista.
Por que o unit economics fica embaçado em escala
Quando o custo não pode ser ligado diretamente ao uso, o unit economics sofre.
Os times têm dificuldade para:
- Explicar as margens por cliente ou produto
- Entender quais funcionalidades são lucrativas
- Prever gastos com precisão
- Tomar decisões seguras sobre arquitetura ou precificação
O time de Finanças vê números que não fecham. A Engenharia vê uma complexidade que não aparece nos relatórios.
Todo mundo sente esse descompasso.
O problema real é a atribuição, não a visibilidade
O problema real não é visibilidade. É o modelo.
Toda organização consegue ver a fatura da nuvem.
O que falha é a conexão entre os recursos de nuvem e as perguntas de negócio que chegam para você.
Tags de nuvem são úteis para questões simples de propriedade. Mas perguntas em nível unitário raramente são um-para-um:
- Um cliente usa vários serviços.
- Um serviço atende vários clientes.
- Um time de plataforma sustenta vários produtos.
- Infraestrutura compartilhada e tráfego de rede não "pertencem" a um único dono.
Mesmo com uma ótima higiene de tags, elas não dão conta de expressar essa realidade muitos-para-muitos nem a lógica de alocação necessária para responder a perguntas como "custo por cliente", "custo por funcionalidade" ou "qual time está subsidiando qual".
É por isso que o unit economics fica embaçado em escala: os dados existem, mas o modelo de custo não corresponde a como o sistema é de fato consumido. E é por isso também que o nosso "FinOps sem tagging" é tão diferente.
Como os melhores times encaram isso de outro jeito
Os times que operam em escala estão começando a repensar como modelar o custo:
- De baixo para cima, a partir do uso, em vez de cima para baixo, pela propriedade
- A partir dos sistemas compartilhados, em vez dos recursos isolados
- Com base no consumo real, em vez de suposições
Essa mudança volta a tornar o custo em nível unitário explicável, mesmo em ambientes complexos.
Você pode ver como isso funciona na prática neste case, que mostra como a Akamai explica o custo em nível unitário em uma infraestrutura compartilhada sem depender de tagging:
Ou, se quiser ver como isso se aplica ao seu ambiente, agende uma demo aqui.