Ao projetar um serviço sem servidor, cada peça do quebra-cabeça, cada serviço gerenciado que você seleciona, é uma escolha de compra. Além disso, tornar-se um serviço de nuvem de nível de produção traz custos adicionais, e as despesas podem aumentar rapidamente se você não prestar atenção.
Neste blog, você aprenderá como uma organização frugal prospera em uma mentalidade FinOps, que é crucial para otimizar custos e maximizar a eficiência em serviços de nuvem. Compartilharei estratégias e itens de ação para alinhar objetivos financeiros e operacionais na nuvem.
Enquanto discuto serviços sem servidor como exemplos, descrevo os insights, a automação e a cultura que beneficiam qualquer serviço e tecnologia de nuvem que você escolher.
Esses insights se originam da minha experiência projetando serviços sem servidor na CyberArk , uma provedora de SaaS baseada na AWS.
Índice
O equívoco sobre o custo do serverless
Como um herói do AWS serverless , sinto-me obrigado a abordar o elefante na sala ao discutir custos de nuvem e serviços sem servidor.
O modelo sem servidor tem sido o exemplo perfeito de pagar apenas pelo que você usa e chegar a zero.
Se for esse o caso, certamente o custo do serviço sem servidor de nível de produção é menor do que o dos serviços sem servidor, certo?
Bem, isso só é preciso algumas vezes. Claro, é uma afirmação verdadeira para os "verdadeiros" serviços serverless, como Lambda, SNS, SQS e DynamoDB, mas serverless inclui muito mais serviços, e novos sabores serverless de serviços AWS surgem a cada ano.
Por exemplo, você pode perceber que o DynamoDB não atende mais aos seus requisitos. Você pode usar o Amazon Aurora serverless, adicionar cache à mistura com o Elasticache serverless ou otimizar para pesquisas de palavras-chave com o OpenSearch serverless. Embora esses serviços tenham uma variante serverless, eles não escalam para zero; você sempre paga um preço mínimo, mesmo que não haja tráfego de clientes. Então, talvez seja melhor chamá-los de serviços gerenciados pela AWS, mas não verdadeiramente serverless. Além disso, esses serviços exigem uma VPC, que adiciona um custo predeterminado por mês de ENI, endpoints de VPC, etc.
Como observação lateral, Jeremy Daly discutiu a natureza sem servidor ou não tão sem servidor dos novos serviços da AWS no excelente podcast de Allen Helton , que eu recomendo fortemente.
Grau de produção significa custo extra
Não importa qual tecnologia você escolher para seus serviços de nuvem, você deve se preparar para a produção em algum momento. Regulamentações, segurança e requisitos de observabilidade devem ser abordados, e eles adicionam custos extras e geralmente negligenciados.
Vamos adicionar alguns desses recursos ao nosso serviço de pré-produção.
Precisamos adicionar recursos de criptografia de dados do cliente ao serviço. Podemos usar um KMS CMK para criptografar dados do cliente ou facilitar a comunicação de serviço para serviço. Um CMK custa 1$ por mês apenas para ser provisionado, sem incluir as chamadas de API, e um extra de 1$ quando você habilita a rotação automática de chaves. Você espera ter 10.000 clientes? Ótimo, são 20.000$ extras por mês adicionados à sua conta da AWS.
Sobre práticas de prontidão de produção. Vamos adicionar segurança e observabilidade da web .
Podemos habilitar um Web Application Firewall na distribuição API Gateway ou CloudFront e melhorar a observabilidade com CloudWatch Dashboards . Esses recursos vêm com um preço mensal constante apenas para provisioná-los, mesmo que seu serviço tenha tráfego mensal zero. Há muitos exemplos como esse.
Ao transformar seu serviço em um serviço pronto para produção, vários pequenos custos se somam, e as pessoas devem estar cientes. Claro, é apenas mais um CMK; é apenas uma linha para criar no AWS CDK; que mal isso pode fazer?
Se você usar várias contas (como deveria) — dev, test, production — então cada adição de custo pode ser potencialmente multiplicada pelo número de contas que você possui. Você implanta em 5 regiões por conta? Isso é um extra de 15 (5*3 - quantidade de contas) CMKS; multiplique novamente.
Esses custos aumentam significativamente, especialmente em contas de desenvolvimento, onde os recursos são implantados, removidos e, muitas vezes, esquecidos porque foram criados manualmente por meio do console. Mas a AWS se lembra deles, e você receberá o cheque até o final do mês.
Os clientes estão chegando
Por fim, e espero que óbvio para a maioria de vocês, quanto mais clientes você conquistar, maior será a escala, as chamadas de API e a quantidade de dados que você armazena, o que se traduz em contas de nuvem AWS mais altas. Seu negócio sobreviverá somente se você planejar esses custos adicionais e incluí-los em seu modelo de receita.
O ponto principal é que o serverless de nível de produção ou o não serverless têm custos constantes adicionais que podem escalar rapidamente; você pagará por muitos bits e bytes e precisa estar ciente disso desde o início. Você precisa definir seu orçamento para a escala esperada de tráfego de clientes e monitorá-lo para que não saia do controle.
Agora que entendemos o problema, vamos discutir como sua organização pode lidar com essa questão, reduzir custos e melhorar a eficiência adotando uma mentalidade FinOps.
Mentalidade FinOps
FinOps é uma estrutura operacional e prática cultural que maximiza o valor comercial da nuvem, permite a tomada de decisões oportunas baseadas em dados e cria responsabilidade financeira por meio da colaboração entre equipes de engenharia, finanças e negócios. - FinOps Foundation
Adotar FinOps e se tornar consciente dos custos é crucial para qualquer funcionário de nível C em uma organização. No entanto, conforme discutido acima, cada escolha de design, cada implantação de pilha do CloudFormation e cada execução de tarefa programada de TI/DevOps é uma escolha de compra.
Suas equipes gastam dinheiro todos os dias em suas contas da AWS.
Se você quiser mudar a mentalidade da sua organização para se tornar mais consciente dos custos, precisa começar de baixo. Arquitetos e líderes de equipe podem liderar o caminho, mas as tropas abaixo devem seguir e entender o objetivo. Claro, você pode adicionar automação que bloqueie os desenvolvedores de implantar todos os tipos de recursos, mas, a longo prazo, isso prejudicará a independência das equipes de desenvolvimento e não escalará. As pessoas precisam adotar a mentalidade FinOps, entendê-la e pensar sobre o custo da nuvem em todos os estágios do desenvolvimento.
Nas seções a seguir, descreverei itens de ação concretos que você pode implementar em sua organização. As personas podem diferir de arquiteto para DevOps, TI e desenvolvedor, mas a ideia é a mesma: é preciso uma aldeia para reduzir seu custo de AWS, e todos precisam jogar junto.
Design com Custo em Mente
Como arquitetos de nuvem, somos uma das poucas pessoas na organização que mais influenciam o custo total da AWS.
Na última AWS re:invent, Vogels discutiu as diretrizes do "The Frugal Architect" , que se correlacionam com minha postagem no blog, " Cloud Architect's High-Level Design Template ".
Minhas principais conclusões da sessão são que toda escolha de design de arquitetura de nuvem é uma escolha de compra.
Como arquitetos, influenciamos tanto os designs de alto nível dos nossos serviços quanto os designs de baixo nível. Na minha empresa, os designs de baixo nível e a prova de conceitos são feitos pelos desenvolvedores com minha escolta. Como tal, é essencial considerar o custo neste estágio inicial.
Ao projetar serviços sem servidor, geralmente há diversas arquiteturas possíveis; por exemplo, é possível usar o SNS ou o EventBridge para emitir eventos para assinantes.
Para tomar uma decisão informada, recomendo usar uma matriz de decisão para comparar ambas as soluções e adicionar o custo esperado à conta como um requisito não funcional.
Descrevo esse processo detalhadamente nesta postagem do blog - Modelo de design de alto nível do Cloud Architect.
Você deve planejar com antecedência — pense no número esperado de clientes e na escala esperada e coloque esses números na calculadora de preços da AWS . Não se surpreenda quando seu custo da AWS disparar um ano depois, e sua solução cara for implantada em produção. Nesse estágio, será muito mais difícil substituí-la.
No entanto, não para por aí. Você não pode supervisionar tudo como arquiteto, e os desenvolvedores fazem escolhas de preços ao implementar recursos. Por exemplo, eles adicionam métricas personalizadas do CloudWatch para painéis internos, mas usam muitas dimensões, o que aumenta drasticamente o custo (aconteceu!). Capacitar as equipes para fazer essas escolhas de forma independente e com custo abrangente é crucial. Eles devem entender que quase todos os recursos que você implanta ou API que você chama geram custos extras de nuvem.
Cultura FinOps
Vamos revisar as práticas culturais que capacitam as equipes em toda a organização a entender o custo da nuvem e reduzi-lo e otimizá-lo ativamente.
Campeão FinOps
A primeira prática é eleger um campeão FinOps em cada equipe (desenvolvedores, TI, DevOps, etc.) que seja responsável, assim como o arquiteto e o líder da equipe, por garantir que os PRs mundanos do GitHub não causem um aumento inesperado de custos. Eles levantarão preocupações de custo durante as revisões de design e ajudarão a equipe a manter o custo em mente.
O ideal é que os defensores do FinOps sempre considerem o custo da nuvem, seja no estágio de design, implementação ou implantação da produção.
Este campeão pode participar ativamente da seção "monitorar sua conta" que descreverei abaixo.
Guilda FinOps
A segunda prática é o compartilhamento de conhecimento entre unidades e organizações. Vamos supor que uma das equipes dos campeões do FinOps descobriu uma nova prática recomendada para reduzir o custo de simultaneidade provisionada no Lambda . É ótimo que uma equipe tenha resolvido esse problema, mas seria muito melhor se a mesma prática recomendada fosse implementada em toda a organização, causando um impacto maior na economia de custos. Para que isso aconteça, você precisa de um mecanismo para compartilhar conhecimento.
Um desses mecanismos pode ser iniciar uma guilda FinOps, onde todos os campeões do FinOps compartilharão seus conhecimentos uma vez por mês.
Conhecer pessoas de fora da sua organização interna e criar novos relacionamentos com pessoas de TI, DevOps, produtos e muito mais também são valores agregados.
Como observação, se você quiser saber mais sobre simultaneidade provisionada e inicializações a frio, confira minha postagem aqui .
Cursos Internos FinOps
As reuniões de guilda são uma ótima maneira de compartilhar informações. No entanto, como elas são limitadas a um público menor e as melhores práticas de reuniões anteriores podem ser esquecidas, é melhor documentar suas melhores práticas. Você pode começar com um documento interno simples ou ir um pouco além e criar um curso de vídeo interno. O curso não precisa ser um vídeo editado profissionalmente; pode até ser uma gravação de reunião de equipes/slack. O conteúdo deve servir como uma maneira rápida de integrar novos campeões de FinOps e disseminar práticas de redução de custos.
Hackathons FinOps
Essa é divertida. Gamifique o FinOps e introduza um hackathon onde os funcionários podem dar vida a ideias de melhorias, automação e outros métodos de redução de custos. Para apimentar as coisas, ofereça prêmios para as ideias mais impactantes.
Comemore o sucesso
Este item de ação pode ser o mais importante de todos, pois as cerimônias são parte integrante de toda cultura. Todos apreciam o feedback sobre um trabalho bem feito, especialmente quando esse trabalho melhora o lucro da empresa. Reconhecer o sucesso em toda a organização criará um efeito positivo e motivará outras equipes a adotar práticas de FinOps e ser as próximas a celebrar seus custos reduzidos.
Monitore sua conta
Ao gerenciar suas finanças na nuvem, seguir um plano de orçamento é crucial para garantir que você gaste seu dinheiro com sabedoria. Utilize ferramentas como o AWS Cost Explorer ou serviços de terceiros como o Anodot para obter insights sobre seus padrões de gastos, focando nos custos associados a cada equipe ou serviço.
Configurar alarmes para gastos excessivos no orçamento e monitorar regularmente suas despesas mensais permite que você entenda as implicações de custo de cada serviço da AWS e equipe da organização.
Você pode identificar o custo para a equipe adicionando tags a cada recurso — o nome da equipe, o nome do microsserviço ou qualquer outra tag que ajude você a entender o custo em casos em que várias equipes compartilham a mesma conta da AWS. Em seguida, você filtra no AWS cost explorer por.
Além disso, se você for um provedor de SaaS (software como serviço), é essencial estimar (ou "chutar" em muitos casos) o custo de cada cliente para orçamento, licenciamento e lucratividade. Esta não é uma tarefa simples, e seus desafios diferem drasticamente se você estiver usando uma estratégia de isolamento de inquilino de modelo de pool ou silo . No entanto, este assunto é muito grande para ser coberto no escopo deste post.
Para organizações que gerenciam várias contas ou usam vários fornecedores de nuvem, uma ferramenta como o Anodot pode oferecer vantagens significativas, pois fornece uma abordagem centralizada ao gerenciamento de custos.
Por fim, garanta que seus defensores do FinOps e outras partes interessadas possam acessar essas ferramentas, visualizar painéis e definir alertas.
Automatize as proteções de custos
Você pode reduzir os custos da nuvem automatizando exclusões de recursos e adicionando políticas ou mecanismos organizacionais que impeçam a criação de alguns recursos.
Algumas ideias que vêm à mente incluem:
Automatize a exclusão de recursos, como KMS CMKs não utilizados.
Automatize a exclusão de pilhas do CloudFormation que falharam na exclusão e foram deixadas com recursos "zumbis". Por exemplo, uma pilha falhou ao excluir um bucket S3 porque ele não estava vazio.
Empregue uma política que impeça os desenvolvedores de implantar em regiões não aprovadas. Os preços dos serviços da AWS diferem entre as regiões. Selecione as regiões que têm os serviços que você precisa a um custo que você está disposto a pagar e que fornecem uma latência boa o suficiente para seus clientes.
Não permita a criação de recursos via console em contas que não sejam de desenvolvimento; permita somente via abordagem de infraestrutura como código (IAC). Reduza as chances de criar recursos órfãos esquecidos.
Encontre recursos "desviados" ou recursos órfãos que não pertencem a nenhuma pilha e ninguém os utiliza, e exclua-os.
Defina alarmes para alertá-lo sobre potenciais picos de custos, permitindo o gerenciamento proativo. Ferramentas como a detecção de anomalias de custos da AWS podem ajudar a identificar padrões de gastos incomuns logo no início.
Escreva uma tarefa agendada que desligue instâncias do EC2 à noite ou automaticamente.
E muito mais, dependendo dos seus casos de uso.
Adotar uma abordagem proativa é a lição mais importante aqui. Não se surpreenda; faça um esforço para reduzir custos ativamente.
Aprendizagem Contínua
O aprendizado contínuo por meio de artigos, encontros da AWS e outros recursos educacionais é essencial. Você nunca sabe quando encontrará um novo mecanismo ou recurso que reduzirá custos. Manter-se atualizado com inovações e anúncios de serviços também é essencial.
É tudo uma questão de mudança e refatoração.
Às vezes, alterar serviços, como optar por HTTP em vez de REST API Gateway, aproveitar ferramentas como Lambda Powertuning para otimizar funções ou reduzir a retenção de log do CloudWatch e alterar o nível de log, pode levar a economias significativas.
Embora as dicas possam parecer exaustivas, elas são apenas a ponta do iceberg. Cada serviço da AWS oferece oportunidades de otimização exclusivas, ilustradas pelas estratégias detalhadas para o DynamoDB disponíveis em Desafios de preços e melhores práticas do DynamoDB da FinOut .
Faça sua lição de casa, pesquise, aprenda e otimize. Valerá a pena a longo prazo.
Resumo
Nesta publicação, abordamos práticas que toda organização deve adotar para promover uma mentalidade FinOps. Discutimos como são necessários os esforços de toda a organização para manter os custos da nuvem proativamente e sempre se esforçar para otimizá-los e reduzi-los.
Espero que este post ajude sua organização em sua jornada FinOps para atingir o nirvana de custo de nuvem. Boa sorte!