Você conhece os diferentes tipos de deployment?

Hello folks! Trago mais uma vez, experiência relatada em forma de artigo. No de hoje, vamos conversar sobre alguns tipos de deploy existentes, quais são os mais famosos e quando utilizá-los.

Introdução

Um deployment, é basicamente a implantação de um software em algum ambiente. Seja ele de produção, homologação… Esse deploy pode ocorrer por mudança de versão, que inclui novas melhorias, novas correções de bugs ou alguns ajustes.

Fazer a implantação de uma nova versão sem saber qual estratégia utilizar é a mesma coisa que andar de roupa de frio num deserto de 50º. Não faz muito sentido.

Por isso, vamos conversar sobre alguns deployments mais populares.

Conhecendo os Diferentes Tipos de Deploy

Blue-Green

Já temos a nossa versão, com o nosso container de pé. Correto? A ideia do Blue-Green é subir a nova versão do lado da versão anterior. Quando esse container com a nova versão estiver operando em 100%, será feito a troca. Todo o tráfego será direcionado para o container de nova versão e a versão antiga será desligada.

Quando a nova versão for ao ar, o usuário laranja da foto, será enviado para os containers verdes ao invés do azul. https://candost.blog/the-blue-green-deployment-strategy/

Vantagem
O bacana do Blue-Green é que você não tem downtime da sua aplicação, ou seja, quando a aplicação for atualizada, os usuários não vão nem notar, já que a nova versão só será apresentada quando tudo estiver 100% carregado e disponível para uso.

Desvantagem
Recursos. Você precisa de ter memória e CPU suficiente para subir duas versões da sua aplicação simultaneamente.

Rollout

É o mais simples e vem por default se você usa um orquestrador de containers como o Kubernetes. Na medida que ele mata containers que estão com a versão antiga, ele sobe novos containers com a versão nova.

As máquinas em azul representam a versão antiga, enquanto que as máquinas verdes representam a nova versão. Os “States” é conforme o tempo vai passando.

Vantagem
Redução de custo. Eu mostrei lá em cima o Blue-Green e citei, que um dos problemas dele era o custo, pois você tinha que ter uma grande alocação de recursos para poder subir duas instâncias da aplicação ao mesmo tempo, e depois fazer a troca. O Rollout não sobe todos de uma vez. Ele vai matando alguns container(s) da versão antiga e subindo o(s) da nova. Uma abordagem menos agressiva e menos custosa.

Desvantagem
Como podemos observar na imagem, conforme a nova versão for subindo, vamos ter duas versões em produção. Uma nova e uma antiga. E se essa mudança de versão for algo considerável, o usuário pode notar essa diferença nesse período de tempo e ficar totalmente confuso. Outros problemas que pode ocorrer é a perca de sessão do usuário ou até mesmo perca de dados.

Eu particularmente recomendo a abordagem de Rollout quando a atualização for de correções de bugs ou ajustes menores.

Canary

Um dos tipos de deploy mais interessante e mais difícil de ser configurado. O Canary Deployment permite que subamos uma nova versão em produção e ela esteja acessível a somente uma porcentagem do seu tráfego. Ou seja, podemos direcionar somente 10% dos usuários do site para visualizarem essa nova atualização enquanto tiramos métricas e vemos o comportamento para um grupo específico de pessoas.

Com uma grande quantidade de dados, conseguimos até sermos mais precisos em quem fará parte do grupo de teste da nova versão. Pessoas com imóveis, pessoas casadas, homens, mulheres…

A maioria dos usuários estão sendo encaminhados para a versão 1.0, enquanto que uma parte deles estão indo para a versão 1.1. https://www.gocd.org/2017/08/15/canary-releases/

Vantagem
Utilizando o Canary, nos conseguimos isolar uma nova versão para um grupo seleto de pessoas e evitar que possíveis problemas atinjam todos os usuários. A ideia é que a versão vá sendo gradualmente exposta aos usuários conforme os dias forem passando e tudo estiver indo bem.

Desvantagem
Complexo. O Canary não só necessita de recursos para subir duas versões em produção, como também precisa de uma grande base de usuários para conseguir trazer informações úteis sobre ela. A complexidade de implementação também é maior do que as demais.

Conclusão

Como eu sempre digo, não existe bala de prata. Há usos e usos. Se você está começando um sistema agora e tem poucos ou nenhum usuário, eu não recomendo que utilize nenhum deles. Você irá gastar recursos e um tempo desnecessário implementando uma estratégia de deployment que ninguém se beneficiará.

Se você quer implementar pequenos bug fixes e patchs de correção, eu recomendo o Rollout. Ele é o mais simples, vem configurado por padrão no Kubernetes, e você não terá muita dor de cabeça.

Agora, se você está em um projeto médio/grande, eu recomendo que sejam adotadas duas alternativas: Blue-Green e o Canary. São ótimas estratégias que trabalham diferente e podem ser combinadas. Você pode lançar uma nova versão para usuários específicos usando o Canary, e quando estiver os testes estiverem finalizados, o Blue-Green pode ser implantado para realizar a transição completa.

Gostaria de agradecer a sua leitura até aqui. Todo esse artigo foi baseado em minha opinião e minha experiência. Deixem suas dúvidas e comentários aqui em baixo, será um prazer respondê-los.

Até mais!