Por: João Henrique Loriato e Hiuri Carriço Liberato
01/04/2024.
Introdução
No dia 20 de março de 2024, a Mutant implementou uma Grande Mudança na Estrutura (GMUD) em suas contas da Amazon Web Services (AWS) com o objetivo de separar os ambientes de desenvolvimento, homologação e produção para suas soluções Enterprise(Grandes Clientes) e Massivo(Pequenos e médios clientes), visando otimizar custos, aumentar a segurança e melhorar a performance de seus produtos sem comprometer a eficiência do seu produto, o Mutant Whats.
Além dos benefícios financeiros, que trouxeram mais clareza sobre os números, a GMUD proporcionou melhorias significativas em termos de segurança e desempenho. Houve uma redução na quantidade de usuários com acesso às contas da AWS e a implementação de autenticação de dois fatores, fortalecendo a proteção dos dados e sistemas da Mutant. Adicionalmente, foram resolvidos problemas de overlap na rede, facilitando a comunicação entre os microserviços ao conectá-los em uma mesma rede interna, resultando em processos de comunicação mais rápidos e eficientes.
Uma das mudanças mais marcantes durante este período foi a transição do CloudFormation para o Terraform, marcando um movimento audacioso em direção à independência da provedora de nuvem. Essa medida estratégica não apenas posicionou a Mutant para enfrentar futuras mudanças de Nuvem com facilidade, caso necessário, mas também a equipou com ferramentas mais robustas e flexíveis para gerenciar sua infraestrutura de nuvem atual.
Por fim, a refatoração das pipelines de deployment demonstrou o compromisso da Mutant com a excelência operacional e a segurança. Ao separar o processo de deployment para cada conta da AWS, a empresa reduziu significativamente os pontos de vulnerabilidade, garantindo uma entrega de atualizações mais segura e confiável para seus clientes.
Neste artigo, exploraremos em detalhes a jornada da Mutant rumo à eficiência e segurança na nuvem, destacando os principais marcos e as lições aprendidas ao longo do caminho.
Importância da segregação de ambientes na AWS
A decisão de migrar o Massivo para contas exclusivas da AWS foi fundamentada na compreensão de que uma empresa não consegue resolver problemas que não conhece, conforme a motivação para a adoção do FinOps. Antes da migração, enfrentávamos desafios relacionados à falta de visibilidade e controle sobre os custos de infraestrutura, bem como questões de segurança e desempenho. Ao reconhecermos esses problemas e entendermos a importância de atacar esses pontos, optamos por adotar metodologias de FinOps, mapeando melhor os recursos e buscando extrair ao máximo das possibilidades de um sistema controlado e dedicado a um único produto.
Do ponto de vista gerencial, uma necessidade observada foi a de adequar e padronizar os domínios, já que antes tinhamos ezfront.com.br, jda.mutant.com.br, whats.mutant.com.br e mutantcxo.com agora todas as soluções estão em baixo de mutantwhats.com.br, fortalecendo a marca e trazendo mais organização para a empresa.
Um grande fator de melhoria que pesou foi a implantação do Terraform, que como a definição da empresa criadora diz, é como uma ferramenta para construir, alterar e criar versões de infraestrutura com segurança e eficiência. Uma ferramenta de IAC que pode ser aplicada em diversas Nuvens, trazendo mais independência para as soluções da Mutant.
O produto – Mutant Whats
O grande destaque do SaaS conversacional da Mutant é a possibilidade de interagir com os mais diversos meios de troca de mensagens por uma única central, seja através de um bot personalizado, seja por um atendente que se comunica de um único lugar, com qualquer app cadastrado.
A empresa cliente inicia o uso do produto a partir do JDA(jornada de aquisição), onde ela escolhe o plano, registra os dados de pagamento e faz a aquisição do serviço. A partir daí o JDA faz a integração junto ao ZOHO-CRM que é o sistema que lida com as contratações, e com o SENDGRID, que gerencia o envio de email aos clientes.
O JDA faz uma solicitação ao IBB, software responsável pelo gerenciamento dos bots, onde através dele é possível criar bots personalizados, específicos para cada cliente. O IBB obtém dados de catálogo através da MUTANT-STORE, que é alimentada pelo catálogo do META para utilizá-los em fluxo, catálogo esse que é alimentado por suas vez pelo ECOMMERCE API, que é o responsável pelo carrinho, controle de produtos, pedidos e como já mencionado o envio de produtos para o META.
O IBB cria os bots a partir do ROGUE, é ele quem interage com o ECOMMERCE para registrar os pedidos, e é ele quem recebe as solicitações de atendimento que vem da solução principal, o EZFRONT.
O EZFRONT, é a ferramenta de atendimento de clientes, que usa bots para realizar conversas, Ele possui perfil de administrador para gerenciar os bots e as conversas, a ele estão associados os atendentes que conversam com os clientes a partir da plataforma. É ele também quem faz solicitação ao ROGUE para atribuir um bot a uma conversa.
Quando uma pessoa envia mensagem para a empresa que usa a solução da Mutant, seja pelo Whatsapp, pelo Telegram, pelo Messenger, pelo Instagram, ela vai receber um primeiro atendimento pelo bot personalizado da empresa, e em seguida por um atendente que pode responder qualquer um desses canais pelo mesmo lugar, por essa facilidade, dentre outras vantagens, que a solução da Mutant é a escolha certa para melhor atender os clientes.
Processo de separação de contas e recursos
O processo se iniciou ainda em 2023, e durou até a segunda metade de março de 2024, sendo necessário um grande esforço das diversas áreas envolvidas para separar as soluções, testar e homologar cada etapa e analisar os impactos de cada separação.
A IAC do Cloudformation foi completamente substituída pelo Terraform, durante a GMUD todos os serviços subiram já na arquitetura nova, que deixou o sistema independente do provedor de nuvem AWS. Vale destacar que o terraform é hoje o que há de melhor em termos de automação de infraestrutura para software como serviço (SaaS).
Uma importante etapa foi a refatoração das pipelines, retirando dependências do ambiente antigo e adicionando segurança e confiabilidade ao trocar a estratégia de deploy para uma conta de desenvolvimento que espelhava a imagem de seu ecr com as contas de homologação e produção, para um novo método no qual as imagens são enviadas para os três ambientes de forma separada, garantindo maior confiabilidade e estabilidade na provisão dos micro-serviços.
Impacto da GMUD nos custos operacionais
Abaixo demonstramos a importante mudança na gestão financeira das operações ao separar o Enterprise do massivo. Na primeira imagem vemos o custo total dos dois produtos:
Na segunda imagem temos o custo exclusivo do Massivo:
Na imagem abaixo, vemos o custo no ambiente de desenvolvimento:
Na imagem abaixo, vemos o custo no ambiente de homologação:
Na imagem abaixo, vemos o custo no ambiente de produção:
Economia de aproximadamente R$10.000 ao mês
Antes da GMUD os custos dos produtos estavam unidos, o que dificultava tomada de decisões baseadas no custo, já que não se sabia com precisão o valor gasto com cada produto, agora com a separação os TL’s tem acesso aos valores exatos gastos por mês com cada solução, possibilitando decisões mais assertivas para o futuro da empresa e dos produtos.
Desafios encontrados durante a GMUD
Abaixo citamos alguns dos principais desafios para a realização da mudança na infraestrutura de Nuvem, que valem ser ressaltadas pois geraram melhorias após as devidas análises e correções.
Um dos principais pontos foi a verificação de que muitos recursos, como Lambda’s e SQS’s essenciais para o produto não haviam sido mapeados e nem documentados de forma detalhada previamente, e com isso foi necessário horas de troubleshooting para entender a especificidade de alguns fluxos e documentar para a sequência da GMUD.
Diversos endpoints estavam no código, o que levava a análises exaustivas para verificar erros que poderiam ser evitados com o uso de variáveis de ambiente, o que eleva o padrão de segurança e torna o código mais manutenível.
Foi necessário refatorar os pipelines para eliminar as dependências do ambiente antigo e fazer os devidos apontamentos para o novo ambiente, o que gastou muitas horas da equipe de DevOps do massivo.
Conclusão
A Grande Mudança na Estrutura (GMUD) implementada pela Mutant em suas contas da Amazon Web Services (AWS) representou um marco significativo na otimização dos ambientes de desenvolvimento, homologação e produção para suas soluções Enterprise e Massivo. A GMUD promoveu melhorias em segurança e desempenho. Foi reduzida a quantidade de usuários com acesso às contas da AWS e implementou-se a autenticação de dois fatores, reforçando a proteção dos dados e sistemas da empresa.
No lado financeiro houve uma grande economia com workloads cloud, já que agora se tem um controle individual das contas do Massivo, não sendo necessário por exemplo manter as instâncias de homologação ligadas quando não se tiver testando algo específico para o massivo, dessa forma, conseguimos uma queda brusca nos custos operacionais.
Também foram resolvidos problemas de overlap na rede, facilitando a comunicação entre os microserviços ao conectá-los em uma mesma rede interna, resultando em processos de comunicação mais rápidos e eficientes. A substituição do Cloudformation pelo Terraform como ferramenta de infraestrutura como código (IaC) foi uma medida estratégica adotada para tornar a arquitetura independente da provedora de nuvem, o que deixa o produto mais sólido, preparando a solução para futuras mudanças de plataforma, se necessário.
Por fim, outra relevante mudança durante a GMUD foi a refatoração das pipelines de deployment. Anteriormente, as imagens eram compartilhadas entre as contas da AWS, representando um potencial ponto de vulnerabilidade. Agora, as pipelines do Bitbucket realizam o deploy para cada uma das contas separadamente, aumentando a segurança e garantindo maior isolamento entre os ambientes. Essas mudanças não apenas atendem às necessidades atuais da Mutant, mas também a posicionam de forma mais sólida para enfrentar os desafios futuros, promovendo uma infraestrutura mais eficiente, segura e adaptável às demandas do mercado, seguindo a filosofia da empresa. Nunca se acomode!
Referências
SoftwareONE. (s.d.). Serviços de FinOps. Recuperado em 1 de abril de 2024, de https://www.softwareone.com/pt-br/servicos-finops
FinOps Foundation. (s. d.) Engineering. recuperado em 9 de abril de 2024, de https://www.finops.org/persona/engineering/
Gocache. (s.d). O que é Terraform e quais suas aplicações. Recuperado em 9 de abril de 2024, de https://www.gocache.com.br/dicas/o-que-e-terraform-e-quais-suas-aplicacoes/