Terraform para governança de custos Cloud

Se você chegou até este artigo sobre Hashicorp Terraform, são grandes as chances de você ter responsabilidades DevOps (ou arquitetura Cloud) e está se perguntando: “Por que eu deveria me importar com a otimização de custos de nuvem? Essa responsabilidade não é minha, eu não estou em governança e nem finanças FinOps, certo?” Errado!

Os engenheiros e arquitetos Cloud estão se tornando os novos gestores financeiros de tecnologia da informação à medida que as equipes de governança e/ou financeiro começam a perder parte de seu controle direto sobre novos modelos de consumo sob demanda de infraestrutura em nuvem.

Então a questão que grande parte de nossos clientes nos perguntam sobre governança em nuvem é: Quais deveriam ser processos, o modelo de times e as tecnologias que posso usar para suportar esta transformação digital que a nuvem acelerou?

Cloud Center of Excellence e Terraform

Se você estiver interessado em definir processos de centro de excelência em nuvem (CcoE), ou apenas definir papeis e responsabilidades pela governança de nuvem e implementar um processo de otimização de custos com usando hashiCorp Terraform Cloud, você está no artigo correto. Vamos juntos!

Este artigo em formato de guia fornecerá:

• Um modelo RASCI atribuindo responsabilidades para a equipe que gerencia a opera os custos de nuvem;
• Uma visualização de como pode ser feito o gerenciamento de custos em nuvem dentro de um Workflow de provisionamento Terraform;
• Recomendações de planejamento para gestão de custos em nuvem e previsibilidade (forecast) com a Terraform;
• Uma introdução ao uso dos recursos de estimativa de custos da Terraform;
• Instruções sobre como integrar e usar ferramentas de otimização de custos de fornecedores de nuvem AWS, Azure e GCP (Google Cloud Platform) e também de terceiros, com os workflows Terraform;
• Exemplos da política do Terraform usando códigos com o Sentinel, possibilitando automaticamente o bloqueio de gastos excessivos, usando regras de custos, tipos de instância e tags.

A maioria dos recursos que citamos neste artigo se concentrará na funcionalidade paga da Terraform, como Estimativa de Custos e Governança & Política (Cost Estimation and Governance & Policy), mas o principal caso de uso em torno da otimização de custos pode ser alcançado apenas com a versão open source.

Uma pesquisa sobre gastos desnecessários em nuvem

Com a mudança para os custos baseados em consumo de infraestrutura e operações; ou seja, utilizando-se de provedores de serviços em nuvem (CSPs) ou simplesmente provedores de nuvem, você paga pelo que usa, mas também paga pelo que provisiona e não usa.

Se você não tem um processo de governança e otimização contínua, então há uma grande chance de que seus gastos em nuvem estão em excesso, pagando pelo desnecessário.

Uma pesquisa da Densify recente sobre gastos em nuvem descobriu que:

• 45% das organizações relataram que estavam acima do orçamento para seus gastos em nuvem;
• Mais de 55% dos entrevistados estão usando processos manuais complexos ou simplesmente não implementam ações e mudanças para otimizar seus recursos em nuvem;
• 34,15% dos entrevistados acreditam que podem economizar até 25% de seus gastos em nuvem e 14,51% acreditam que podem economizar até 50%. O mais impactando da pesquisa foi que, 27,46% disseram: “Eu não sei”.

Por que os engenheiros e arquitetos cloud estão se tornando os controladores financeiros de custos em nuvem

Ao fazer a migração para a nuvem, a maioria das organizações tem pensado em modelos básicos de governança onde uma equipe, às vezes referida como o Cloud Center of Excellence, foca em áreas como estratégia, arquitetura, operações e custo.

A maioria dessas equipes contém uma combinação de especialistas técnicos em gerenciamento de TI e nuvem e áreas de finanças comuns à TI. No entanto, os times de finanças são cobrados principalmente pelo planejamento de custos, previsão financeira de migração e otimização de contratos de software.

Devido às pressões financeiras, eles tendem a dizer: “Precisamos controlar os custos, as economias, as previsões para os próximos períodos, etc.” mas não temos controle direto sobre o uso dos custos.

São os engenheiros e arquitetos cloud que gerenciam diretamente a infraestrutura e os custos e de forma ainda mais arriscada, os revendedores de cloud (cloud brokers) quem “tomam conta” destes custos.

Neste caso, percebemos uma mudança de paradigma da governança de Tecnologia da Informação e financeiro onde:

• Os engenheiros e arquitetos cloud não são mais apenas responsáveis pelas operações, mas também pelos custos;
• Os engenheiros e arquitetos cloud agora têm as ferramentas de Cloud Management Platform (CMP) e recursos para automatizar e gerenciar diretamente controles de custos;
• O planejamento de custos e o forecast (estimativa futura) para a execução de Workflows em nuvem não são facilmente compreendidos pelas áreas financeiras;
• As formas tradicionais de orçamento financeiro e planejamento de demanda de hardware on-prem (como orçamentos baseados em contratos e compras em Capex) não explicam ou controlam a complexidade de custos em modelos baseados em consumo (ou seja, cloud).

Como foco e para ganhos rápidos, a área financeira de TI precisa manter o controle para as duas principais áreas de redução de custos:

• Pré-provisionamento: Governança limitada e controle na fase de provisionamento de recursos.
• Pós-provisionamento: Governança limitada e controle na aplicação de mudanças de infraestrutura para redução de custos.

Nas seções a seguir, definiremos juntos boas práticas para: Pessoas, Processos e Tecnologias (plataforma) associadas ao gerenciamento de práticas financeiras em nuvem com Terraform.

Para simplificar as coisas, assumiremos que possuem uma estrutura de governança em nuvem — ou seja, o Cloud Center of Excellence (CCoE) — que é responsável por gerenciar a governança geral em nuvem.

Nesta equipe que estruturamos há quatro papéis principais:

• Gerenciamento de TI (IT Management);
• Finanças (FinOps);
• Engenharia Cloud (composta por DevOps e Infraestrutura e Operações);
• Segurança (SecOps);

Este modelo pode ser usado como uma linha de base de funções e atuações para esta equipe de Governança nuvem (Cloud Management).

Este é um modelo que usamos, juntamente com modelos semelhantes como Software Asset Management (SAM), para definir os papéis e responsabilidades do Cloud Center of Excellence para muitas organizações.

Planejamento, Otimização e Governança

Como os engenheiros e arquitetos cloud podem usar o Terraform em cada nível do processo de gerenciamento de custos em nuvem para fornecer valor e minimizar trabalhos adicionais?

Para começar, veja como a visualização ilustra o papel do Terraform no ciclo de vida de gerenciamento de custos em nuvem. Comece no topo com a fase Planejamento ou planning:

Resumimos agora os passos:

• Comece identificando cargas de trabalho (workloads) que estão migrando para a nuvem;
• Crie a configuração Terraform;
• Executar o terraform plan para executar a estimativa de custos;
• Executar o terraform apply para a provisão dos recursos;
• Uma vez provisionadas, os workloads serão executadas e as ferramentas CMP (cloud Management platform) fornecerão recomendações de otimização;
• Integre as recomendações de otimização de um fornecedor no Terraform e/ou no seu pipeline de CI/CD;
• Investigue e analise recomendações de otimização e implemente as políticas (sentinel policies) do Terraform para controles de custo e segurança;
• Atualizar a configuração do Terraform e executar o plano e aplicar;
• Recursos recém-otimizados e compatíveis, são agora serão provisionados.

Planejamento — Pré-Migração e Previsão de Custos Contínuos

As migrações em nuvem exigem uma avaliação de vários pontos para determinar se faz sentido mover um aplicativo/carga de trabalho para a nuvem. Os fatores primários para a avaliação são:

• Arquitetura e Righsizing do ambiente atual;
• Business Case;
• Custo estimado para a mudança;
• Custos contínuos de utilização orçado/previsto para os próximos 1-3 anos, em média.

Uma vez que os engenheiros e arquitetos cloud estão agora assumindo algumas dessas responsabilidades, faz sentido usar ferramentas de engenharia para lidar com elas.

O Terraform ajuda os engenheiros e arquitetos cloud a assumir essas novas responsabilidades com a estimativa de custos (cost estimations), que ajuda a calcular os custos de infraestrutura de cada provisionamento executado com base no plano de implantação real (deployment plan).

Usando arquivos de configuração Terraform como uma definição padrão de como o custo de um aplicativo/workflow é estimado, agora você pode usar APIs Terraform Cloud & Enterprise  para fornecer informações financeiras automaticamente com dados financeiros estimados em nuvem ou usar a interface de usuário do Terraform para fornecer acesso direto financeiro aos custos.

Ao fazer isso, você poderá eliminar muitos processos que não foram otimizados para redução de custos.

Recomendações de planejamento:

• Use arquivos de configuração terraform como a definição padrão de planejamento e previsão de custos em nuvem em AWS, Microsoft Azure e GCP (Google Cloud Platform), e forneça essas informações através da API Terraform ou controles de acesso baseados em papéis dentro da interface de usuário Terraform para fornecer um padrão financeiro para workflow de provisionamento automatizado.

Nota: Muitas organizações realizam planejamento financeiro dentro do Excel, do Google Sheets e ferramentas de Cloud Management Platform (CMP). Para conectar e utilizar os dados dentro desses sistemas acima, recomendamos o uso da API de Estimativas de Custos da Terraform  para extrair os dados.

• Use módulos Terraform  como unidades padrão de infraestrutura definida para avaliações de custos e planejamento de demanda em nuvem.
  • Exemplo: Defina um conjunto padrão de módulos para uma aplicação Java padrão, de modo que o módulo A + B + C = $X por mês. Planejamos mover 5 aplicativos Java este ano. Esta pode ser uma metodologia rápida para avaliar os custos potenciais de execução de aplicativos antes de definir os arquivos reais de configuração do Terraform.

• Use o Terraform para entender o crescimento de custos de aplicativos/cargas de trabalho ao longo do tempo, ou seja, custos de expansão e ou migração em nuvem.
• Tente alinhar estruturalmente as convenções de nomeação de Organizações Terraform, Espaço de Trabalho e Nomeação de Recursos ao processo de orçamento/previsão financeira.

Há um guia para começar com a Terraform Cost Estimation.  Uma vez habilitado, quando um plano Terraform é executado, o Terraform chamara as APIs de estimativa de custos da AWS, Microsoft Azure e/ou GCP para apresentar o custo estimado para esse plano, que pode ser usado de acordo com seu fluxo de trabalho financeiro. Você também pode exportar este relatório de estimativa como JSON.

Exemplo de Estimativa de Custos usando Terraform

Exemplo de carga API JSON de Estimativa de Custos do Terraform

Esteja ciente de que a Estimativa de Custo terraform fornece custos com base em uma visão do espaço de trabalho (workspace).

Se precisar de uma visão de espaço de trabalho mais apurada com cross-workspace, você precisará aproveitar a API de estimativa de custos terraform em conjunto com uma ferramenta de relatórios de sua escolha, como por exemplo Microsoft PowerBI.

Ferramentas úteis para visualização de custos em várias nuvens

O HashiCorp Terraform, construiu uma ferramenta simples de código aberto que pode lhe dar essa visão de espaço de trabalho mais alto e transversal. A ferramenta se chama Tint e você pode visitar este post no blog e o repositório GitHub do criador Peyton Casper  repositório GitHub  para aprender como usá-la.

Se você tem requisitos complexos para reportar, ou já tem um produto de relatórios corporativos existente (por exemplo, Microsoft BI, Tableau, etc.), os dados de estimativa de custos da HashiCorp Terraform também funcionarão com essas soluções.

Otimização — Operacionalizando e realizando economia contínua de custos

Otimização Cloud é a prática contínua de avaliar a relação de custos e benefícios do uso atual da infraestrutura de nuvem.

Os fornecedores de nuvem (Amazon AWS, Microsoft Azure, GCP, Oracle Cloud, etc.) e outras ferramentas de terceiros podem começar com algumas recomendações de otimização, mas algumas organizações nem sempre se aproveitam das recomendações, por uma lacuna de automação.

Os engenheiros e arquitetos Cloud nem sempre se envolvem com plataformas e tópicos de otimização, deixando-os sem visão de como está sendo o seu trabalho no que tange ao impacto de custos.

Mesmo em casos em que eles estão envolvidos com essas plataformas de CMP, muitas vezes há um alto nível de intervenção manual necessária para reduzir custos.

Automatizando insights de otimização junto ao Workflow de provisionamento

É seguro dizer que os principais CSPs e a grande maioria das ferramentas de CMP (Cloud Management Platform) como por exemplo Vmware CloudHealth e Snow Software Embotics, permitem exportar recomendações de otimização através de uma API ou de um método alternativo (referências: AWS,  Azure,  GCP).

Neste guia, vamos focar na abordagem mais básica para automatizar a ingestão de dados de otimização, que virá diretamente dos CSPs ou de terceiros como o Densify  que mantêm um Módulo HashiCorp Terraform. Usaremos o Densify nos exemplos que se seguem.

Existem também muitos usuários hashicorp que querem criar seus próprios provedores Terraform  para processos semelhantes.

Os conceitos e códigos podem ser usados como modelo para suas próprias implantações.

Cada fornecedor fornece um conjunto diferente de recomendações, mas todas elas fornecem insights sobre processamento (computação), por isso vamos nos concentrar nisso.

Qualquer insight que você receber (por exemplo, computação e processamento, armazenamento, DB, etc.) pode ser consumido com base no padrão abaixo.

Padrões básicos para recomendações de otimização com Terraform

Para estabelecer um mecanismo para que o Terraform acesse as recomendações de otimização, apresentamos alguns padrões comuns:

• Fluxo de trabalho manual — Revisão das recomendações de otimização do portal de provedores e atualização manual dos arquivos HashiCorp Terraform. Como não há automação, isso não é o ideal, mas um loop de feedback para otimização pode começar daqui.
• Fluxo de trabalho de arquivos — Crie um mecanismo onde as recomendações de otimização sejam importadas em um repositório local através de um processo agendado (geralmente diariamente).
  • Por exemplo, os clientes densify usam um script para exportar recomendações em um arquivo densify.auto.tfvars  e ele é baixado e armazenado em um repositório acessível localmente. Em seguida, a função de busca Terraform é usada para procurar atualizações específicas de otimização que foram definidas como variáveis.

• Fluxo de trabalho da API — Crie um mecanismo para que as recomendações de otimização sejam extraídas diretamente do fornecedor e armazenadas dentro de um repositório de dados acessível usando a funcionalidade http data_source do Terraform para executar a referência de importação de conjunto de dados.
• Ticketing Workflow — Este fluxo de trabalho é semelhante aos fluxos de trabalho de arquivo e API, mas algumas empresas inserem uma etapa intermediária onde as recomendações de otimização primeiro vão para um sistema de controle de service desk e operação de TI, como ServiceNow ou Jira. Dentro desses sistemas há um fluxo de trabalho e a lógica de aprovação incorporada onde uma flag é definida para mudanças aprovadas e é passada como uma variável a ser consumida mais tarde no processo.

Otimização como Código: Exemplos de atualização de código HashiCorp Terraform

Em qualquer um desses casos, especialmente se processos de automação estiverem implementados, será importante manter os dados de recursos principais como variáveis.

As ferramentas de insight de otimização fornecerão uma recomendação de tamanho para recursos ou serviços (ou seja, computação, DB, armazenamento, etc.). Neste exemplo, usaremos recursos computacionais, mas o exemplo é representativo para todos.

No mínimo, recomendamos que tenham três variáveis definidas para realizar a atualização de otimização no Terraform com alguma lógica básica: new_recommendations,  current_fallbacke  resource_unique_id.

Como mencionamos, usaremos o Densify. Você pode encontrar o módulo Densify Terraform  através do Registro Terraform e do Repo Do Densify-dev no  GitHub.

No blog do Terraform você encontrará vários códigos criados, recomendamos o acesso e pesquisa.

Governança — Garantindo economia de custos futuros com HashiCorp Terraform

O último e crítico componente do ciclo de vida de gerenciamento de custos em nuvem é ter políticas criadas e definidas para parar os excessos de custos e fornecer reports para operação cloud.

No Terraform, você pode automatizar estes reports com o Sentinel, uma política como estrutura de código incorporada dentro do HashiCorp Terraform para governança e política (o Sentinel também pode ser usado em outros produtos HashiCorp).

Conformidade de custos como Código e Política Sentinela como Código

O Sentinel inclui um idioma específico de domínio (DSL) para escrever definições de política que avaliam todo e qualquer dado definido em um arquivo Terraform.

Você pode usar o Sentinel para garantir que os recursos provisionados sejam: seguros, possuam tags e estejam dentro das restrições de uso e custos.

Para custos, os clientes do Terraform implementam a política principalmente em torno de três áreas: (mas lembre-se, você não está limitado apenas a esses três):

Áreas de controle de custos:

• Quantidade — Controle a quantidade de gastos;
• Tamanho provisionado — Controle o tamanho/uso do recursos e rightsizing;
• Tempo de vida — Controle o tempo de vida (TTL) do recurso.

Em todas essas três áreas, é possível aplicar controles de políticas em torno de recursos como espaços de trabalho (workspaces) Terraform por exemplo: aplicativos/cargas de trabalho, ambientes: Produção, Desenvolvimento e Homologação e políticas de tags para otimizar recursos e evitar gastos desnecessários.

A seguir, um exemplo de saída de política sentinela ao executar plano terraform. Vamos nos concentrar em três políticas:

1. aws-global/limit-cost-by-workspace-type
2. aws-compute-nonprod/restrict-ec2-instance-type
3. aws-global/enforce-obrigatos-tags

O Sentinel tem três níveis de execução: Advisory, Soft-Mandatory e Hard-Mandatory — consulte o link fornecido para definições. O nível de execução ditará o fluxo de trabalho e a resolução de violações de políticas.

Se você estiver usando o Terraform Cloud for Business ou o Terraform Enterprise, os usuários poderão interagir com a UI Terraform, CLI ou a API para integrar totalmente em seus pipelines de CD/CD para controle de fluxo de trabalho de políticas e em sistemas VCS  como GitLab, GitHub e BitBucket para criação e gerenciamento de políticas.

Exemplos de código de governança de custo usando Sentinel em Terraform

Na política aws-global/limit-cost-by-workspace-type definida para este espaço de trabalho (que pode ser individual ou globalmente definida) aplicamos limites de gastos mensais e um nível de execução.

Você pode ver trechos no link que mostram limitadores de custo (US$ 200 para desenvolvimento, US$ 500 para QA e assim por diante).

O nível de execução como soft mandatory, o que significa que os administradores podem substituir falhas de políticas se houver uma razão legítima, mas isso impedirá a maioria dos usuários de gastar até esse valor.

O caminho para o gerenciamento de custos em nuvem

À medida que as organizações usam cada vez mais a infraestrutura em nuvem, a filosofia DevOps não pode mais ser ignorada. À medida que os silos entre desenvolvedores e operadores quebram, os silos também podem ser quebrados entre finanças e engenharia/arquitetura.

Os engenheiros e arquitetos cloud têm muito mais autonomia para implantar a infraestrutura de que precisam imediatamente. Isso significa mais responsabilidade para controlar esses custos por eles mesmos. Tecnologias como Terraform e Sentinel dão à engenharia fluxos de trabalho automatizados e monitorados por finanças que precisam para gerenciar custos e recuperar recursos não utilizados — tudo dentro da ferramenta que a maioria deles já usa.

Isso ajuda as organizações a evitar uma abordagem complicada e baseada outras plataformas e ao mesmo tempo em que evita o caos e o desperdício de Shadow IT.

Fonte: https://www.hashicorp.com/blog/a-guide-to-cloud-cost-optimization-with-hashicorp-terraform

Tag: terraform enterprise,terraform plan, terraform cli, google cloud,infrastructure as code, cloud infrastructure, google cloud platform, chave publica, rede virtual, hashicorp configuration language, terraform by hashicorp, oracle cloud, análises de segurança, preciso criar, code with terraform, human readable, arquivo maintf, provedores de nuvem, variáveis de ambiente, aws s3, execution plan, vamos criar, recurso da aws, escrever código, safely and predictably, declarative configuration, microsoft azure, cloud platform, configuration files, visual studio, bancos de dados, infraestrutura como código, máquinas virtuais, alta disponibilidade, configuration language, terraform para provisionamento, declarative configuration files, terraform cloud business tier, cloud providers, cloud provider, infra como código, azure devops, Cloud Center Of Execellence, Software Asset Management, infrastructure as code, provision infrastructure, solução de código, linha de comando, github actions, ambiente de produção, via terraform, plano de execução, modules from the registry, terraform pode ajudar, versões de infraestrutura, apis into declarative configuration, gerar um plano, integrações de infraestrutura, comando plano, infraestrutura como solução, access control, nuvens privadas, módulo de infraestrutura, running terraform, fluxo de trabalho típico, gerenciamento de infraestrutura, define infrastructure, vmware vsphere, aws resources, arquivos de configuração, quais suas aplicações, terraform vs, boas práticas, module registry, várias nuvens, cdk for terraform, terraform plan, terraform registry, data sources, fale conosco, terraform init, resource dependencies, terraform module, hashicorp cloud platform, aws infrastructure, controle de versão, ibm cloud, terraform associate, gráfico de recursos, terraform enterprise, google cloud, infraestrutura como código, provedores de nuvem, ciclo de vida, hashicorp configuration language, infraestrutura de que precisavam, infraestrutura em nuvem, estiver usando, terraform by hashicorp, oracle cloud, safely and predictably, execution plan, cloud infrastructure, google cloud platform, code with terraform, bancos de dados, microsoft azure, declarative configuration files