Custo total de propriedade

A fatura que só conta o preço do medidor

Em 2022, a 37signals, empresa por trás do Basecamp e do serviço de e-mail Hey, decidiu que suas faturas de AWS e Google Cloud tinham virado uma das partes mais caras de rodar o negócio, e começou a mover essa infraestrutura de volta para data centers próprios. Até 2024, a fatura anual de nuvem da empresa tinha caído de US$ 3,2 milhões para US$ 1,3 milhão, uma economia relatada de US$ 2 milhões por ano, depois de uma compra antecipada de hardware de cerca de US$ 700 mil, com a empresa projetando mais de US$ 10 milhões economizados ao longo de 5 anos. Esse é um caso real e bem documentado de possuir hardware custando menos do que alugar a capacidade equivalente, para a carga de trabalho específica, estável e previsível, daquela empresa.

É também, sozinho, uma comparação incompleta, e entender por quê é exatamente para o que serve o custo total de propriedade.

O que o TCO realmente significa

Custo total de propriedade é o custo completo de adquirir, rodar e manter um sistema ao longo de um período definido, geralmente de 3 a 5 anos, e não só o preço de um único item da conta. Uma fatura de nuvem mostra o medidor: computação, armazenamento e transferência de dados, cobrados pelo mês recém-usado. Uma cotação de hardware mostra o preço de tabela da máquina. Nenhum dos 2 é TCO. TCO é o que você obtém depois de somar tudo que cerca esse número visível, dos 2 lados da comparação.

Custos diretos contra os custos que ninguém coloca na fatura

Os custos diretos e medidos são os que uma fatura de nuvem já mostra: computação, armazenamento e transferência de dados. A transferência de dados merece uma nota específica, porque não é simétrica. A AWS, como a maioria dos provedores, não cobra para mover dados para dentro da nuvem, mas cobra, em faixas escalonadas, para mover dados para fora, chamado de egress. Uma carga de trabalho que lê pouco dado, mas exporta grandes volumes com frequência, pode carregar uma fatura de transferência de dados bem maior do que os custos de computação sozinhos sugeririam.

Tudo o mais é um custo indireto, e ele fica dos 2 lados da comparação, não só de um. Do lado da nuvem: o trabalho único de migrar ou reconstruir a arquitetura de uma carga de trabalho para rodar lá, tempo de equipe gasto configurando, monitorando e otimizando recursos de nuvem, as ferramentas de gestão de custo e monitoramento compradas especificamente para acompanhar esse gasto, e ferramentas de segurança ou compliance por cima disso. Do lado on-premises: energia e refrigeração para a sala onde o hardware fica, o imóvel em si, uma renovação de hardware a cada poucos anos conforme o equipamento envelhece, e tempo de equipe gasto instalando, aplicando patches e, no fim, descartando equipamento aposentado, o mesmo peso de manutenção que a primeira lição deste domínio já apontou como um dos motivos originais pelos quais a nuvem existe.

A armadilha: comparar só o que é fácil de comparar

É tentador fazer essa comparação olhando 2 números, a fatura de nuvem deste trimestre e o preço de tabela de hardware de servidor equivalente, e declarar vencedor quem tiver o número menor. Nenhum dos 2 números é TCO. A fatura de nuvem deixa de fora a equipe e as ferramentas construídas ao redor dela. O preço de tabela do hardware deixa de fora energia, refrigeração e o ciclo de renovação que volta a aparecer em 3 a 5 anos.

O caso da 37signals é um exemplo real e útil de como essa armadilha é fácil de cair, mesmo quando uma empresa está genuinamente tentando ser rigorosa. A cobertura independente sobre a mudança apontou especificamente que os números de economia divulgados ainda não contabilizavam custos futuros de renovação de hardware, o pessoal adicional de operações que a mudança exigiu, nem o custo contínuo de manter espaço, energia e refrigeração de data center próprio. Isso não é uma crítica à decisão da 37signals, que pode muito bem continuar válida depois que essas categorias forem contabilizadas. É uma demonstração de que mesmo uma empresa defendendo publicamente a posse de hardware ainda não tinha, no momento em que esses números foram divulgados, terminado de contar todas as categorias que uma comparação de TCO completa exige.

Exemplo prático: uma comparação de 3 anos, feita de forma honesta

Pegue uma carga de trabalho com tráfego estável e previsível e compare 3 anos de posse on-premises contra 3 anos na nuvem, contando os custos indiretos dos 2 lados.

Para essa carga de trabalho específica e estável, a comparação honesta de 3 anos favorece o hardware on-premises, por cerca de US$ 56.000, e não simplesmente porque a fatura medida da nuvem é maior do que o preço de tabela do hardware. Isso só fica claro depois que pessoal e ferramentas são contabilizados dos 2 lados. É o mesmo formato de decisão que a 37signals tomou, em uma escala muito maior.

Mude uma única premissa e a resposta pode se inverter. Dê a essa carga de trabalho um padrão de tráfego que tem picos de 3 vezes o valor de base por 2 semanas por ano, e o lado on-premises agora precisa de hardware dimensionado para um pico que só usa por 2 semanas e deixa ocioso o resto do ano, o mesmo problema de superprovisionamento que a nuvem foi construída para remover. O lado da nuvem, em contraste, simplesmente escala para essas 2 semanas e reduz depois, pagando só pela capacidade extra que de fato usou. Essa única mudança no formato da carga de trabalho costuma ser suficiente para virar a comparação para o outro lado. Nem "a nuvem sempre sai mais barata" nem "a nuvem é sempre um roubo" é uma regra que se pode decorar; TCO é um cálculo que você faz para uma carga de trabalho específica, não um veredito que se transfere do caso de uma empresa para o de outra.

FinOps: a disciplina que mantém o TCO atualizado

Um cálculo de TCO é uma fotografia, precificada uma vez para uma decisão tomada em um ponto específico no tempo. O gasto com nuvem não fica parado depois dessa decisão: ele muda a cada vez que um engenheiro sobe um novo recurso, exatamente o que o torna diferente de um orçamento fixo de data center definido uma vez e deixado de lado. O FinOps é a disciplina construída para gerenciar essa diferença. A FinOps Foundation o define como um framework operacional e uma prática cultural que maximiza o valor de negócio da tecnologia, viabiliza decisões oportunas e orientadas por dados, e cria responsabilidade financeira através da colaboração entre engenharia, financeiro e áreas de negócio, em vez de tratar custo como algo que só o financeiro revisa depois do fato.

Essa é a mesma ideia para a qual o próprio AWS Well-Architected Framework aponta com seus princípios de otimização de custo: implementar a gestão financeira da nuvem como uma capacidade organizacional de verdade, e analisar e atribuir o gasto continuamente, para que o dono de uma carga de trabalho consiga ver, e agir sobre, o que ela realmente custa. FinOps é como fica essa análise quando ela roda de forma contínua, em vez de uma vez por ano.

Para onde isso leva

Uma fatura de nuvem e uma cotação de hardware são as 2 respostas parciais. Antes de comparar 2 formas de rodar uma carga de trabalho, liste todo custo direto e indireto dos 2 lados, precifique-os na mesma janela de vários anos, e só então compare os totais. Acerte esse hábito uma vez, em uma planilha, e o FinOps é simplesmente como fica manter esse hábito de forma contínua, em vez de fazer isso só de vez em quando.

Isso encerra a economia da nuvem: qual problema ela resolve, como você paga por ela, e quanto ela realmente custa para rodar. O próximo domínio deixa o custo para trás e passa para os serviços em si, começando pelas 3 formas como provedores de nuvem empacotam o que vendem: IaaS, PaaS e SaaS.