Blue-Green Deployment

No mundo do desenvolvimento de software, uma das questões mais importantes a ser trabalhada é a de deploy das aplicações. Mais ainda, quando se deseja lançar uma nova versão, isso deve ser feito da maneira mais automatizada possível, utilizando técnicas que deixem o software disponível o maior tempo possível. Idealmente, o mesmo não deveria ficar offline durante tais atualizações.

A técnica Blue-Green Deployment objetiva justamente alcançar o objetivo mencionado acima, ou seja, fazer com que a transição da versão de um software para uma mais nova, seja feita de maneira transparente, evitando que o produto desenvolvido fique indisponível.

Como funciona o Blue-Green Deployment

Deve-se criar dois ambientes de produção, chamados Blue e Green. Assuma que o ambiente Blue esteja com o software em produção. Logo, o roteador direciona as requisições para esse ambiente. O ambiente Green, por outro lado, possui o produto com a nova release, em ambiente de staging que será promovido à produção. No ambiente Green, todos os testes devem ser feitos para garantir que a nova versão esteja pronta para produção. A figura abaixo ilustra o exemplo descrito.

Ambiente Blue em produção
No contexto da técnica Blue-Green deployment, o ambiente Blue está em produção

Quando a nova versão no ambiente Green estiver aprovada, reconfigura-se o roteador para direcionar as requisições para o ambiente Green. Portanto, o ambiente com a nova versão estará instantaneamente em produção (Green). O ambiente Blue, possui a versão antiga, que a pouco estava em produção. A figura abaixo ilustra o resultado de tal transição. A partir de agora, atualizações para uma futura versão serão feitas no ambiente Blue, já que o Green é o de produção. Quando o ambiente Blue, após atualizações e testes, estiver pronto para produção, redireciona-se novamente os pacotes para esse ambiente, fazendo-se com que o Green seja novamente o ambiente com a versão mais antiga do software. Essa alternância entre os ambientes Green e Blue estarem com ambientes de produção e staging é feita indefinidamente.

Ambiente Green em produção
No contexto da técnica Blue-Green deployment, o ambiente Green está em produção

Suponha agora, que o ambiente que acabou de se tornar de produção seja o Green (versão mais atual) e o antigo seja o Blue – como ilustrado na figura acima; caso haja problemas inesperados com a nova versão, basta redirecionar as requisições de volta para o ambiente Blue e utilizar a antiga versão. Perceba que grande vantagem isso traz: caso haja problemas inesperados numa nova versão, fazer rollback para versão anterior é fácil e é feito de maneira instantânea.

Trabalhando com Blue-Green Deployment na prática

Existem várias soluções para trabalhar com Blue-Green Deployment. Menciona-se aqui uma solução disponibilizada pela plataforma Azure: os chamados staging slots. Através dessa solução, o Azure disponibiliza dois ambientes de execução diferentes, sendo um de staging e outro de produção podendo eles serem alternados sempre quando necessário. E isso é exatamente o que temos na técnica Blue-Green Deployment.

Benefícios

Blue-Green Deployment possibilita que haja mudança de versões de uma aplicação, sem que a mesma fique offline, já que, durante a fase de transição da mudança de envio de requisições de um ambiente para o outro, ambas aplicações ficam online, sem prejuízos ao usuário final.

Além disso, caso haja a necessidade de se voltar para a versão anterior do produto, basta redirecionar o tráfego de requisições para o ambiente antigo, algo que é feito de forma fácil, rápido e novamente, sem deixar a aplicação offline.

Blue-Green deployment também pode ser utilizado para testes A/B, ou seja, testes onde duas ou mais versões de aplicações são utilizadas ao mesmo tempo. Nesse caso, basta que o roteador direcione as requisições para os dois ambientes, Blue e Green. Ele também deve garantir que, para um mesmo IP, o direcionamento das requisições seja feito sempre para o mesmo ambiente.

Dificuldades

Aqui são discutidas algumas dificuldades sobre a implamentação do Blue-Green Deployment.

Manutenção de dois ambientes

Perceba que, fazer com que o Blue-Green Deployment funcione adequadamente não é trivial. Deve-se ter dois ambientes idênticos (Blue e Green) para fazer a troca entre eles, algo que, em muitos casos não é simples devido a dificuldade de criá-los, ou porque não se tem o domínio de trabalhar em ambientes Cloud (como Azure e Amazon), ou porque simplesmente há restrições de criação e manipulação desses ambientes.

Banco de dados

Provavelmente o leitor deve estar se perguntando: e se uso banco de dados, como fica a consistência dos dados na troca entre Blue e Green? Realmente, o gerenciamento de banco de dados nesse processo não é trivial.. Isso porque, a cada troca de versão, ou seja, de ambiente de produção Blue/Green deve-se pensar como tratar o acesso e consistência dos dados.

Caso utilize-se banco de dados NoSQL, esse problema passa a ser menos complicado. Isso porque esses bancos são schemaless e portanto basta colocar a nova versão da aplicação no ar e as eventuais variações da modelagem de dados valerão apenas para as alterações recentes. Perceba, entretanto, que a versão atual deve ser compatível com o modelo de dados de sua predecessora. Caso nunca altere-se modelos de entidades antigas, a compatibilidade deve existir  com todas as versões anteriores. Logo, é interessante em pesar na eventual migração de dados para modelos mais recentes da aplicação.

Bancos de dados SQL, por outro lado, representam um problema maior em termos de migração e suporte ao modelo de dados. Pode-se seguir algumas estratégias:

  • Manter banco de dados separados para o ambiente Green e Blue. Logo, cada banco possui sua versão de acordo com a aplicação instalada. É claro que utilizando-se essa estratégia existe o problema da consistência dos dados durante a transição entre os bancos de dados dos ambiente Green e Blue. Uma solução para isso é criar uma funcionalidade de modo de leitura. Isso significa que, a aplicação é colocada nesse modo e em seguida a transição de Blue para Green ou vice-e-versa é feita. Como a aplicação está em modo de leitura não há a atualização de dados, portanto não há inconsistência. Após a transição, a aplicação volta a funcionar normalmente, ou seja, permitindo a escrita de dados na versão mais atual da aplicação com modelo de dados atualizado.
Blue-Green Deployment com dois bancos de dados
Blue-Green Deployment com dois bancos de dados
  • Manter apenas um banco de dados para ambos os ambientes, Blue e Green. Nesse caso as versões atual e nova da aplicação deverão suportar o mesmo modelo de dados, o que em si já pode ser um desafio. Recomenda-se, fazer a atualização do modelo de dados antes da mudança de Green para Blue, ou vice-e-versa, devido a complexidade e risco dessa modificação. Perceba que um plano sólido de alteração de modelos e migração de dados deve ser traçado para evitar problemas, algo que também não é trivial.
Blue-Green Deployment com um banco de dados
Blue-Green Deployment com um banco de dados

Conclusões

Mesmo sendo um processo pouco trivial, o Blue-Green Deployment possui um benefício chave: o tempo próximo de zero que a aplicação fica offline durante a troca de versões. Isso é algo inestimável para clientes que possuem aplicações que rodam 24/7 e portanto precisa ser seriamente considerado nesses casos.

A realidade de muitos aplicativos, contudo, não necessita de tal sofisticação na troca de versões. É aceitável que a aplicação fique offline durante algumas horas, logo, a técnica discutida aqui talvez não necessite ser implantada, devido a sua alta complexidade.

Em outras palavras, a utilização do Green-Blue Deployment depende do custo-benefício que isso traz para o cliente. Também depende, em certos casos, do time de desenvolvimento querer aprender uma técnica eficiente de troca de versões de um produto sem que o mesmo fique offline.

Referencias

[1] – BlueGreenDeployment by Martin Fowler – http://martinfowler.com/bliki/BlueGreenDeployment.html

[2] – Using Blue-Green Deployment to Reduce Downtime and Risk – https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html

[3] – The DOs and DON’Ts of Blue/Green Deployment – https://cloudnative.io/blog/2015/02/the-dos-and-donts-of-bluegreen-deployment/

[4] – Blue-green deployments – http://docs.octopusdeploy.com/display/OD/Blue-green+deployments

[5] – Simple Apache Based Blue Green Deployments – http://techblog.betgenius.com/simple-apache-based-blue-green-deployments/

[6] – Les Patterns des Géants du Web – Zero Downtime Deployment – http://blog.octo.com/zero-downtime-deployment/

[7] – Testes A/B – https://pt.wikipedia.org/wiki/Teste_A/B

[8] – Referência com figuras do deployment feito em ambiente Green e Blue – http://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/

[9] – Set up staging environments for web apps in Azure App Service – https://azure.microsoft.com/en-gb/documentation/articles/web-sites-staged-publishing/

[10] – Azure Web Apps (Websites) Deployment Slots – Explained- http://blog.amitapple.com/post/2014/11/azure-websites-slots/#.V4YhUvkrL_s

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s