Cloud FinOps: Aprendendo a otimizar custos na computação em nuvem

outubro 6, 2021
By Bruno Almeida

Em uma economia cada vez mais baseada na alocação e escalonamento de recursos na nuvem, o FinOps (Cloud Financial Management) é um movimento natural que tem sido adotado por empresas dos mais diversos nichos de mercado, como já destacamos em um post sobre o primeiro livro lançado sobre tema.

Conversamos com Renato Weiner, da Cloud8, para aprofundar as questões mais técnicas que abrangem o FinOps no contexto atual. Consultor experiente, Weiner foi o terceiro funcionário da conhecida Locaweb, onde trabalhou por 10 anos, e de lá, a convite do UOL, montou a unidade de host do portal. Há cerca de 9 anos criou a Cloud8, em um momento no mercado de cloud em que a AWS estava iniciando suas operações no Brasil, logo após o lançamento do S3.

“Quando a gente começou, o pensamento era criar uma plataforma para resolver os desafios de sair do esquema de datacenter tradicional e ir para um ambiente de cloud. Conceitualmente, esses desafios continuam os mesmos: questão de custos (acompanhar e saber onde se está gastando), questão de segurança (datacenter físico e sistemas hospedados, mesmo que ainda não seja cloud), disponibilidade, performance, Observabilidade, monitoração… os desafios são os mesmos, mas as formas de você executar são diferentes”, explica Weiner.

Neste post, compartilhamos os principais pontos do bate-papo conduzido pelo nosso CEO, Bruno Pereira (veja o vídeo com a íntegra da conversa ao final do texto).

Recomendações para empresas que estão iniciando em FinOps


FinOps é um jargão criado para motivar uma nova indústria de custeio em torno do gerenciamento financeiro na nuvem. O sentido do termo faz referência à responsabilidade que as empresas precisam ter ao cuidar de seus custos na nuvem. Para se ter uma ideia, hoje temos 45 mil itens contábeis entre as cinco clouds cadastradas no Cloud8. À medida que as pessoas vão utilizando, vamos registrando automaticamente esses itens. E o que acontece é o seguinte: se imaginarmos que estamos falando de milhares de itens, é muito fácil se perder nessa avalanche de opções dentro da cloud, seja ela AWS, um SKU do Google ou um item da Microsoft. Se você mergulhar direto nesses dados sem que tenha um conhecimento prévio ou uma ferramenta para ajudar, certamente você não vai conseguir fazer o melhor uso disso.

A minha recomendação para quem está começando ou já está avançado em cloud pública mas ainda não possui uma gestão específica de FinOps, é a seguinte: primeira coisa, é analisar com atenção as ferramentas que os provedores fornecem. Tem muita gente que confunde essa questão de FinOps com a fatura que vai receber no final do mês. É bom ficar atento, pois está muito longe disso. FinOps não é simplesmente saber o quanto se vai pagar: talvez as ferramentas que vemos nas plataformas, a princípio, possam dar a medida de quanto se vai gastar. Mas isso não é o que importa. Quando se pensa em FinOps, o que devemos observar é como o custo está alocado, então é preciso entender dentro dos produtos e dentro dos usos que se faz, como é que se está gastando, em termos de automação, storage e banco de dados, por exemplo. Isso do ponto de vista técnico.

Você tem que entender também, como estão evoluindo esses gastos, e quais são as anomalias encontradas. E isso, geralmente, é algo sinalizado pelas ferramentas utilizadas das clouds públicas. Você pode também pensar na organização das suas contas, de como pode começar a operar. Por exemplo, existem empresas que trabalham com múltiplas contas, e outras que trabalham com uma única conta. Então, no momento de pensar em organização de custos, você pode pensar em quebrar tudo, para segmentar a segurança dos custos, e fazer o custeio por contas. Essa é uma decisão estratégica, que pode ser tomada no começo do projeto. Mas hoje temos os frameworks “well-architected” – que todo mundo acaba usando esse mesmo termo, mas a AWS foi quem inaugurou – onde se diz que é possível gerenciar múltiplas contas.

Algo útil para a questão de segurança, e também útil para a questão de custos; porém, com a desvantagem de aumentar a complexidade de gerenciamento, seja com credenciais – um usuário vai precisar de uma credencial em cada ponta. Por exemplo, no Google você tem uma credencial que vale para multi-projeto, mas se houver uma permissão diferente ou projeto diferente do outro, aí já começa a complicar as coisas – então, como tudo na vida, é um trade-off: tem suas vantagens e desvantagens.

Mas uma estrutura de custos pode ser feita multi-conta. Se optar por ter uma única conta, fica um pouco mais complicado de começar a segmentar esses custos. Então quando começar, no dia 0, você terá o prisma vertical, a dimensão técnica, onde passará a entender o custo dos produtos, aquela “sopa de letrinhas” básica: a gente pode estar falando de EC2, de Azure Compute, de BigQuery do Google, enfim, todos esses são produtos técnicos.

Agora, quando fizer os relatórios, conseguirá ter em mente o montante que gastará de cada produto. E quando analisar o montante, você pode se perguntar: dentro de uma realidade de Compute, como eu separo quais são os custos por componente? Qual o custo por horas? Por exemplo, você vai ter horas do EC2: você pode ter horas sob demanda, horas sob spot, horas de instância reservada, horas de Savings Plans. Como isso ficará distribuído dentro da minha conta ou das minhas múltiplas contas?  Discos: como estou consumindo o Storage de discos? Como estou consumindo Data Transfer, backup, alarmes, e por aí vai?

Quanto mais você começa a entrar a fundo em cada uma das dimensões, mais complexa vai ficando a determinação desses custos. Então é preciso entender qual a maturidade de gestão de custos em que se deseja chegar. Mas existe uma segunda dimensão, não menos importante, que é a gestão de negócios. Então, se você quer traduzir toda a sua infraestrutura técnica para a sua gestão de negócios, como deve fazer isso? Você deseja traduzir toda a sua gestão, como por exemplo, produto, cliente, ambiente, centro de custo, orçamentos; como traduzir tudo isso para uma linguagem de negócios? Aqui entram em ação as tags. Então você passa a etiquetar todos os seus componentes, mas terá que escolher o conjunto de etiquetas antes de começar a sair etiquetando tudo, porque se tiver que mudar no meio caminho, vai te dar um pouco de retrabalho.

Então o ideal é começar certo: você pode escolher, como mencionei, centro de custos, produto, ambiente, equipe, e passar a etiquetar todos os seus componentes. Começar bem é etiquetar todo mundo, escolhendo a topologia do seu ambiente em termos técnicos (multi-conta ou uma conta só?), e principalmente, tomando uma decisão estratégica e de negócios: será que vou usar as ferramentas que tenham cloud pública? Vou criar as APIs e scripts internamente? Ou vou usar uma ferramenta de fora que possa me ajudar nessas tarefas? Independente das três decisões, eu sempre bato na mesma tecla: não se descuide dos custos. Pois, com esse monte de possibilidades, é muito fácil não só se perder, como também surgir alguma surpresa no meio do caminho, que você não sabia que estava sendo cobrado, e com uma má surpresa no fim do mês.

Créditos da nuvem: como fazer o melhor uso?


Todos os grandes players da nuvem oferecem programas de créditos. O crédito tem um lado bom, que é você deixar de gastar por uns meses, mas é preciso atentar também para o lado ruim, que é a amarração com um ou outro player, e o mal costume de achar que tudo é muito barato, “de graça”, e que, portanto, não vai gastar lá na frente. Geralmente, o que ocorre é que quando se começa a usar esses créditos, o primeiro sintoma perigoso é abandonar completamente os custos. E o segundo sintoma é que as ferramentas que exibem os custos vão apresentá-los como zero. E aí você não sabe exatamente quanto seria esse custo se não tivesse o crédito.

Então, se não buscar acompanhar o quanto efetivamente está gastando, poderá ter uma má surpresa na jornada ao findar esses créditos. A gente já tem notado empresas que possuem uma preocupação inicial de cara, e que começam a utilizar seus créditos com uma mentalidade de gasto efetivo, ou seja, eles já entram no orçamento real dessas empresas. Por exemplo, se você tem 10 mil dólares de crédito/mês e o orçamento é de 5 mil dólares, sabe que não poderá ultrapassar esse teto. Então o custeio que está sendo utilizado, está entrando dentro do orçamento para se ter uma ideia real do quanto custa o produto. E o fato de você não pagar para a cloud pública, é simplesmente uma questão de caixa da empresa. E não adianta deixar isso para última hora. Nós já tivemos clientes que nos procuraram faltando dois meses para findar os créditos, com questões como: quanto gastei nos últimos 10 meses? Aí o que se vê é uma curva estratosférica, parece uma curva exponencial, com máquinas mal dimensionadas, transferência de dados enorme, bancos de dados sem arquivamento, storage sem lifecycle, usando tiers de dados super caros para dados que são pouco acessados, ou seja, claramente não existia mesmo uma preocupação com os gastos na nuvem.

E aí vira prioridade, porque se virar o último mês e extrapolar nos próximos 12 meses, a empresa terá um problema sério que poderá até prejudicar seu funcionamento. Então vem aquela demanda para economizar da noite para o dia, ou mesmo de migrar para outro provedor, que por sua vez irá ofertar outros créditos, e continuar a operar dessa forma. Mas o custo da migração, se é que dá pra fazer uma migração depois, é altíssimo, não só a questão financeira, mas a questão de skill e time-to-market. Por tudo isso, a preocupação com a questão dos créditos deve vir desde o dia zero. Ela deve ser encarada da mesma forma como se estivesse pagando direto ao provedor. Eu tomaria muito cuidado com essa “armadilha” do crédito. E encararia isso como jogo real, não apenas “um treino” para o uso da nuvem.

Situações de erros frequentes


A primeira coisa que vejo é a utilização do ambiente de desenvolvimento de uma forma subótima. Quando a cloud começou a ser comercializada há alguns anos, era vendida como a solução ideal para seu ambiente de desenvolvimento. Então as pessoas faziam lab, instalavam máquina virtual, sistema operacional A, B e C, testava tudo da maneira mais simples, detonava o ambiente, e bola para frente. E aí de repente implementava em um datacenter físico, porque ainda não havia confiança na segurança da cloud; isso foi muito questionado, mas hoje sabemos que não é bem assim, a nuvem pode ser infinitamente mais segura que o ambiente físico. No entanto, foi muito usada como ambiente de teste.

E o que a cloud vende muito é que tudo é cobrado sob demanda: usou horas, usou espaço em disco, usou requisições – fiz uma requisição para um serviço, coloquei uma mensagem em uma fila, rodei uma regra de machine learning – você paga pela unidade (daí também o termo “unit economics”). Então o fato de se usar o ambiente de desenvolvimento pagando pela unidade significa que se não estiver usando o seu ambiente de desenvolvimento você pode simplesmente desligar ou desprovisionar. Esse é o primeiro ponto que vejo de melhoria. Lógico que como isso começou lá atrás, as empresas já têm um pouco mais de maturidade para saber lidar com o ambiente de desenvolvimento.

Mas além de desligar e desprovisionar, os ambientes de desenvolvimento também podem ter algum tipo de limite e modificação. Então, por exemplo: você não pode criar instâncias do tamanho x no ambiente de desenvolvimento sem que haja uma aprovação, uma conversa: ouvimos histórias de empresas onde se criam máquinas enormes para fazer um teste de carga que, na prática, nunca vão precisar, e de repente esquecem ligadas ou usam por tempo demais. Ambiente de desenvolvimento é, portanto, algo que pode e deve ser muito bem trabalhado nessa equação.

Se pegarmos a lógica da otimização do uso, temos uma série de situações onde é possível fazermos uma escala vertical – aumentando e diminuindo o tamanho de componentes – mesmo em produção, quando não existe a demanda. Hoje em dia, é bem claro: dependendo das aplicações, nós temos: horário comercial versus horário de folga. Mas toda aplicação geralmente tem uma certa sazonalidade. Uma folha de pagamento, por exemplo: chega no fim do mês, precisa de mais servidor, porque vai rodar tudo ao mesmo tempo. Eu vejo que ainda existem muitas empresas com relativa dificuldade de entender como funciona essa sazonalidade.

E a sazonalidade pode ser aproveitada para ligar e desligar, para refazer seu provisionamento, aumentar ou diminuir o seu ambiente. Veja isso como uma boa oportunidade: identifique essa sazonalidade, lógico que dentro da arquitetura da sua aplicação – tem aplicação que dá pra escalar, tem aplicação que não dá pra escalar; tem banco de dados que dá para desligar, tem banco de dados que não dá para desligar ou mesmo rebootar – hoje em dia temos tantos componentes, que muitas será possível fazer isso. Até container, um fargate, por exemplo, você pode mudar uma task definition dele. Você pode rodar no fim de semana uma task definition de um fargate spot menor do que você rodaria durante a semana. Você já está economizando com spot, e poderá economizar muito mais ainda no fim de semana diminuindo a task definition.

Um terceiro ponto que observamos muito também, é a questão de componentes que não são utilizados. Muitas vezes são provisionados componentes que são cobrados. O clássico: na AWS você tem os famosos NAT gateways, para poder fazer conectividade entre as VPCs, entre as subnets. Então o NAT gateway é muito fácil de sair provisionando e depois esquecer que não precisa utilizá-lo. Ele acaba sendo um componente pouco utilizado e, no pior dos casos, mal utilizado. E como isso tudo entra na fatura, tudo acumulado e consolidado, aquele custo entra como uma obscuridade dentro da sua fatura se você não parar, se for a fundo e não encontrar que tem o NAT gateway com data transfer, e às vezes inter-região ou inter-zona de disponibilidade. 

Por conta de tudo isso, nós passamos a criar dashboards específicos de Data Transfer, onde é possível apontar exatamente quem é o ID, qual é o componente do produto, qual seja ele, qual é o NAT gateway, qual o tipo de tráfego, inter A-Z, inter-região, CloudFront, VPC, VPC peering, VPN. É preciso ter sempre em mente que a AWS vai cobrar absolutamente tudo. Então se você tiver uma requisição no API Gateway, se estiver no Lambda e transferir, tudo entra na fatura do Data Transfer out, inter-região e AZ. Mas é preciso quebrar essa história do data transfer para saber disso. A gente encontra algumas empresas que sofrem com essa questão do Data Transfer.

E é possível otimizar isso, por exemplo, às vezes tem um servidor que está transferindo demais, ou tem um servidor com um vídeo de imagens grandes e você descobre que tem uma taxa de transferência altíssima, às vezes terabytes por dia, e a sua conta da AWS vai ficar lá nas alturas. A questão do Data Transfer é algo com que é preciso se preocupar, e é necessário ter um acompanhamento diário de quanto está seu custo de Data Transfer, caso existam sistemas realmente afetados por ele. Porque da noite para o dia você pode ter uma mudança, uma anomalia e isso pode ficar extremamente caro.

Equipes FinOps: Abordagem para Times de Produto

Antes de sair montando time, ou delegando a responsabilidades de FinOps, é preciso estar claro dentro da empresa a importância de fazer esse acompanhamento de custos. Não somente o acompanhamento, mas a questão do rateio, para que haja a visibilidade do que está acontecendo em termos de custos na organização. Então o primeiro passo é colocar estrategicamente para todos que isso é importante. O segundo passo é o como fazer. E aí para motivar o “como fazer”, costumo contar uma história que acho interessante. A gente que é técnico sabe que hoje a TI está sendo mais valorizada nesses processos de digitalização que tivemos nos últimos anos. Mas, no geral, a TI sempre foi vista como um centro de custos, como um lugar obscuro onde tinha um monte de gente esquisita que suportava uma operação que não era tão estratégica dentro da empresa, e que custava muito caro e ninguém entendia nada.

Quando começamos a olhar com atenção para a questão dos custos, podemos entender isso como uma oportunidade estratégica para se aproximar da área comercial, da área financeira e da área de produtos. Porque se você sabe exatamente quanto custa a TI e começa a dialogar com os times financeiro e de produtos, irá naturalmente vender melhor a ideia da importância da TI. Então se você desenha um processo de FinOps onde consegue fazer o rateio das áreas, onde consegue fazer o chargeback, e alinhar orçamento separando o que é operacional do dia a dia, você traz negócios para dentro da TI.

Agora, como fazer isso? A gente vê empresas onde o FinOps está arraigado na equipe, ou seja, você sempre terá um responsável, de preferência um só, que será a pessoa que vai responder pelas variações. Geralmente, não deveria ser uma pessoa da área financeira, porque, aqui na nossa realidade, o financeiro está mais preocupado com a área de finanças inteira da organização, e não tem o entendimento de bits e bytes que acontece na cloud. Então uma pessoa que seja puramente financeira em uma área técnica, cobrando por exemplo porque o custo de S3 subiu, só vai gerar ruído, e talvez não seja muito produtivo.

Agora, um gestor que seja capaz de fazer a ponte entre as áreas de negócio e a equipe técnica, e esteja sempre preocupado e de olho no que pode estar acontecendo, essa pessoa pode se tornar um “FinOps hero”, no jargão que as equipes da área brincam. Este é um papel que não é interessante para uma pessoa que é puramente técnica – mexer com planilha de Excel para fazer consolidação de custos – ninguém quer fazer isso, e se ninguém quer fazer isso, vai precisar de um terceiro, uma ferramenta ou uma empresa como a Elven para ajudar as equipes a fazer isso. Essa pessoa será a responsável por cobrar a equipe no momento certo, na dose certa, pela questão do uso racional de toda a infraestrutura.

Então é preciso ser alguém que tenha o conhecimento, com uma ferramenta para apoiá-lo a tomar as decisões que o ajudam a acompanhar de perto o dia a dia das coisas. A gente já observou também organizações onde a área de Governança assume essa parte dos custos, mas aí é preciso ter uma certa maturidade, porque o nome às vezes assusta, por ser uma pessoa que sempre vai estar no pé mas com um papel importante, fazendo com que os processos acordados entre as áreas sejam cumpridos.

Então, se nós acordamos que você tem um budget, e esse budget precisa ser reportado ou populado uma vez por mês, e a equipe não faz, quem está errado? É a governança de cobrar, ou a equipe de não ter feito? Então a governança funciona, desde que haja uma maturidade. E o que não deve ser feito? Delegar isso a uma pessoa com perfil junior. Primeiro porque vai ser uma tremenda batata quente colocar isso no colo de uma pessoa que não sabe nada de tecnologia para se tornar, aí sim, alguém muito chato, porque ele não entende, não tem o conhecimento para cumprir a tarefa. A outra coisa importante é: ou faz sério, ou não faz. Ou seja, ou faz direito ou não faça pela metade.

Quando eu digo fazer direito, veja bem não é fazer tudo, mas fazer pelo menos o mínimo. Isto é: se a gente tiver um determinado budget que for ultrapassado, vamos tomar ações específicas. Vamos instituir, por exemplo, que iremos atentar todos os dias para determinados custos. Ou seja, é ter um mínimo de regras: vamos colocar tag em todos os lugares, vamos definir o escopo e como iremos evoluir. Ou então, dependendo da maturidade da empresa, é possível ter uma equipe dedicada ao FinOps (a menos que você esteja desenvolvendo toda a estrutura para integrar dentro da empresa, mas aí é outro porte de organização, por exemplo, grandes bancos). Mas acho desnecessário essa questão de fazer do desenvolvimento interno uma coisa que seja muito sofisticada. Mas… tem que fazer.

Árvore de contas: como ter sucesso em instâncias reservadas e Savings Plans

Quando você compra uma instância reservada na AWS, uma all upfront, onde você paga 100% à vista e o custo subsequente dos meses é zero. Então, amortizando, você pagou x mil agora, e os próximos meses vai ser zero. O one-blended vai ser sempre zero. O blended vai misturar, vai pegar o custo que você tem on-demand, vai fazer uma mistura e vai ratear entre as contas. Isso, ao meu ver, não é nada bom, porque uma conta que se beneficiou de uma instância reservada, que tinha custo zero, se você contar o custo blended, ela passa a ter um novo custo. Então, por exemplo, dentro do Cloud8 a gente simplesmente ignora o blended. A gente só trabalha o one-blended porque não faz sentido essa mistura. Mas, em contrapartida, a AWS também tem uma questão de alocação da instância reservada.

Quando você compra um saving plan, que é mais genérico ainda, ele aloca onde você tem a economia maior. O tipo de instância, a região, se você tem um produto, um SQL Server Enterprise etc, onde vai gerar uma economia maior. Quando você busca na AWS pelas ferramentas deles onde esses custos estão alocados, geralmente ele aloca na conta pagadora, ou seja, não faz o rateio entre as outras contas. Então, por exemplo, dentro da nossa plataforma, a gente tem a conta pagadora, e rateamos entre quem efetivamente recebeu o benefício desses “descontos” que pagamos adiantado. Existem duas coisas aqui: a questão do dia a dia, você comprou e quer saber como está utilizando; e a recomendação.

Hoje em dia, a recomendação de Savings Plans e de instância reservada pode e deve ser feita dentro do próprio console da AWS. Eles têm a recomendação, você consegue fazer as simulações de vários tipos de saving plan geral, Compute, por região, por tipo, um ano, três anos, all partial e no upfront e consegue enxergar a realidade melhor. Pode levar em conta os últimos x meses, as últimas semanas, você faz a sua previsibilidade lá. E o mais legal é que você não precisa comprar tudo de uma vez.

Então, por exemplo, se você comprar 10 dólares por hora, vai sair uma fortuna, são 7440 dólares por mês de 31 dias; mas se não quiser comprar 10 dólares de cara, você pode comprar 1 dólar parcial, e fazer aquele mesmo esquema: acompanha, espera alguns dias para ver como está alocado, compra mais 1 dólar, mais outro, e vai indo, até chegar no seu limite de savings plan. Mas a recomendação pode ser feita no próprio console da AWS. É ainda um negócio meio difícil de entender, mas uma das nossas missões é facilitar essa questão. 

Assista ao vídeo com a íntegra do bate-papo:

Cloud FinOps: Aprendendo a otimizar custos na computação em nuvem

/ Computação em Nuvem, Elvenworks / Por
Cloud FinOps

Em uma economia cada vez mais baseada na alocação e escalonamento de recursos na nuvem, o FinOps (Cloud Financial Management) é um movimento natural que tem sido adotado por empresas dos mais diversos nichos de mercado, como já destacamos em um post sobre o primeiro livro lançado sobre tema.

Conversamos com Renato Weiner, da Cloud8, para aprofundar as questões mais técnicas que abrangem o FinOps no contexto atual. Consultor experiente, Weiner foi o terceiro funcionário da conhecida Locaweb, onde trabalhou por 10 anos, e de lá, a convite do UOL, montou a unidade de host do portal. Há cerca de 9 anos criou a Cloud8, em um momento no mercado de cloud em que a AWS estava iniciando suas operações no Brasil, logo após o lançamento do S3.

“Quando a gente começou, o pensamento era criar uma plataforma para resolver os desafios de sair do esquema de datacenter tradicional e ir para um ambiente de cloud. Conceitualmente, esses desafios continuam os mesmos: questão de custos (acompanhar e saber onde se está gastando), questão de segurança (datacenter físico e sistemas hospedados, mesmo que ainda não seja cloud), disponibilidade, performance, Observabilidade, monitoração… os desafios são os mesmos, mas as formas de você executar são diferentes”, explica Weiner.

Neste post, compartilhamos os principais pontos do bate-papo conduzido pelo nosso CEO, Bruno Pereira (veja o vídeo com a íntegra da conversa ao final do texto).

Recomendações para empresas que estão iniciando em FinOps


FinOps é um jargão criado para motivar uma nova indústria de custeio em torno do gerenciamento financeiro na nuvem. O sentido do termo faz referência à responsabilidade que as empresas precisam ter ao cuidar de seus custos na nuvem. Para se ter uma ideia, hoje temos 45 mil itens contábeis entre as cinco clouds cadastradas no Cloud8. À medida que as pessoas vão utilizando, vamos registrando automaticamente esses itens. E o que acontece é o seguinte: se imaginarmos que estamos falando de milhares de itens, é muito fácil se perder nessa avalanche de opções dentro da cloud, seja ela AWS, um SKU do Google ou um item da Microsoft. Se você mergulhar direto nesses dados sem que tenha um conhecimento prévio ou uma ferramenta para ajudar, certamente você não vai conseguir fazer o melhor uso disso.

A minha recomendação para quem está começando ou já está avançado em cloud pública mas ainda não possui uma gestão específica de FinOps, é a seguinte: primeira coisa, é analisar com atenção as ferramentas que os provedores fornecem. Tem muita gente que confunde essa questão de FinOps com a fatura que vai receber no final do mês. É bom ficar atento, pois está muito longe disso. FinOps não é simplesmente saber o quanto se vai pagar: talvez as ferramentas que vemos nas plataformas, a princípio, possam dar a medida de quanto se vai gastar. Mas isso não é o que importa. Quando se pensa em FinOps, o que devemos observar é como o custo está alocado, então é preciso entender dentro dos produtos e dentro dos usos que se faz, como é que se está gastando, em termos de automação, storage e banco de dados, por exemplo. Isso do ponto de vista técnico.

Você tem que entender também, como estão evoluindo esses gastos, e quais são as anomalias encontradas. E isso, geralmente, é algo sinalizado pelas ferramentas utilizadas das clouds públicas. Você pode também pensar na organização das suas contas, de como pode começar a operar. Por exemplo, existem empresas que trabalham com múltiplas contas, e outras que trabalham com uma única conta. Então, no momento de pensar em organização de custos, você pode pensar em quebrar tudo, para segmentar a segurança dos custos, e fazer o custeio por contas. Essa é uma decisão estratégica, que pode ser tomada no começo do projeto. Mas hoje temos os frameworks “well-architected” – que todo mundo acaba usando esse mesmo termo, mas a AWS foi quem inaugurou – onde se diz que é possível gerenciar múltiplas contas.

Algo útil para a questão de segurança, e também útil para a questão de custos; porém, com a desvantagem de aumentar a complexidade de gerenciamento, seja com credenciais – um usuário vai precisar de uma credencial em cada ponta. Por exemplo, no Google você tem uma credencial que vale para multi-projeto, mas se houver uma permissão diferente ou projeto diferente do outro, aí já começa a complicar as coisas – então, como tudo na vida, é um trade-off: tem suas vantagens e desvantagens.

Mas uma estrutura de custos pode ser feita multi-conta. Se optar por ter uma única conta, fica um pouco mais complicado de começar a segmentar esses custos. Então quando começar, no dia 0, você terá o prisma vertical, a dimensão técnica, onde passará a entender o custo dos produtos, aquela “sopa de letrinhas” básica: a gente pode estar falando de EC2, de Azure Compute, de BigQuery do Google, enfim, todos esses são produtos técnicos.

Agora, quando fizer os relatórios, conseguirá ter em mente o montante que gastará de cada produto. E quando analisar o montante, você pode se perguntar: dentro de uma realidade de Compute, como eu separo quais são os custos por componente? Qual o custo por horas? Por exemplo, você vai ter horas do EC2: você pode ter horas sob demanda, horas sob spot, horas de instância reservada, horas de Savings Plans. Como isso ficará distribuído dentro da minha conta ou das minhas múltiplas contas?  Discos: como estou consumindo o Storage de discos? Como estou consumindo Data Transfer, backup, alarmes, e por aí vai?

Quanto mais você começa a entrar a fundo em cada uma das dimensões, mais complexa vai ficando a determinação desses custos. Então é preciso entender qual a maturidade de gestão de custos em que se deseja chegar. Mas existe uma segunda dimensão, não menos importante, que é a gestão de negócios. Então, se você quer traduzir toda a sua infraestrutura técnica para a sua gestão de negócios, como deve fazer isso? Você deseja traduzir toda a sua gestão, como por exemplo, produto, cliente, ambiente, centro de custo, orçamentos; como traduzir tudo isso para uma linguagem de negócios? Aqui entram em ação as tags. Então você passa a etiquetar todos os seus componentes, mas terá que escolher o conjunto de etiquetas antes de começar a sair etiquetando tudo, porque se tiver que mudar no meio caminho, vai te dar um pouco de retrabalho.

Então o ideal é começar certo: você pode escolher, como mencionei, centro de custos, produto, ambiente, equipe, e passar a etiquetar todos os seus componentes. Começar bem é etiquetar todo mundo, escolhendo a topologia do seu ambiente em termos técnicos (multi-conta ou uma conta só?), e principalmente, tomando uma decisão estratégica e de negócios: será que vou usar as ferramentas que tenham cloud pública? Vou criar as APIs e scripts internamente? Ou vou usar uma ferramenta de fora que possa me ajudar nessas tarefas? Independente das três decisões, eu sempre bato na mesma tecla: não se descuide dos custos. Pois, com esse monte de possibilidades, é muito fácil não só se perder, como também surgir alguma surpresa no meio do caminho, que você não sabia que estava sendo cobrado, e com uma má surpresa no fim do mês.

Créditos da nuvem: como fazer o melhor uso?


Todos os grandes players da nuvem oferecem programas de créditos. O crédito tem um lado bom, que é você deixar de gastar por uns meses, mas é preciso atentar também para o lado ruim, que é a amarração com um ou outro player, e o mal costume de achar que tudo é muito barato, “de graça”, e que, portanto, não vai gastar lá na frente. Geralmente, o que ocorre é que quando se começa a usar esses créditos, o primeiro sintoma perigoso é abandonar completamente os custos. E o segundo sintoma é que as ferramentas que exibem os custos vão apresentá-los como zero. E aí você não sabe exatamente quanto seria esse custo se não tivesse o crédito.

Então, se não buscar acompanhar o quanto efetivamente está gastando, poderá ter uma má surpresa na jornada ao findar esses créditos. A gente já tem notado empresas que possuem uma preocupação inicial de cara, e que começam a utilizar seus créditos com uma mentalidade de gasto efetivo, ou seja, eles já entram no orçamento real dessas empresas. Por exemplo, se você tem 10 mil dólares de crédito/mês e o orçamento é de 5 mil dólares, sabe que não poderá ultrapassar esse teto. Então o custeio que está sendo utilizado, está entrando dentro do orçamento para se ter uma ideia real do quanto custa o produto. E o fato de você não pagar para a cloud pública, é simplesmente uma questão de caixa da empresa. E não adianta deixar isso para última hora. Nós já tivemos clientes que nos procuraram faltando dois meses para findar os créditos, com questões como: quanto gastei nos últimos 10 meses? Aí o que se vê é uma curva estratosférica, parece uma curva exponencial, com máquinas mal dimensionadas, transferência de dados enorme, bancos de dados sem arquivamento, storage sem lifecycle, usando tiers de dados super caros para dados que são pouco acessados, ou seja, claramente não existia mesmo uma preocupação com os gastos na nuvem.

E aí vira prioridade, porque se virar o último mês e extrapolar nos próximos 12 meses, a empresa terá um problema sério que poderá até prejudicar seu funcionamento. Então vem aquela demanda para economizar da noite para o dia, ou mesmo de migrar para outro provedor, que por sua vez irá ofertar outros créditos, e continuar a operar dessa forma. Mas o custo da migração, se é que dá pra fazer uma migração depois, é altíssimo, não só a questão financeira, mas a questão de skill e time-to-market. Por tudo isso, a preocupação com a questão dos créditos deve vir desde o dia zero. Ela deve ser encarada da mesma forma como se estivesse pagando direto ao provedor. Eu tomaria muito cuidado com essa “armadilha” do crédito. E encararia isso como jogo real, não apenas “um treino” para o uso da nuvem.

Situações de erros frequentes


A primeira coisa que vejo é a utilização do ambiente de desenvolvimento de uma forma subótima. Quando a cloud começou a ser comercializada há alguns anos, era vendida como a solução ideal para seu ambiente de desenvolvimento. Então as pessoas faziam lab, instalavam máquina virtual, sistema operacional A, B e C, testava tudo da maneira mais simples, detonava o ambiente, e bola para frente. E aí de repente implementava em um datacenter físico, porque ainda não havia confiança na segurança da cloud; isso foi muito questionado, mas hoje sabemos que não é bem assim, a nuvem pode ser infinitamente mais segura que o ambiente físico. No entanto, foi muito usada como ambiente de teste.

E o que a cloud vende muito é que tudo é cobrado sob demanda: usou horas, usou espaço em disco, usou requisições – fiz uma requisição para um serviço, coloquei uma mensagem em uma fila, rodei uma regra de machine learning – você paga pela unidade (daí também o termo “unit economics”). Então o fato de se usar o ambiente de desenvolvimento pagando pela unidade significa que se não estiver usando o seu ambiente de desenvolvimento você pode simplesmente desligar ou desprovisionar. Esse é o primeiro ponto que vejo de melhoria. Lógico que como isso começou lá atrás, as empresas já têm um pouco mais de maturidade para saber lidar com o ambiente de desenvolvimento.

Mas além de desligar e desprovisionar, os ambientes de desenvolvimento também podem ter algum tipo de limite e modificação. Então, por exemplo: você não pode criar instâncias do tamanho x no ambiente de desenvolvimento sem que haja uma aprovação, uma conversa: ouvimos histórias de empresas onde se criam máquinas enormes para fazer um teste de carga que, na prática, nunca vão precisar, e de repente esquecem ligadas ou usam por tempo demais. Ambiente de desenvolvimento é, portanto, algo que pode e deve ser muito bem trabalhado nessa equação.

Se pegarmos a lógica da otimização do uso, temos uma série de situações onde é possível fazermos uma escala vertical – aumentando e diminuindo o tamanho de componentes – mesmo em produção, quando não existe a demanda. Hoje em dia, é bem claro: dependendo das aplicações, nós temos: horário comercial versus horário de folga. Mas toda aplicação geralmente tem uma certa sazonalidade. Uma folha de pagamento, por exemplo: chega no fim do mês, precisa de mais servidor, porque vai rodar tudo ao mesmo tempo. Eu vejo que ainda existem muitas empresas com relativa dificuldade de entender como funciona essa sazonalidade.

E a sazonalidade pode ser aproveitada para ligar e desligar, para refazer seu provisionamento, aumentar ou diminuir o seu ambiente. Veja isso como uma boa oportunidade: identifique essa sazonalidade, lógico que dentro da arquitetura da sua aplicação – tem aplicação que dá pra escalar, tem aplicação que não dá pra escalar; tem banco de dados que dá para desligar, tem banco de dados que não dá para desligar ou mesmo rebootar – hoje em dia temos tantos componentes, que muitas será possível fazer isso. Até container, um fargate, por exemplo, você pode mudar uma task definition dele. Você pode rodar no fim de semana uma task definition de um fargate spot menor do que você rodaria durante a semana. Você já está economizando com spot, e poderá economizar muito mais ainda no fim de semana diminuindo a task definition.

Um terceiro ponto que observamos muito também, é a questão de componentes que não são utilizados. Muitas vezes são provisionados componentes que são cobrados. O clássico: na AWS você tem os famosos NAT gateways, para poder fazer conectividade entre as VPCs, entre as subnets. Então o NAT gateway é muito fácil de sair provisionando e depois esquecer que não precisa utilizá-lo. Ele acaba sendo um componente pouco utilizado e, no pior dos casos, mal utilizado. E como isso tudo entra na fatura, tudo acumulado e consolidado, aquele custo entra como uma obscuridade dentro da sua fatura se você não parar, se for a fundo e não encontrar que tem o NAT gateway com data transfer, e às vezes inter-região ou inter-zona de disponibilidade. 

Por conta de tudo isso, nós passamos a criar dashboards específicos de Data Transfer, onde é possível apontar exatamente quem é o ID, qual é o componente do produto, qual seja ele, qual é o NAT gateway, qual o tipo de tráfego, inter A-Z, inter-região, CloudFront, VPC, VPC peering, VPN. É preciso ter sempre em mente que a AWS vai cobrar absolutamente tudo. Então se você tiver uma requisição no API Gateway, se estiver no Lambda e transferir, tudo entra na fatura do Data Transfer out, inter-região e AZ. Mas é preciso quebrar essa história do data transfer para saber disso. A gente encontra algumas empresas que sofrem com essa questão do Data Transfer.

E é possível otimizar isso, por exemplo, às vezes tem um servidor que está transferindo demais, ou tem um servidor com um vídeo de imagens grandes e você descobre que tem uma taxa de transferência altíssima, às vezes terabytes por dia, e a sua conta da AWS vai ficar lá nas alturas. A questão do Data Transfer é algo com que é preciso se preocupar, e é necessário ter um acompanhamento diário de quanto está seu custo de Data Transfer, caso existam sistemas realmente afetados por ele. Porque da noite para o dia você pode ter uma mudança, uma anomalia e isso pode ficar extremamente caro.

Equipes FinOps: Abordagem para Times de Produto

Antes de sair montando time, ou delegando a responsabilidades de FinOps, é preciso estar claro dentro da empresa a importância de fazer esse acompanhamento de custos. Não somente o acompanhamento, mas a questão do rateio, para que haja a visibilidade do que está acontecendo em termos de custos na organização. Então o primeiro passo é colocar estrategicamente para todos que isso é importante. O segundo passo é o como fazer. E aí para motivar o “como fazer”, costumo contar uma história que acho interessante. A gente que é técnico sabe que hoje a TI está sendo mais valorizada nesses processos de digitalização que tivemos nos últimos anos. Mas, no geral, a TI sempre foi vista como um centro de custos, como um lugar obscuro onde tinha um monte de gente esquisita que suportava uma operação que não era tão estratégica dentro da empresa, e que custava muito caro e ninguém entendia nada.

Quando começamos a olhar com atenção para a questão dos custos, podemos entender isso como uma oportunidade estratégica para se aproximar da área comercial, da área financeira e da área de produtos. Porque se você sabe exatamente quanto custa a TI e começa a dialogar com os times financeiro e de produtos, irá naturalmente vender melhor a ideia da importância da TI. Então se você desenha um processo de FinOps onde consegue fazer o rateio das áreas, onde consegue fazer o chargeback, e alinhar orçamento separando o que é operacional do dia a dia, você traz negócios para dentro da TI.

Agora, como fazer isso? A gente vê empresas onde o FinOps está arraigado na equipe, ou seja, você sempre terá um responsável, de preferência um só, que será a pessoa que vai responder pelas variações. Geralmente, não deveria ser uma pessoa da área financeira, porque, aqui na nossa realidade, o financeiro está mais preocupado com a área de finanças inteira da organização, e não tem o entendimento de bits e bytes que acontece na cloud. Então uma pessoa que seja puramente financeira em uma área técnica, cobrando por exemplo porque o custo de S3 subiu, só vai gerar ruído, e talvez não seja muito produtivo.

Agora, um gestor que seja capaz de fazer a ponte entre as áreas de negócio e a equipe técnica, e esteja sempre preocupado e de olho no que pode estar acontecendo, essa pessoa pode se tornar um “FinOps hero”, no jargão que as equipes da área brincam. Este é um papel que não é interessante para uma pessoa que é puramente técnica – mexer com planilha de Excel para fazer consolidação de custos – ninguém quer fazer isso, e se ninguém quer fazer isso, vai precisar de um terceiro, uma ferramenta ou uma empresa como a Elven para ajudar as equipes a fazer isso. Essa pessoa será a responsável por cobrar a equipe no momento certo, na dose certa, pela questão do uso racional de toda a infraestrutura.

Então é preciso ser alguém que tenha o conhecimento, com uma ferramenta para apoiá-lo a tomar as decisões que o ajudam a acompanhar de perto o dia a dia das coisas. A gente já observou também organizações onde a área de Governança assume essa parte dos custos, mas aí é preciso ter uma certa maturidade, porque o nome às vezes assusta, por ser uma pessoa que sempre vai estar no pé mas com um papel importante, fazendo com que os processos acordados entre as áreas sejam cumpridos.

Então, se nós acordamos que você tem um budget, e esse budget precisa ser reportado ou populado uma vez por mês, e a equipe não faz, quem está errado? É a governança de cobrar, ou a equipe de não ter feito? Então a governança funciona, desde que haja uma maturidade. E o que não deve ser feito? Delegar isso a uma pessoa com perfil junior. Primeiro porque vai ser uma tremenda batata quente colocar isso no colo de uma pessoa que não sabe nada de tecnologia para se tornar, aí sim, alguém muito chato, porque ele não entende, não tem o conhecimento para cumprir a tarefa. A outra coisa importante é: ou faz sério, ou não faz. Ou seja, ou faz direito ou não faça pela metade.

Quando eu digo fazer direito, veja bem não é fazer tudo, mas fazer pelo menos o mínimo. Isto é: se a gente tiver um determinado budget que for ultrapassado, vamos tomar ações específicas. Vamos instituir, por exemplo, que iremos atentar todos os dias para determinados custos. Ou seja, é ter um mínimo de regras: vamos colocar tag em todos os lugares, vamos definir o escopo e como iremos evoluir. Ou então, dependendo da maturidade da empresa, é possível ter uma equipe dedicada ao FinOps (a menos que você esteja desenvolvendo toda a estrutura para integrar dentro da empresa, mas aí é outro porte de organização, por exemplo, grandes bancos). Mas acho desnecessário essa questão de fazer do desenvolvimento interno uma coisa que seja muito sofisticada. Mas… tem que fazer.

Árvore de contas: como ter sucesso em instâncias reservadas e Savings Plans

Quando você compra uma instância reservada na AWS, uma all upfront, onde você paga 100% à vista e o custo subsequente dos meses é zero. Então, amortizando, você pagou x mil agora, e os próximos meses vai ser zero. O one-blended vai ser sempre zero. O blended vai misturar, vai pegar o custo que você tem on-demand, vai fazer uma mistura e vai ratear entre as contas. Isso, ao meu ver, não é nada bom, porque uma conta que se beneficiou de uma instância reservada, que tinha custo zero, se você contar o custo blended, ela passa a ter um novo custo. Então, por exemplo, dentro do Cloud8 a gente simplesmente ignora o blended. A gente só trabalha o one-blended porque não faz sentido essa mistura. Mas, em contrapartida, a AWS também tem uma questão de alocação da instância reservada.

Quando você compra um saving plan, que é mais genérico ainda, ele aloca onde você tem a economia maior. O tipo de instância, a região, se você tem um produto, um SQL Server Enterprise etc, onde vai gerar uma economia maior. Quando você busca na AWS pelas ferramentas deles onde esses custos estão alocados, geralmente ele aloca na conta pagadora, ou seja, não faz o rateio entre as outras contas. Então, por exemplo, dentro da nossa plataforma, a gente tem a conta pagadora, e rateamos entre quem efetivamente recebeu o benefício desses “descontos” que pagamos adiantado. Existem duas coisas aqui: a questão do dia a dia, você comprou e quer saber como está utilizando; e a recomendação.

Hoje em dia, a recomendação de Savings Plans e de instância reservada pode e deve ser feita dentro do próprio console da AWS. Eles têm a recomendação, você consegue fazer as simulações de vários tipos de saving plan geral, Compute, por região, por tipo, um ano, três anos, all partial e no upfront e consegue enxergar a realidade melhor. Pode levar em conta os últimos x meses, as últimas semanas, você faz a sua previsibilidade lá. E o mais legal é que você não precisa comprar tudo de uma vez.

Então, por exemplo, se você comprar 10 dólares por hora, vai sair uma fortuna, são 7440 dólares por mês de 31 dias; mas se não quiser comprar 10 dólares de cara, você pode comprar 1 dólar parcial, e fazer aquele mesmo esquema: acompanha, espera alguns dias para ver como está alocado, compra mais 1 dólar, mais outro, e vai indo, até chegar no seu limite de savings plan. Mas a recomendação pode ser feita no próprio console da AWS. É ainda um negócio meio difícil de entender, mas uma das nossas missões é facilitar essa questão. 

Assista ao vídeo com a íntegra do bate-papo:

Experimente agora, grátis!