Saulo Zimbaro
Jul 23 · 5 min read

Neste artigo irei expor 6 frentes de atuação que qualquer equipe de FinOps (ou até mesmo DevOps) deve conhecer para redução e otimização dos custos com infraestrutura e serviços em cloud. Algumas ações podem ser aplicadas em todas as grandes clouds como Azure, Google Cloud ou AWS enquanto outras técnicas são "proprietárias" da AWS. Em artigos futuros pretendo detalhar cada um dos 6 caminhos.

A ordem demonstrada aqui não necessariamente reflete importância, prioridade ou dependência. Isso depende muito da natureza das suas operações, perfil de uso dos seus recursos ou arquitetura.

Também não significa que só existam essas 6 ações quando se fala em redução e otimização de custos na AWS. Há diversas outras linhas de atuação, o que motivou a criação de inúmeras organizações como a FinOps Foundation.

A ideia deste artigo é ser algo introdutório para quem procura formas de otimização e redução de custos com infra na nuvem. Pretendo detalhar cada caminho em artigos separados.

Bem, vamos lá. Os caminhos são:

  1. Right Sizing.
  2. Arquitetura Elástica.
  3. Application Tuning.
  4. Reserva de Capacidade.
  5. Otimização de Instâncias.
  6. Migração de workloads para outras clouds.

1. Right Sizing

Right Sizing é um termo emprestado do mundo corporativo, que é utilizado para explicar uma técnica de estratégia organizacional e administrativa que visa a adaptação da empresa às tendências de mercado.

No mundo de TI, assim como no mundo corporativo, é exatamente a mesma coisa. Aqui objetivo do Right Sizing é garantir que você tenha/use o mínimo de recurso disponível para executar suas cargas de trabalho ou atividades.

Em outras palavras é garantir que você não tenha recurso ocioso e consequentemente pague por algo que você não usou.

No mundo AWS essa técnica pode ser aplicada em alguns serviços como EC2 , Dynamo, RDS ou SQS, por exemplo. Em alguns casos, a própria AWS auxilia lançando evoluções nos seus serviços, como o Dynamo On Demand. Estou preparando um artigo dedicado sobre Right Sizing na prática.

2. Arquitetura Elástica

Dado que seus recursos estão dimensionados corretamente e não há excessos (Right Sizing) você precisa garantir que suas cargas de trabalho irão acompanhar o perfil de uso da sua solução.

Por exemplo, imagine que você seja responsável por um sistema em que a Hora de Maior Movimento (HMM) esteja concentrada entre 13 horas e 18 horas. Neste intervalo sua carga aumenta 80% comparado com a média do restante do dia. Você precisa garantir que sua solução esteja dimensionada corretamente para a HMM e que isso não signifique ter carga ociosa no restante do dia.

Uma arquitetura elástica ajuda a resolver esse problema. Há diversas formas de construir uma arquitetura elástica e passa pela escolha de quais serviços ou tecnologias você irá usar. Novamente, esse tema pode ser bem mais detalhado e terá um artigo especial para ele.

3. Application Tuning

Algumas pessoas chamam de refactor e pode ser o mais custoso dos caminhos a se seguir nesta jornada de redução e otimização de custos. Digo isso, pois um tuning de aplicação pode impactar diversas áreas em uma empresa, desde a arquitetura até a operação e o retorno do investimento de tempo pode ser difícil de estimar.

Nada mais é que revisitar sua solução procurando possíveis otimizações e gargalos que gerem consumo desnecessário de recursos ou serviços integrados.

Algumas linhas de pensamento adotam a filosofia de "solução boa é solução pronta". Tema bem polêmico cabendo discussão à parte.

4. Reserva de Capacidade

Esta técnica pode não ser útil para você dependendo da cloud que você use.


Antes vou explicar as 3 formas de compra de servidores virtuais na AWS:

On Demand: Você paga pelo que usou , simples assim. A um preço de tabela.

Spot Instances: Você se beneficia da venda de capacidade ociosa na AWS. A um preço variável dependendo da oferta e procura.

Reserved Instance: Você antecipa a compra de servidores por determinado período e garante descontos por isso.

Essas 3 formas de compra podem ser aplicadas somente a alguns serviços como EC2 , RDS, ElasticSearch, entre outros.


Voltando ao caminho …

Reserva de capacidade, na AWS, significa antecipar a compra de infraestruturas, as chamadas Reserved Instances (RIs). Como dito acima.

Aqui o objetivo é garantir que você pague o melhor preço pela sua infraestrutura já bem dimensionada (Right Sizing) e não mutável (Arquitetura Não Elástica). É recomendado que você passe pelo Right Sizing para garantir que está antecipando a infraestrutura correta para a sua carga de trabalho. É verdade que a AWS flexibilizou bastante o mercado de RI como por exemplo a possibilidade de aplicar os descontos de compra de 1 instância m5.xlarge em 2 instâncias de m5.large ou então a não obrigatoriedade de escolher a zone de disponibilidade no momento da compra.

A AWS proporciona descontos de até 75% na antecipação de infra. Há diversos modelos, formas de pagamento e detalhes específicos que podem ser adotados. Mais detalhes em artigo futuro.

5. Otimização de Instâncias

Esta técnica, assim como a de reserva de capacidade, pode não ser aplicada a você dependendo da cloud que você use.

Na AWS há um serviço chamado EC2 Spot. Este serviço oferece descontos de até 90% no preço de EC2 (servidores virtuais).

Sua aplicação ou carga de trabalho precisa ser tolerante a falhas, pois este modelo foi construído em cima da carga ociosa de servidores da AWS e baseado em oferta/procura como um mercado financeiro de ações. Seu servidor pode ser desligado a qualquer momento dependendo de diversas condições que serão discutidas e detalhadas em outro artigo.

6. Migração de workloads para outras clouds

Por fim e não menos importante, você também possui oportunidade de reduzir custos em cloud migrando para outras clouds. :-) Como assim?

Parece complicado, mas não é. Dependendo da sua arquitetura e solução você pode migrar suas cargas de trabalho para outras clouds onde isso signifique redução de custo. De quebra, você ainda diversifica sua infraestrutura evitando o temido vendor lock-in.

Nesta técnica devem ser considerados alguns custos operacionais na conta, afinal, uma arquitetura híbrida, quando mal planejada, pode resultar em problema e não em solução.

Pretendo, em outros artigos, explicar um pouco da minha experiência e motivação na migração de cargas de trabalho para fora da AWS.


Espero ter passado um pouco da minha experiência neste tema e mostrado os caminhos possíveis a serem trilhados. Fique à vontade para sugerir e comentar.


A Mobicare combina os Melhores Talentos, Tecnologias de Ponta, Práticas Agilee DevOps com Capacidades Operacionais avançadas para ajudar Operadoras Telecom a gerar novas receitas e a melhorar a experiência dos seus próprios clientes.

Se você gosta de inovar, trabalhar com tecnologia de ponta e está sempre buscando conhecimento, somos um match perfeito!

Vem trabalhar com a gente 😉 bit.ly/mobicarreiras

mobicareofficial

Se você gosta de inovar, trabalhar com tecnologia de ponta e está sempre buscando conhecimento, somos um match perfeito! Vem trabalhar com a gente 😉 bit.ly/mobicarreiras

Saulo Zimbaro

Written by

mobicareofficial

Se você gosta de inovar, trabalhar com tecnologia de ponta e está sempre buscando conhecimento, somos um match perfeito! Vem trabalhar com a gente 😉 bit.ly/mobicarreiras

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade