Como fazer alterações em uma infraestrutura sem quebrar nada? A gente responde essa pergunta em detalhes mais adiante. Mas, primeiro, vamos começar falando sobre o que queremos dizer com as breaking changes: é o processo de fazer alterações em milhares de recursos relacionados à infraestrutura, como aplicativos, bancos de dados, filas, entre outros, tentando minimizar o impacto indesejado.
Na Pomelo, nosso objetivo é sempre manter a qualidade de nossos serviços e mitigar qualquer inconveniente que possa surgir enquanto eles estiverem produtivos. Por esse motivo, as mudanças em nossa infraestrutura são feitas com um processo definido, sobre o qual vamos falar a seguir.
Vamos começar com um pouco de contexto!
Por que é importante coordenar todas as breaking changes na infraestrutura?
Como qualquer empresa, estamos constantemente desenvolvendo mudanças (fixes, features, hotfixes etc.) em diferentes ambientes e entre várias equipes simultaneamente, como desenvolvimento e infraestrutura. Isso pode levar a distorções que afetam os aplicativos de forma não intencional.
Essa situação significa que, de alguma forma, todos nós temos que estar cientes do que, quando, como e por que algo está acontecendo, seja nos aplicativos em que trabalhamos diariamente ou não.
Diante dessa situação, como podemos, na Pomelo, manter um de nossos princípios culturais, o da Velocidade (e qualidade) Pomelo, e coordenar essas tarefas da melhor maneira? Vamos descobrir!
Como é a infraestrutura da Pomelo?
A infraestrutura da Pomelo é dividida em três partes principais:
- Infra dinâmica;
- Infra estática;
- e Infra aplicativa.
Tanto para a Infra dinâmica quanto para a Infra estática, precisamos primeiro entender o conceito de IaC: infraestrutura como código. Quer saber o que é isso? Bem, a RedHat o define da seguinte forma: “A infraestrutura como código permite que a infraestrutura seja gerenciada e preparada por meio de código, em vez de por meio de processos manuais.“
Agora, falando mais sobre cada parte de nossa infraestrutura:
Infra dinâmica
Como mencionamos em artigos anteriores, a Pomelo criou o Rocket, nosso IDP (conteúdo em espanhol). A partir dessa ferramenta, podemos criar produtos que nosso aplicativo precisa, como queues e clusters de rds, entre outros exemplos. Eles são criados por meio de diferentes ferramentas, como CloudFormation, o que nos permite cumprir os padrões previamente definidos.
Infra estática
Na infraestrutura estática, onde atualmente gerenciamos a infraestrutura onde o Rocket está, fazemos isso de forma um pouco diferente. Para isso, usamos o Terraform, semelhante ao CloudFormation, que nos permite criar infra como código.
Infra aplicativa
Por sua vez, além dos recursos que um aplicativo pode ter, ele requer sua própria infraestrutura (por exemplo, um microsserviço). Para isso, ao trabalharmos com o Kubernetes, precisamos que, toda vez que um microsserviço for manipulado, ele tenha tudo o que precisa para ser instalado corretamente no cluster correspondente.
Como planejamos mudanças minimizando o impacto indesejado?
Vale destacar que, com uma equipe grande sempre agilizando, é muito importante não perder a qualidade e a rapidez características nossas nesse processo. Para isso, a primeira coisa que definimos foi uma Política de Mudanças, que entendemos como um contrato que determina o que, como, quando e por que uma mudança deve seguir o fluxo. Da mesma forma, essa política registra quem é o responsável pela aprovação de cada uma delas.
Essa organização nos permite realizar as breaking changes, garantindo que, quando implementadas em qualquer ambiente que a política ofereça, elas estejam em conformidade com os quatro pilares a seguir:
- seja aprovado pela(s) pessoa(s) responsável(is);
- seja devidamente comunicada aos envolvidos;
- esteja disponível em um cronograma de alterações;
- seja auditada.
Por fim, devemos mencionar que tudo isso não é importante apenas para manter a ordem e fazer alterações sem quebrar nada. Na Pomelo, isso também nos dá as ferramentas para podermos cumprir as auditorias correspondentes, pois temos a certificação PCI-DSS 4.0.
Portanto, cada alteração deve ser registrada adequadamente, com fácil acesso ao que, como, quando e por que foi feita, bem como quem a aprovou.
Para isso, criamos o seguinte diagrama (representativo):
Mãos à obra!
Tendo o contexto e o que queremos fazer, resta saber como.
Aqui tínhamos outro desafio grande e interessante: como poderíamos desenvolver uma ferramenta que acrescentasse etapas adicionais ao processo de implementação atual, minimizando o atrito que isso poderia gerar?
Assim, projetamos um aplicativo que tem dois tipos principais de entradas: por meio do frontend do Rocket e do pipeline que usamos no Github. Isso facilita e reduz o tempo na criação da Approval (entidade que tem todas as informações necessárias), para depois acompanhar todo o gerenciamento de aprovações por meio dela.
A arquitetura e seus componentes, entre outros detalhes, são compostos por:
- um AWS RDS PostgreSQL;
- um AWS S3 Bucket com a propriedade Object Lock;
- o uso do Slack para comunicação;
- e Google Calendar, com um calendário específico com cada uma das alterações visíveis, para que todos possam organizá-lo em sua visualização de calendário pessoal.
Conclusões
Ao fazer uma recapitulação, conseguimos ter uma boa compreensão de onde estávamos no início e quais eram nossas necessidades. Desenvolvemos uma Política de Mudanças como um contrato, conseguindo definir o escopo completo de cada uma delas. Também implementamos um aplicativo que nos permite cumprir essa política, reduzir o atrito, automatizar processos, economizar tempo e levar a outro patamar o desenvolvimento seguro em nossa infraestrutura. Dessa forma, conseguimos gerar a auditoria necessária para estar em conformidade com as certificações e as regulamentações de cada uma delas, tornando-a parte do fluxo de desenvolvimento da Pomelo. Assim, com esse processo, conseguimos fazer breaking changes por meio de uma ou mais revisões, com comunicação, programação e auditoria adequadas.