O que é implementação azul-verde?

Um ambiente está ativo e atende aos usuários, rotulado como "azul", e outro, o ambiente "verde", é usado para a implementação e teste de uma nova versão. Quando a nova versão é aprovada, o tráfego é roteado instantaneamente do ambiente azul para o ambiente verde.

A estratégia foi popularizada e nomeada por Jez Humble e David Farley em seu livro seminal de 2010 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

O azul-verde é uma técnica de implementação contínua que permite a eliminação do downtime, com a capacidade de reverter instantaneamente para uma versão anterior. Ele oferece testes A/B fáceis e cria um ambiente seguro para desenvolvimento sem o risco de os usuários finais encontrarem uma versão que não esteja pronta.

Embora a expressão "azul-verde" seja a mais comum, existem variações. A Netflix usa "vermelho/preto", mas o conceito permanece o mesmo. Às vezes, os desenvolvedores podem querer ter mais de dois ambientes. O esquema de nomenclatura de cores é eficaz para diferenciar dois ambientes. No entanto, as organizações também podem usar convenções de nomenclatura, como números de versão, IDs de compilação ou títulos personalizados, especialmente se houver mais de dois ambientes envolvidos.

Embora o conceito seja simples, há várias etapas e variáveis dentro dessas etapas para criar uma implementação azul-verde estável e segura que aproveite os benefícios da estratégia.

A criação de ambientes idênticos para a implementação azul-verde pode ser feita manualmente ou com ferramentas automatizadas. Infraestrutura como código, ou IaC, é uma abordagem automatizada para o provisionamento. A IaC usa arquivos de configuração legíveis por máquina, como um conjunto de instruções ou uma receita, para permitir o provisionamento e a configuração automáticos da infraestrutura de TI de acordo com especificações predefinidas.

A IaC permite que os desenvolvedores criem automaticamente uma cópia do ambiente azul, que já está operacional, para uso como ambiente verde. Os desenvolvedores podem então editar esses modelos conforme necessário, sabendo que eles estão começando de um lugar confiável. O uso da IaC ajuda a garantir uma replicação repetível e precisa.

A conteinerização, na qual o código da aplicação, as dependências e as APIs são todos empacotados em uma "imagem de contêiner", é outra abordagem. O uso de contêineres garante que todo o ambiente seja idêntico. O Kubernetes, uma plataforma de orquestração de contêineres de código aberto, é comumente usado para conteinerização em implementação azul-verde.

Depois que os ambientes são criados, a aplicação é implementada no ambiente azul (ativo).

Um balanceador de carga é um mecanismo, frequentemente encontrado em ambientes de aplicação como uma ferramenta em provedores de nuvem ou ambientes Kubernetes, que direciona o tráfego de produção conforme desejado. Nesse cenário, o balanceador de carga direciona o tráfego para o ambiente azul ativo.

Em seguida, o novo código com as atualizações da aplicação é implementado no ambiente de produção verde. Como o balanceador de carga está roteando o tráfego para o ambiente de produção azul, o verde é um espaço seguro para experimentar, testar e configurar.

Quando o processo de implementação no ambiente verde estiver concluído, realize todas as etapas de validação necessárias. Essas etapas podem incluir verificações de segurança, análises de desempenho, busca de erros e muito mais.

Quando o ambiente verde for validado e aprovado por todos os stakeholders necessários, atualize o balanceador de carga para direcionar o tráfego da versão anterior azul para a nova versão verde.

Essa transição será instantânea; os usuários não verão em nenhum momento um erro ou algo diferente dos ambientes azul ou verde.

As atualizações de DNS podem ser usadas para direcionar os usuários para o ambiente desejado, mas pode haver atrasos significativos enquanto os caches atualizam o endereço IP. Devido a essas preocupações, os balanceadores de carga são preferidos porque as atualizações entram em vigor imediatamente.

Embora a etapa de validação devesse ter detectado a maioria dos possíveis bugs ou problemas de desempenho, ainda é importante monitorar o ambiente verde recém-ativo. O software e os serviços de análise de dados podem ajudar aqui. Comparar as atividades pode indicar se está acontecendo algo incomum.

Se algo der errado, o tráfego do usuário poderá ser redirecionado para o ambiente azul enquanto os desenvolvedores solucionam o problema.

A desativação de um ambiente azul em desuso é opcional; algumas organizações podem querer manter o ambiente azul indefinidamente, caso o ambiente verde precise ser revertido em algum momento. Mas há também possíveis motivos relacionados a custos para desativar o ambiente azul em algum momento do seu ciclo de vida. Como alternativa, o ambiente azul pode se tornar o próximo ambiente experimental, ou verde.

O pipeline de integração contínua/entrega contínua é "um fluxo de trabalho de DevOps automatizado que simplifica o processo de entrega de software." Esse pipeline facilita a entrega contínua de alterações de código nas aplicações.

É uma prática intimamente integrada à implementação azul-verde: a CI/CD permite a implementação azul-verde e as implementações azul-verde geralmente são incorporadas aos pipelines de CI/CD para ajudar a lançar as atualizações de software com downtime zero e risco reduzido.

Os pipelines de CI testam e integram automaticamente o novo código antes que ele seja integrado ao repositório central, reduzindo o risco de códigos com falhas chegarem à implementação. Os pipelines de CD aproveitam uma estratégia de implementação azul-verde para otimizar lançamentos rápidos sem afetar os usuários. A implementação azul-verde proporciona disponibilidade quase contínua e reversão segura, o que desempenha um papel importante na conquista do objetivo geral de CI/CD de lançamentos de código frequentes e confiáveis.

Derivada da expressão idiomática do "canário na mina de carvão", as implementações de canário são outra maneira de reduzir o risco ao implementar novas versões de software.

Enquanto as implementações azuis/verdes criam dois ambientes separados, cada um dos quais normalmente hospeda todo ou nenhum tráfego, o canário adota uma abordagem diferente. Os lançamentos canário têm apenas um ambiente, que hospeda várias versões.

Em uma implementação canário, as novas versões são lançadas primeiro para um pequeno percentual de usuários. Assim, os desenvolvedores podem ver se os erros aumentam, o desempenho diminui ou outros problemas surgem. Essa pequena porcentagem de usuários atua como o "canário na mina de carvão". Se não houver problemas, o tráfego para a nova versão é aumentado gradualmente, verificando os erros o tempo todo.

A principal vantagem de uma implementação canário em relação ao azul/verde está no custo da infraestrutura, já que a implementação canário usa apenas um ambiente, enquanto as implementações azul/verde, usam dois. Mas as implementações canário também podem ser mais complexas e de maior risco se uma reversão for necessária, em comparação com o simples redirecionamento do balanceamento de carga do azul/verde.

O método de implementação canário pode ser útil se os possíveis erros não forem uma preocupação tão significativa quanto disponibilizar uma nova versão aos usuários o mais rápido possível, ou se os desenvolvedores quiserem monitorar o impacto com feedback real da experiência do usuário.

Dito isso, há também uma abordagem híbrida. Os balanceadores de carga podem direcionar parte do tráfego do usuário, digamos, 1%, para o ambiente verde, enquanto deixam 99% para o azul. Isso combina efetivamente as duas estratégias, fornecendo insights sobre a implementação canário com a capacidade de reverter as alterações de forma rápida e fácil.

A implementação azul-verde oferece muitas vantagens, seja em uma abordagem do tipo tudo ou nada ou em uma implementação gradual do tipo canário.

Como o balanceador de carga alterna o tráfego instantaneamente para o ambiente desejado, os usuários finais nunca sofrem downtime. Essa é uma grande vantagem para instâncias de alto tráfego, nas quais o downtime pode gerar problemas significativos para os negócios.

A existência de dois ambientes separados, sendo um deles conhecido por ser seguro e operacional, permite que os desenvolvedores desfaçam instantaneamente quaisquer alterações em caso de problemas. Se o ambiente verde apresentar problemas, o tráfego pode simplesmente ser redirecionado para o ambiente azul.

Ter dois ambientes separados simplifica a análise de métricas, a análise de dados e testes A/B para as diferentes versões.Os dados de análise e monitoramento podem ser claramente conectados ao ambiente azul ou verde, permitindo uma comparação direta e verificações de integridade. Isso contrasta com a implementação canário, que pode ser mais difícil de distinguir, já que ambas as versões estão ativas simultaneamente.

Um ambiente experimental verde permite o teste completo de novas versões fora da vista do usuário final. Novas versões são implementadas com um grau significativo de confiança de que funcionarão conforme o esperado. Nos casos em que isso não ocorre, o tráfego pode ser redirecionado instantaneamente de volta para o ambiente azul estável.

Embora a implementação azul-verde ofereça muitos benefícios, existem potenciais desvantagens e casos de uso não ideais que as equipes de desenvolvimento devem considerar.

Com dois ambientes totalmente provisionados em execução, os custos de hospedagem e infraestrutura podem aumentar. Não significa necessariamente que esses custos serão exatamente o dobro do custo de um único ambiente. Em alguns casos, o ambiente verde terá uma pegada de carbono menor ou o ambiente azul pode ser desativado rapidamente, ou alguns recursos podem ser compartilhados entre os dois ambientes. Mas é provável que haja algum aumento de custo.

Embora não seja exclusivo das implementações azul-verde, manter a sincronização do banco de dados entre ambientes antigos e novos pode representar um desafio. Por exemplo, em um sistema azul-verde que envolve mudanças frequentes ou complexas no esquema, pode ser complicado manter a compatibilidade.

Para evitar a quebra do ambiente de produção, as alterações no esquema devem ser compatíveis com versões anteriores, o que significa que o novo sistema deve funcionar com o anterior. Caso contrário, os ambientes podem exigir bancos de dados separados que devem ser sincronizados em tempo real. Essa sincronização bidirecional apresenta seus próprios riscos, como inconsistências e degradação do desempenho.

Para lidar com esse problema, ferramentas de CI/CD, como o GitHub Actions, incluem processos de implementação de banco de dados que gerenciam automaticamente as atualizações de esquemas. Às vezes, alterações de esquema muito complexas podem anular o valor da implementação azul-verde.

Nas aplicações com estado, aquelas que mantêm dados persistentes entre as solicitações, as implementações azul-verde podem apresentar problemas. As aplicações com estado podem incluir carrinhos de compras, que mantêm seu conteúdo entre várias visitas, ou registros de mensagens. Se os bancos de dados não forem compartilhados e compatíveis entre os ambientes, esses dados podem ser perdidos.

As aplicações de microsserviço geralmente são sistemas altamente complexos compostos de muitos componentes diferentes e que podem ser implementados individualmente. Como os desenvolvedores de microsserviços podem querer implementar alterações dezenas de vezes por dia, a natureza incremental de uma implementação canário é considerada uma escolha mais segura.