Autor: Wilker Guedes

Quando falamos em aplicações sendo executadas em um ambiente de produção, uma das primeiras coisas que nos vem em mente é a alta disponibilidade. Em um cenário extremamente competitivo e concorrente ficar indisponível não é uma opção.

O software é “vivo” e é constantemente modificado para atender os mais diversos cenários, seja a liberação de novas funcionalidades, correção de bugs e otimizações. A cada nova alteração temos uma nova versão da aplicação que precisa ser disponibilizada em produção(release), por outro lado, precisamos manter a confiabilidade do ambiente produtivo, garantindo que a aplicação continue funcional e disponível.

Temos aqui o cenário ideal para a cultura DevOps, time de Dev entregando novas releases e querendo vê-las em produção o mais rápido possível e o time de Ops querendo manter o ambiente estável, seguro e disponível.

Felizmente existem estratégias que nos ajudam a mitigar os riscos de uma implantação(deployment) visando o mínimo de indisponibilidade possível (near zero-downtime). Veremos a seguir como a estratégia de implantação Blue/Green nos ajuda a alcançar este objetivo.

Além da Blue/Green existem outras estratégias de deploy e que podem ser mescladas com a Blue/Green. São elas:

Canary: Nesta abordagem, apenas uma parte do tráfego é direcionado para a nova versão, permitindo ter mais controle e testar de forma mais direcionada. O nome da técnica “Canário” vem de uma prática bem peculiar e vale a pena pesquisar sobre a sua origem.

Rolling: Já nesta técnica, a nova aplicação vai sendo liberada aos poucos(rolando) até que toda a aplicação tenha sido substituída por completo e esteja apta a receber todo o tráfego e então a aplicação antiga é removida.

O problema

Realizar a implantação de uma aplicação em produção não é uma atividade trivial e por mais testes que sejam realizados antes de uma aplicação ir para produção, sempre fica a expectativa de como será o comportamento com o tráfego em escala real.

Em ambientes mais tradicionais é comum ter uma janela de manutenção, no qual, alterações no ambiente de produção podem ocorrer de forma planejada, e de certa forma, resguardadas em caso de problemas que causem indisponibilidade.

Neste cenário, um deploy mal sucedido geralmente é corrigido com o deploy da última versão estável da aplicação(Rollback). Embora funcione, esta não é a melhor estratégia pois além de ser demorado, aumenta o tempo de downtime e dificulta a análise da falha, visto que não há tempo suficiente para analisar a causa da falha(debug) pois é preciso restaurar a disponibilidade da aplicação.

O Que é o Blue/Green?

Blue/Green é uma técnica de implantação de aplicações com o mínimo de downtime possível e a possibilidade de realizar o rollback de forma rápida e sem muito esforço.

A ideia central é que tenhamos uma cópia idêntica da nossa infraestrutura de produção, uma com a versão atual e estável da aplicação(Blue) e outra com a nova versão que desejamos implementar(Green).

Agora, basta direcionar o tráfego para o ambiente Green e caso ocorra algum problema, basta redirecionar o tráfego de volta para a aplicação estável.

Assim como todas as demais atividades que fazemos no nosso dia a dia, a estratégia de deployment deve ser discutida e amplamente planejada para que os mais diversos fatores possam ser levados em conta, como:

• Arquitetura da aplicação
• Esquema do banco de dados
• Riscos operacionais e de negócios
• Custos
• Conhecimento técnico

Devido a necessidade de ter um clone da infraestrutura da sua aplicação, esse não é um cenário ideal para ambientes tradicionais como datacenters ou modelos on-premises, justamente pela dificuldade e custos de provisionar esses recursos em duplicidade. Esse tipo de cenário é muito mais comum em empresas que já se beneficiam do uso da computação em nuvem(Cloud Computing).

Exemplo de uma implantação Blue/Green:

Blue/Green na AWS

Elastic Beanstalk: O AWS Elastic Beanstalk é um serviço de fácil utilização para implantação e escalabilidade de aplicações e serviços da web desenvolvidos com Java, .NET, PHP, Node.js, Python, Ruby, Go e Docker em servidores familiares como Apache, Nginx, Passenger e IIS.

fonte: https://aws.amazon.com/pt/elasticbeanstalk/

Um Environment(Ambiente) do beanstalk pode ser facilmente copiado, o que nos permite ter uma réplica idêntica do nosso ambiente e fazermos a parte Green da nossa estratégia de deploy. Com o recurso Swap URL direcionamos facilmente o tráfego da nossa aplicação principal para o nosso ambiente Green e o beanstalk se encarrega de trocar as urls dos ambientes.

Route 53:O Amazon Route 53 é um web service Domain Name System (DNS) na nuvem altamente disponível e escalável.

fonte: https://aws.amazon.com/pt/route53/

O Route 53 nos permite ter uma abordagem mais direta, ou seja, mudar o apontamento DNS da aplicação atual(Blue) para o novo(Green).

É possível também utilizá-lo para direcionar uma porcentagem do tráfego para a nova aplicação utilizando a funcionalidade de

ASG — Auto Scaling Groups: O AWS Auto Scaling monitora os aplicativos e ajusta automaticamente a capacidade para manter um desempenho constante e previsível pelo menor custo possível. Com o AWS Auto Scaling, é fácil configurar a escalabilidade de aplicativos para vários recursos em diversos serviços em questão de minutos.

fonte: https://aws.amazon.com/pt/autoscaling/

É possível adicionar mais de um ASG ao Loadbalancer, desta forma podemos criar um novo ASG(Green) com um lauchconfiguration que aponte para uma AMI com a nova versão da nossa aplicação. Agora, basta aumentar a quantidade de instâncias do novo ASG aguardar que as instâncias fiquem saudáveis, ou seja passem no health check, em seguida basta alterar o ASG para que utilize o Load balance que queremos realizar o deploy. Quando concluído o deploy basta reduzir a quantidade de instâncias do ASG Blue e por último removê-lo do Load Balance.

Espero que este artigo tenha lhe ajudado a entender um pouco mais sobre a estratégia de deploy Blue/Green e como é possível realizá-la na AWS utilizando alguns dos vários serviços disponíveis.

Abraço e até o próximo.

Fonte: https://d1.awsstatic.com/whitepapers/AWS_Blue_Green_Deployments.pdf