fbpx

Canary release + Blue Green

Fala galera, hoje o assunto é canary release e blue green, então vamos lá começar com o Blue Green Deployment.

Essa técnica consiste basicamente em montar dois ambientes um com o código antigo, e um com o novo código, possuindo uma chave de decisão de qual ambiente será utilizado.

Acabou o artigo então ?

Claro que não, vamos aprofundar um pouco mais.

Imagine que você faz parte do time de TI de um sistema que propicia ao usuário, um serviço de locomoção, onde basicamente você faz a solicitação de um  veículo nas imediações para te levar de um local a outro, tipo um App famoso que existe por aí que começa com U. Pois bem, imagine que você recebe uma requisição para alterar o microsserviço que define os veículos próximos, acrescentando um critério para tomada de decisão, agora é possível decidir se você quer buscar veículos que aceitem animais. (Vamos abstrair aqui caso a funcionalidade já exista, ou não faça parte do contexto do microsserviço)

Pois bem, você foi lá e alterou todo o código, agora você possui uma versão nova, com tudo testado e pronto para subir ao ambiente de produção.

Nesse momento você pode simplesmente fazer o deploy e rezar para tudo dar certo, e você não impactar todos os usuários, ou você pode pensar em algumas estratégias de implantação, que podem lhe dar um pouco mais de tranquilidade.

Pensando em Blue Green, você teria um ambiente de produção com o seu código funcionando e sem a nova alteração, vamos chamar este ambiente de (A). E no outro você teria o novo código com as alterações feitas (B).

No momento da implantação você poderia virar de (A) para (B), e caso algo não ocorresse como previsto, você voltaria para (A).

Segue um desenho para exemplificar:

Blue Green Deployment Microsserviços Dicas de TI arquitetura de software Estrategias de deploy Ambiente Blue Green Estrategias de implantação inovação tecnologia

Bom né? Já diminui bastante a complicação caso aconteça algum problema.

Agora aqui vai uma outra técnica chamada Canary release.

O Canary release recebeu esse nome por se inspirar em uma técnica antigamente utilizada pelos mineradores. Ao entrar em uma mina estes levavam consigo gaiolas com pobres canários, por serem mais sensíveis a variações, caso alguma toxina se encontrasse no local, os animaizinhos vinham a falecer, dando um aviso que o local não era seguro, e assim poupando a vida dos mineradores.

Bom, espero que a humanidade tenha evoluído, e que não utilizemos mais os pobres animais. Mas como não somos mineradores e não vamos colocar canários presos dentro dos servidores, vamos ao ponto.

Canary release é uma forma de implementação que diminui a chance de um estrago grande em produção.

Imagine que ao invés de fazer uma mudança geral de um ambiente para o outro, você conseguiria balancear essa carga, abrindo aos poucos o tráfego de um ambiente para o outro, e controlar como as coisas vão indo, desta forma você minimiza muito o impacto, e a ação de contorno em caso de um problema.

Aqui vai o desenho de cima com o detalhe de um deploy utilizando essa técnica.

Bom, mas nem tudo são flores, rs.

Manter os ambientes e fazer a gestão dos componentes até chegar nesse tipo de cenário não é algo fácil. Se você quer chegar nesse nível, comece agora, e tenha disciplina.

Opinião:

Ao meu ver, esse tipo de abordagem é muito interessante para implementações de novas regras em funções já existentes, ou seja, quando você possui a V1 do código em produção. Caso seja a primeira implantação daquela função, ou microsserviço, não me parece fazer sentido o custo de manutenção da estrutura.

Obrigado por ler até aqui, deixe seu comentário, compartilhe com os amigos.

Um forte abraço e até a proxima semana.

Natan Pasquarelli Freitas

Deixe uma resposta

Powered by WordPress.com. por Anders Noren

Acima ↑

%d blogueiros gostam disto: