Compartilhamento de tags #
Existem casos de uso onde um componente utilizado por múltiplas contas, componente ‘grande’ ou ‘custoso’ e componente compartilhado por algum cenário de negócios precisa ter seu custo ‘quebrado’ entre diversas Tags.
Um exemplo prático seria um banco de dados que é utilizado por vários ‘centros de custos’ e precisa ser rateado entre eles. O cenário de uma tag única para este banco não comporta este rateio.
Nosso engine está bem avançado em vários cenários de rateio. Entre em contato com o seu caso de uso e faremos a configuração por enquanto (em breve teremos uma interface e daremos flexibilidade).
Rateio de valores #
Existem alguns casos de uso onde é necessário ratear um determinado valor de Tag entre os demais valores, sem perder a informação original.
Para deixar mais prático, imagine o cenário em que a Tag de nome “centrocustos” possui um valor “Infra”. Este “infra” contém todos os serviços periféricos de sustentação do cloud: logs, suporte, envio de alertas, emails, etc. Até mesmo serviços que não podem ser tagueados nativamente (ver “Tags faltantes”). Como ele representa o custo de operação do cloud, vê-se necessário ratear a ‘infra’ entre os demais valores do centro de custos.
Neste cenário, o Cloud8, para não perder a informação, trabalharia da seguinte forma:
- Cria-se uma cópia idêntica da tag ‘centrocustos’ que poderíamos chamar de ‘centrocustos-rateado’;
- Aplica-se a regra de rateio para suprimir os valores de ‘infra’ (e pode incluir outros como ‘infraestrutura’, ‘suporte’, etc) e ratear proporcionalmente entre os demais. Quem gasta mais, recebe mais custo de ‘infra’.
O cliente continua vendo o valor original em ‘centrocustos’ para fins de relatórios, análises de tagged, untagged e pivot table e agora também pode ter a visão com o rateio customizado que precisa.
Kubernetes – EKS e GKE #
Com a migração de aplicações que antes rodavam em instâncias ou clusters dedicados para uma nova estrutura Kubernetes, o que antes poderia ter um FinOps bem organizado, passa pelo desafio de reorganizar o rateio e visibilidade.
O cluster Kubernetes é composto por diversas instâncias, de vários tipos e sujeito a modelos de custos diversificados (spot, on demand, reservas e / ou savings plans aplicados). Elas, por sua vez, terão ‘pods’ (aplicações) alocados e desalocados com regras e frequências determinadas por um ‘scheduler’ técnico e consumindo parcialmente estes recursos. O desafio aqui é saber onde e quando cada pod rodou e o quanto de recurso consumiu.
Para coletar estes dados e fazer a conta do rateio, usamos as ferramentas nativas do AWS e GCP (Azure em breve) que podem ser habilitadas a qualquer momento. O GKE não possui custos extras, mas o AWS incorrerá em custos de CloudWatch que precisam ser acompanhados e avaliados. Dependendo do número de instâncias, este custo pode variar de poucos dólares até algumas centenas. Portanto, o benefício de visualizar os custos internos (e obscuros) deve ser avaliado sob a ótica do investimento em como extrair estes dados e quão complexo seria a gestão deles. Nossa proposta é simplificar e integrar dados internos aos dados de toda a infra, sem a necessidade de mais ferramentas de gestão.
Para habilitar os custos tanto de EKS como GKE, utilize a lista de componentes e clicando no botão direito, selecione a opção de ativação. Ela também traz as instruções de como fazer.
Veja mais: Como habilitar o compartilhamento de custos em ECS e EKS.
