Blue-Green Deployment
Uma forma segura de atualizar suas aplicações
Com a transformação digital que todas as empresas estão sofrendo, a cada dia que passa se torna mais importante conseguir disponibilizar de forma ágil novas funcionalidades às aplicações existentes.
Com isso, novas técnicas surgiram para atender a essa demanda. Em ambientes computacionais complexos, onde não é possível criar e manter um ambiente de homologação que seja idêntico ao ambiente produtivo — frequentemente por conta de massa de dados — não é possível realizar uma homologação que dê plena confiança na nova versão. Nesse cenário não é raro serem encontrados bugs somente em ambiente produtivo.
Blue-Green Deployment é uma técnica de implantação de sistemas que consiste em criar um ambiente “espelho” do ambiente produtivo. A esse ambiente damos o nome Green. Ao ambiente produtivo corrente, damos o nome Blue.
Todos os usuários daquela aplicação têm acesso ao ambiente Blue. No ambiente Green, realizamos a atualização para a nova versão da aplicação. Esse ambiente atualizado é acessível apenas pelos responsáveis pela homologação e testes regressivos dessa atualização.
Após o término da fase de testes e homologação (e possíveis correções que sejam demandadas), é feito a publicação da versão Green para todos os usuários da aplicação.
Essa publicação consiste simplesmente em um redirecionamento do load balancer, onde ele passa a apontar o tráfego para o ambiente Green, ao invés do Blue, conforme imagem abaixo:
Dessa forma, a publicação ocorre com zero indisponibilidade — nenhum usuário recebe erro de sistema indisponível, em nenhum momento.
O ambiente Blue, no que lhe concerne, será utilizado para a próxima implantação. A versão corrente estará no ambiente Green, e todo o procedimento de atualização, testes e homologação será realizado no ambiente Blue. Após o término dessa fase homologatória, o load balancer aponta para o Blue e o ciclo se reinicia:
Banco de Dados
O gerenciamento dos bancos de dados entre os ambientes Blue e Green é uma das questões mais complicadas quando trabalhamos com esse tipo de deployment.
Para mitigar esse problema, é recomendado utilizar a mesma instância de banco de dados em ambos os ambientes, como na figura abaixo:
Se não for possível utilizar a mesma instância de banco de dados para ambos os ambientes, deve ser garantido que haja uma sincronização dos dados na mudança de um ambiente para outro.
Existe também o problema de novas implementações que alteram a estrutura dos dados. Tenha em mente que o banco de dados tem que ser alterado de forma que funcione em ambos os ambientes.
Uma estratégia utilizada é separar as alterações de banco das alterações que estão subindo na nova versão da aplicação. O procedimento segue a seguinte ordem (considerando que o Blue é o ambiente corrente):
- estrutura do banco de dados é atualizada
- Blue deve seguir funcionando normalmente
- Green é atualizado com a nova versão da aplicação
- testes e homologação são efetuados no Green
- load balancer faz o chaveamento do Blue para o Green
Note que já na primeira atividade o banco de dados é atualizado, tendo o potencial de impactar a versão corrente. Por isso a necessidade de as alterações de banco de dados funcionarem para ambos os ambientes.
Granularidade
A mais simples forma de utilizar um Blue-Green Deployment é espelhar o ambiente produtivo por completo: todas as aplicações e microsserviços. Porém, dependendo o tamanho desse ecossistema, torna-se inviável financeiramente.
Para minimizar os custos, uma estratégia mais dinâmica pode ser utilizada: manter as aplicações estáveis (geralmente os sistemas legados, que não são mais atualizados) fora dos ambientes Blue e Green. Ambos os ambientes utilizam essas mesmas aplicações, conforme figura abaixo:
Rollback
Quando é identificado que existe algum problema crítico com a nova versão após ela ser liberada ao usuário final, geralmente decidimos realizar um rollback (independente da estratégia de deployment ser Blue-Green ou não).
Se estivermos utilizando a estratégia Blue-Green, o rollback é extremamente fácil. Basta redirecionar o load balancer para o outro ambiente.
Disaster Recovery
Disaster Recovery é um plano estruturado para recuperar a aplicação caso aconteça algum problema muito crítico que comprometa todo (ou boa parte) o ambiente produtivo.
Se sua estratégia de Blue-Green consistir em deixar cada um em uma infraestrutura diferente (regiões diferentes, geograficamente falando), você pode utilizar o Blue-Green como um perfeito Disaster Recovery.
Além disso, cada nova implantação acaba sendo um teste do Disaster Recovery. Quando não utilizamos o Blue-Green, criamos o plano de Disaster Recovery e raramente (ou mesmo nunca) temos a oportunidade de validar que o mesmo cobre tudo o que precisa. Quando se faz necessário seu uso, acabamos nos deparando com uma série de detalhes que não foram previamente pensados.
Conclusão
O Blue-Green Deployment é uma estratégia de implantação que traz uma enorme segurança ao negócio e área técnica. Se a homologação for bem feita, dificilmente novos defeitos são introduzidos.
A maior barreira encontrada é a financeira. Replicar e manter um ambiente de produção não é barato, e um estudo bem minucioso deve ser feito para avaliar se vale a pena ou não.
Em cenários onde bugs em produção causam grande estrago — tanto financeiro, quanto para a marca — e mesmo assim constantemente não se consegue garantir em tempo de homologação que a nova versão não está levando mais bugs, essa estratégia encaixa muito bem.
Sugestão de Leitura
Continuous Delivery por Jez Humble and David Farley
Origem: Aelson Alves