Estratégias para Otimizar Custos com Nuvem: O “Projeto Manhattan”

TL;DR 

O “Projeto Manhattan”, nome dado a migração da infraestrutura Pipefy da AWS para a Oracle OCI, levou cerca de 12 meses desde a análise inicial até sua finalização. O objetivo foi a redução de nossos custos operacionais em pelo menos 2x o equivalente ao desconto oferecido por contratos de fidelização com as clouds.”

Escrito por Milton Costa, Site reliability engineering Manager (SRE) na Pipefy.

Introdução 

Na Engenharia da Pipefy, a busca por eficiência operacional é uma constante desde 2018-2019, quando o crescimento da empresa exigiu uma gestão ainda mais estratégica dos recursos. A pandemia acelerou essa necessidade, intensificando o foco em projetos que otimizassem custos e melhorassem o desempenho.

Diante desse cenário, iniciamos uma série de iniciativas, culminando no ambicioso ‘Projeto Manhattan’. Durante seis meses, nossa equipe mergulhou em análises aprofundadas e estudos de viabilidade, visando identificar as melhores oportunidades de otimização. O resultado foi um conjunto de ações estratégicas que transformaram significativamente a nossa infraestrutura e processos internos.

Contexto inicial 

A Pipefy sempre confiou na maturidade da AWS como nosso principal recurso de cloud, aliada a uma arquitetura cloud-native desenhada para operar em cima de Kubernetes. Desde o início, focamos em várias frentes para melhorar nossa eficiência, mas os custos sempre foram crescentes, seja pelo avanço do negócio, pela implementação de novas tecnologias ou por problemas diversos de arquitetura da aplicação e infraestrutura.

Em busca de melhorias e redução de custos 

Nós já tínhamos reduzido muitos dos nossos custos recorrentes em cloud:

• Internalizando serviços
• Contratando instâncias reservadas na AWS
• Utilizando máquinas spot
• Rightsizing de deployments
• Otimizando aplicações
• Removendo recursos legados
• Simplificando a plataforma
• Renegociando contratos com fornecedores diversos

Com todo esse trabalho, conseguimos reduzir aproximadamente 20% de nosso custo de infraestrutura, mas ainda não estávamos satisfeitos. Sabemos que sempre dá para ser ainda mais criativo na busca de mais por menos, e esse trabalho nunca parou: se tornou um padrão a ser considerado em qualquer projeto dentro da engenharia.

No tempo certo 

Procurando por oportunidades de economia, uma das opções seria mudar de provedor de nuvem. Um que nos fornecesse toda a robustez que a AWS tem. Será que outras nuvens conseguem? Será que existe vida fora da AWS que se encaixe em nossa realidade de operação global? Os contratos seriam interessantes e com bons descontos? Minha resposta para isso é: SIM. Vejo que os principais players que temos hoje entregam tanta qualidade quanto a AWS no core do negócio deles, que é infraestrutura com desempenho, fácil administração, monitoramento e resiliência. Mas será que o custo-benefício se equipara? É melhor ou pior?

Nosso contrato estava para entrar em fase de renovação e esse foi o momento perfeito para encaixar esse estudo. Iniciamos as discussões 6 meses antes, mas também envolvendo nosso atual fornecedor a fim de encontrar o melhor caminho. Isso foi algo muito benéfico, pois tivemos tempo para avaliar com calma e discutir mais oportunidades de saving. Também tivemos tempo de olhar em paralelo outras opções do mercado.

Ouvimos propostas de redução de 5% a 40%, todas interessantes em algum detalhe. Procuramos parceiros de billing também, que através de seus contratos maiores com os provedores de nuvem poderiam repassar alguma vantagem para nossa operação em forma de descontos e serviços agregados. Fizemos relatórios gigantescos de todas as opções para não ter dúvidas de que a decisão que iríamos tomar seria a melhor.

Direto ao ponto 

Após muitas rodadas de testes, aprovação de diversas áreas como segurança, compliance, técnico e outros, 4 dos 5 fornecedores já tínhamos algo em produção, sabíamos utilizar, tínhamos a base que precisávamos, e isso foi um grande atalho para a tomada de decisão. 

Optamos por focar na Oracle OCI pois um conjunto de fatores nos mostrou que eles têm condições de suportar toda nossa arquitetura, além de trazer reduções agressivas nos custos base de cloud que temos (VM, disco, tráfego e serviços agregados). Lendo aqui, parece ter sido fácil mas tivemos que trabalhar com a mitigação de muitos SPOF’s (pontos únicos de falha) que eventualmente criaríamos, riscos generalizados de performance e compatibilidade no uso em larga escala.

Iniciamos a execução com um projeto piloto antes de assinar o contrato com a OCI e começar a mudar as coisas. Negociamos com eles um conjunto de PoCs para validação de diversos componentes, ampliando os ensaios feitos até então e contando com o time técnico da OCI. Mesmo sabendo que tudo tecnicamente funcionaria, precisávamos aprovar o uso massivo de algumas camadas da arquitetura.

Projeto Piloto 

Nesta etapa, focamos em observar, testar carga, estressar, e ir ao limite como:

• Erros na aplicação.
• Compabilidade com os serviços da cloud, opções de tipo de disco, vm, iops, família de processadores, configurações de rede.
• Escalabilidade de componentes para uso em larga escala, aumento repentino e limites gerais do provedor como quantidade de vm.
• Limites de requisições por segundo, throughput, TTFB, APDEX.
• Simulação de jornada do cliente no uso da plataforma.

Através de muitos relatórios e apresentações entre times, essa foi uma etapa essencial para nos dar segurança de que as coisas tomariam o rumo correto após a assinatura de um contrato de alto valor com um novo fornecedor. Também construímos uma matriz de risco definindo responsabilidades para pessoas e times diferentes, com ações de análise/mitigação dos riscos.

 Ao final, esse resultado foi compartilhado com todos os stakeholders e líderes para dar visibilidade e ter o aval para seguir. Alguns riscos se tornaram desafios que apareceram ao longo da execução do projeto e tivemos que ser rápidos para contorná-los e não afetar o planejamento.

Execução 

Todas as etapas já citadas acima decorreram ao longo de 2022-2023, e em janeiro de 2024 entramos na fase de execução, que durou 6 meses, no que diz respeito ao core do produto, como aplicações, banco de dados e outras dezenas de componentes vitais. Conseguimos gerenciar as diversas frentes de migração com datas de entrega, escopos e seguindo uma lógica no processo das camadas de infraestrutura a serem movidas. Como tivemos um planejamento antecipado, a execução se tornou algo objetivo e conseguimos seguir sem grandes problemas. Claro, com contratempos, mas nenhum estourou o limite do previamente planejado, o que é algo impressionante.

Resultados

Com esse projeto, conseguimos desenvolver nosso time em aspectos que foram além do escopo principal, como a expertise em gerenciamento de ferramentas internalizadas no Kubernetes, tais como:

• Bancos de dados relacionais e não relacionais.
• Melhorias na segurança da informação nas camadas de tráfego de dados e criptografia em repouso e nos processos e indicadores para os times de segurança.
• Mudanças na arquitetura, como o uso de multiplos clusters Kubernetes para organizar e otimizar o desempenho segregando cargas de trabalho.
• Integração entre as principais clouds que utilizamos, permitindo o uso de diferentes serviços de forma segura e criando um ecossistema de cloud híbrido.

No fim, conseguimos reduzir em cerca de 30% nossos gastos com infraestrutura em nuvem ao migrar da AWS para a OCI. Aliado a esses resultados, também atingimos melhores níveis de desempenho mesmo com o constante crescimento da base de clientes em nossa plataforma.