Os três pilares para construir uma cultura de otimização de custos na sua empresa — e um guia passo a passo para colocá-la de pé com os produtos da DoiT.
Em muitas empresas, otimizar custos é quase sempre uma reação de pânico, motivada por algum evento externo — como o time financeiro tomando um susto com a fatura ou a necessidade de reduzir o burn rate antes de uma rodada de captação.
Se a sua empresa se encaixa nesse cenário, está na hora de promover uma postura mais proativa em toda a organização. Otimização de custos não pode ser tarefa de uma pessoa só. Cada engenheiro e cada usuário da nuvem precisa se importar.
Mas, para que seus usuários da nuvem se importem, é preciso despertar um senso de responsabilidade e de propriedade sobre os custos da nuvem em todos eles. Isso só acontece quando esses usuários têm visibilidade dos próprios custos. E essa visibilidade só vem com uma alocação de custos bem feita — o mapeamento dos custos de nuvem até seus respectivos donos.
YouTube
Toque para ativar o som
Erro 153
Erro de configuração do player de vídeo
Acesse o YouTube para buscar mais vídeos
Quando os usuários da nuvem têm clareza sobre seus custos, passam a se importar mais com eles. Fazem perguntas melhores sobre o porquê dos valores e ganham autonomia para agir de forma proativa — seja levando o custo em conta no design de novas funcionalidades, seja atacando antes da hora despesas que vêm subindo aos poucos.
A seguir, vamos passar pelos três pilares para construir uma cultura consciente de custos na sua empresa, transformando essa prática em um exercício contínuo entre todos os usuários da nuvem.
Dica #1 - Alinhe sua hierarquia de recursos à estrutura organizacional
O ideal é organizar seus recursos de nuvem de um jeito que reflita a estrutura real da sua empresa. As Folders do Google Cloud ou as Organizational Units (OUs) da AWS são uma ótima forma de fazer isso.
Elas servem para separar e categorizar recursos entre diferentes departamentos/times da sua organização. Dentro delas, você terá projetos (Google Cloud) ou contas (AWS), com cada um dos seus workloads pertencendo a um único projeto/conta.
YouTube
Toque para ativar o som
Erro 153
Erro de configuração do player de vídeo
Acesse o YouTube para buscar mais vídeos
Sem essa estrutura, prepare-se para enfrentar problemas como recursos espalhados, dificuldade na atribuição de custos e gestão de acessos complicada.
O conceito não é nenhuma novidade na programação. A Lei de Conway diz que a forma como os times se comunicam e se organizam influencia diretamente os produtos ou sistemas que criam. Da mesma maneira, na computação em nuvem, quando você estrutura seus recursos espelhando a organização da sua empresa, a gestão e a colaboração ficam muito mais fluidas.
Isole seus workloads em contas/projetos próprios
Além disso, é fundamental isolar os workloads em contas AWS ou projetos do Google Cloud próprios. É comum encontrarmos clientes que mantêm todos os workloads em uma única conta/projeto ou que compartilham projetos/contas entre vários times.
Quando você junta workloads sem relação na mesma conta ou projeto, gerenciar custos e acompanhar o uso vira uma dor de cabeça.
YouTube
Toque para ativar o som
Erro 153
Erro de configuração do player de vídeo
Acesse o YouTube para buscar mais vídeos
Imagine, por exemplo, que você tem recursos de duas aplicações diferentes no mesmo projeto do Google Cloud. Ao não isolá-los em projetos/contas distintos, você passa a depender excessivamente de uma higiene de tagging perfeita (mais sobre isso na próxima dica). E, conforme sua organização cresce, essa abordagem só aumenta a complexidade na hora de atribuir custos.
Sempre que possível, mantenha um único workload em uma única conta/projeto. Mas, quando você tiver workloads pequenos com escopos parecidos, pode fazer sentido colocar todos na mesma conta (veja a ilustração abaixo).
De novo, a ideia não é nova para quem programa. Isolar workloads de nuvem em contas ou projetos separados está alinhado ao princípio de "loose coupling" (acoplamento fraco), que consiste em projetar componentes ou módulos independentes que interagem entre si com o mínimo de dependências.
Ao segregar workloads em contas ou projetos distintos, você cria ambientes independentes, com pouca dependência entre si. Os benefícios vão muito além de uma alocação de custos mais simples — você também ganha recursos nativos de segurança operacional, como estruturas de permissão e rate-limiting, ao separar seus workloads.
Dica #2 - Aplique tags e/ou labels nos seus recursos
Tags (AWS, Azure) e Labels (Google Cloud) servem para fornecer informações granulares sobre os seus recursos de nuvem.
Os casos de uso incluem:
- Enriquecimento de billing (ex.: incluir informações de centro de custo em um recurso)
- Classificação de ambiente/aplicação (ex.: definir níveis de segurança de dados)
- Automação (ex.: definir agendamentos de reboot)
Focando no primeiro caso de uso, tags e labels têm um papel essencial na alocação e no acompanhamento de custos.
As tags ajudam a categorizar recursos por ambientes, times e muito mais, deixando claro o uso entre essas categorias. Combinadas com contas bem definidas, as tags facilitam personalizar relatórios para times, aplicações e outros recortes específicos, graças aos filtros mais precisos que você consegue aplicar.
YouTube
Toque para ativar o som
Erro 153
Erro de configuração do player de vídeo
Acesse o YouTube para buscar mais vídeos
Boas práticas para aplicar tags em recursos de nuvem
Pode ser tentador montar uma estrutura super detalhada, com várias tags diferentes que devem ser aplicadas a cada recurso. Esse nível de detalhamento até é admirável, mas pouco realista no começo. Recomendamos começar pequeno, com 2 ou 3 tags apenas, e ser bem rigoroso na hora de aplicá-las.
As três tags absolutamente indispensáveis (na nossa opinião) são:
- Nome da aplicação (ex.: "app_name")
- Time (ex.: "team")
- Estágio/ambiente (ex.: "env")
Como as tags diferenciam maiúsculas de minúsculas, recomendamos adotar um padrão de nomenclatura, como snake case, para evitar duplicação. Os nomes podem, claro, ser ajustados à cultura da sua empresa, mas devem ser descritivos e claros. Neste caso, "app_name" se refere ao nome de um microsserviço ou workload, e "env" a um estágio de desenvolvimento, como "development", "testing" ou "production".
O ideal é que os valores dos dois campos venham de uma lista relativamente padronizada. Mais uma vez, se houver pessoas marcando recursos com variações como "Website - Backend", isso pode gerar dor de cabeça na hora de analisar os dados.
Um exemplo em que as tags ajudam você a entender melhor o seu consumo de nuvem é quando há uma conta de "recursos compartilhados" na organização e todos os recursos de banco de dados (usados por vários times) ficam por lá. Para cada banco, você pode atribuir uma tag ou label que define qual time deve ser cobrado pelo uso desse recurso.
Falamos mais sobre isso no nosso post Resource Labeling Best Practices.
Dica #3 - Configure relatórios em tempo real e alertas customizados
De nada adianta definir uma hierarquia de recursos de nuvem bem organizada e marcar tudo direitinho com tags se você não oferece aos seus usuários da nuvem relatórios e alertas em tempo real com esses dados segmentados. Qual o sentido?
O "Efeito Prius"
No livro "Cloud FinOps", da O'Reilly, os autores explicam o "Efeito Prius", traçando paralelos entre o impacto dos relatórios em tempo real no comportamento dos engenheiros (mais conscientes de custos) e a experiência de dirigir um Prius.
Ao dirigir um Prius, você recebe informações em tempo real sobre o consumo de energia e quanto tempo falta até a bateria acabar. Pise fundo no acelerador e verá o consumo subir e o tempo até a bateria zerar despencar. Essa informação pode levar a uma direção mais sensata. Ou você pode decidir que, como está com pressa, vale a pena acelerar mesmo que isso esgote a bateria mais rápido.
Independentemente do que você faça com a informação, o ponto é que agora você toma uma decisão mais consciente, com dados que antes não tinha.
Relatórios em tempo real viabilizam decisões descentralizadas e bem informadas
Os relatórios de custo de nuvem em tempo real, assim como um Prius mostrando o impacto do consumo de combustível na vida útil da bateria, oferecem insights imediatos e dão autonomia para que os usuários da nuvem tomem decisões informadas sobre as partes da infraestrutura pelas quais são responsáveis.
E, embora a virada para uma postura mais consciente em relação aos custos não aconteça da noite para o dia, os relatórios em tempo real influenciam o comportamento rumo a decisões mais eficientes em custo no futuro.
Eles devem vir na forma de relatórios de custo e uso, dashboard(s), orçamentos e outros alertas customizados que entregam informações relevantes para o usuário da nuvem que está consultando. Ou seja, qualquer relatório consultado por um usuário da nuvem deve ser filtrado (com alguma combinação das suas tags e contas relevantes) para mostrar apenas o consumo pelo qual ele e/ou seu time são responsáveis.
Como impulsionar uma cultura consciente de custos com a DoiT
Empresas nativas digitais usam o portfólio de produtos da DoiT — junto com a sua rede global de expertise em nuvem para FinOps e suporte de infraestrutura — para tomar decisões mais informadas sobre o uso da nuvem.
Veja a seguir um guia passo a passo de como muitos clientes da DoiT promovem uma cultura de consciência e responsabilidade sobre custos entre seus times de engenharia.
Mapeie os custos de nuvem para suas categorias de negócio
O primeiro passo para fazer alocação de custos é definir os agrupamentos de negócio aos quais você quer alocar os custos. No DoiT Cloud Intelligence™, isso é feito com Attributions. As Attributions ajudam você a agrupar recursos de nuvem e organizar os custos do jeito que você quer alocá-los.
Abaixo, dois exemplos de uso de Attributions para mapear custos em diferentes categorias de negócio.
No primeiro, definimos os custos de uma aplicação agrupando três contas AWS diferentes.
Mapeando custos de nuvem para uma aplicação hipotética
No segundo, definimos os custos de um time de engenharia de produto (no caso, "Team Bruteforce") como qualquer recurso com Label "team" ou Project Label com valor "bruteforce".
Mapeando custos de nuvem para um time de engenharia hipotético
Crie relatórios em tempo real e dashboards
Você pode então usar Attributions em Reports — e, mais adiante, em Dashboards — para filtrar o consumo específico de um time, ambiente, app ou qualquer outro recorte que tenha definido com Attributions.
Por exemplo, abaixo usamos a nossa Attribution "Application A" como filtro, detalhando esses custos por serviço e exibindo apenas os 10 maiores em termos de custo.
Relatório de custo de nuvem detalhando os custos de uma aplicação definida com DoiT Attributions
Você pode então agendar a atualização e o envio recorrente desse relatório para os usuários da nuvem aos quais ele é relevante. É uma forma simples de começar a aumentar a consciência das pessoas sobre o impacto delas nos custos de nuvem.
Agendando o envio recorrente de um relatório de custo de nuvem
Você também pode criar um dashboard específico para um time ou app, dando aos usuários da nuvem relevantes uma visão completa dos próprios custos. Abaixo, adicionamos o nosso relatório "Application A - Service Cost" a um novo dashboard que criamos e que vai conter outros relatórios relacionados ao consumo dessa aplicação.
Adicionando um relatório de custo de nuvem de uma Application a um dashboard com outros relatórios sobre essa Application.
O dashboard abaixo é um exemplo do que você pode criar para o seu time, além de agendar relatórios específicos para os usuários da nuvem aos quais eles são relevantes.
Dashboard com relatórios customizados de custo de nuvem em torno de uma Application específica
Alertas customizados e Anomaly Detection direcionado
Além dos relatórios, alertas em tempo hábil — que avisam os usuários quando devem dar uma olhada mais atenta em algum aspecto do gasto em nuvem — também ajudam a aumentar a consciência e a responsabilização.
Configure alertas granulares de custo de nuvem para stakeholders
Por exemplo, clientes da DoiT configuram Alerts quando querem que stakeholders fiquem atentos ao uso em níveis mais granulares.
Abaixo, configuramos um alerta de custo limitado à nossa Attribution "Application A". Da forma como está configurado, seremos avisados sempre que o custo para atender qualquer cliente — definido pela seleção da tag "customer" no dropdown Evaluate for each — aumentar 25% ou mais, semana a semana. O dropdown Evaluate for each é muito útil quando você quer avaliar separadamente cada instância de uma mesma dimensão (por exemplo, cada um dos seus namespaces de Kubernetes).
Um alerta que nos avisa sempre que o custo para atender qualquer cliente — definido pela seleção da tag "customer" no dropdown Evaluate for each — aumenta 25% ou mais, semana a semana
Configure Anomaly Detection direcionado
O Anomaly Detection da DoiT funciona monitorando picos de custo de forma autônoma e avisando você quando detecta gastos anômalos, para que você minimize o impacto na sua fatura. Por padrão, ele identifica comportamentos anormais para cada SKU em cada conta ou projeto que você possui.
Exemplo de anomalia detectada para o SKU DataTransfer-Out-Bytes do AWS S3
Sistemas de detecção de anomalia normalmente fornecem insights sobre o uso de nuvem da organização inteira. Mas essa abordagem ampla acaba bombardeando os times com notificações que não têm relação direta com o que eles fazem.
Já com o Anomaly Detection da DoiT, você pode inscrever usuários da nuvem em alertas de anomalia específicos para os custos pelos quais eles são responsáveis, usando Attributions. Isso leva os alertas de anomalia a outro nível, permitindo que os seus times ajustem com precisão quais alertas recebem, focando apenas nos custos de nuvem pelos quais são responsáveis.
Depois de criar uma Attribution, basta ativar o Anomaly Detection para ela.
Ative o Anomaly Detection para os recursos de nuvem de uma Application específica
Depois, é só entrar nas configurações de notificação das pessoas responsáveis pela Application A e inscrevê-las nos alertas relacionados àquela Attribution (ou elas mesmas podem fazer isso).
Como se inscrever nos alertas de anomalia para uma Attribution específica
Construir uma cultura consciente de custos em toda a empresa não é tão simples quanto pedir aos usuários da nuvem que se importem mais com o assunto. Você precisa entregar a eles os dados que mostrem o custo do próprio trabalho.
E, para entregar os dados mais precisos sobre o impacto de cada pessoa ou time na fatura de nuvem, é preciso alinhar a sua hierarquia de recursos à estrutura organizacional, definir as tags adequadas e marcar seus recursos com elas. Mas o verdadeiro poder está em combinar esses passos fundamentais com mecanismos de relatório e alerta em tempo real.
Você consegue fazer as duas coisas com a DoiT, começando pelo trabalho com nossos especialistas em FinOps para definir as tags que você deve criar — caso ainda não as tenha — e uma hierarquia de recursos que faça sentido para a estrutura da sua empresa.
Com isso estabelecido, você pode usar os produtos da DoiT para entregar relatórios e alertas relevantes em tempo real aos seus usuários da nuvem.
Se você já é cliente DoiT, pode seguir agora mesmo o passo a passo descrito acima no DoiT Cloud Intelligence. Se ainda não, entre em contato com a gente para ver como aproveitar os produtos e serviços de consultoria da DoiT em qualquer fase da sua jornada na nuvem.