Migração sem sofrimento

Com uma boa arquitetura, testes A/B e chaveamento na borda

O contexto

Durante alguns anos no VivaReal, muitas pessoas trabalharam para substituir um grande legado monolítico por uma stack mais sustentável, baseada em microservices com responsabilidades mais definidas, deployments independentes, tolerância a falhas mais efetiva, etc. Enfim, uma stack moderna e pronta para mudanças e novas features.

Eu tive o prazer de acompanhar a última milha dessa longa jornada. Que foi a migração do https://www.vivareal.com.br/ para um dos últimos sistemas dessa stack a ficar pronto: o render!

Mas, antes de mais nada, eu separei artigos de outras pessoas que escreveram sobre outras partes dessa aventura:

• O Bin fala sobre como foi a separação dos assets e templates que possibilitou a transição para o novo render ser tão tranquila e transparente para o frontend.
• A Sabrina fala sobre o início dos testes e2e no site do VivaReal que possibilitou realizarmos muitos refactorings. Além de pegar alguns bugs bem chatos durante o desenvolvimento do novo render.
• O Erick fala sobre o início do time de plataforma que mantém serviços vitais para o funcionamento dos sites (provavelmente o maior cluster de Kubernetes do Brasil é o nosso)!
• E nesse outro post eu falo em como fizemos para juntar todos os dados de todos os microservices que existem aqui no Grupo Zap para o frontend e o render utilizarem!

A estratégia

Como os assets já estavam separados, nós decidimos fazer o chaveamento na borda e o novo render (feito em NodeJs) e o antigo render (um pedaço já bem pequeno do legado monolítico em Java) acessariam sempre a última versão dos assets na mesma origem.

O desafio nesse ponto foi encontrar uma maneira de fazer esses dois sistemas coexistirem servindo no mesmo domínio. Sendo que o novo render deveria ser utilizado somente quando um determinado parâmetro estivesse presente na query string, por exemplo ?__vt=ch:a , faz com que um request recebido seja servido pelo novo render e sem o parâmetro pelo antigo.

Duas origens para o mesmo domínio

Como utilizamos a Cloudflare como nosso servidor de borda, fomos logo pesquisar se havia alguma forma de fazer diretamente lá… e sim, existe uma feature muito interessante chamada Resolve Override que se encaixou exatamente nas nossas necessidades! Com ela podemos, dada uma expressão de URL, por exemplo, https://www.vivareal.com.br/venda/*__vt=ch:a* , selecionar um outro servidor como origem, aqui tem um exemplo mais concreto.

Assim conseguimos chegar em um cenário bastante favorável para a nossa migração:

Seleção de usuários para usar o novo render

Fonte

Para a seleção de usuários que seriam os nossos beta testers nós utilizamos uma ferramenta de testes A/B, o Google Optimize. Com ela conseguimos direcionar qualquer percentual dos nossos usuários para essa URL com o parâmetro na query string que era servida pelo novo render.

Como a ferramenta já era utilizada no site do Viva Real, foi realmente muito simples aproveitá-la para o nosso propósito.

Baby steps

Com a forma de chaveamento entre os backends e a seleção dos usuários definidos, nós começamos a fazer a virada para o novo render uma página por vez.

Primeiro as páginas mais simples até chegar nas mais complexas. Sempre acompanhando os erros que ocorriam e corrigindo-os rapidamente.

Também conseguimos comparar o tempo de resposta dos dois backends e fazer ajustes quando necessário.

Quando algo dava muito errado, nós simplesmente desligávamos o teste A/B ou a regra de chaveamento na borda, corrigíamos o problema e começávamos novamente.

Conclusão

Dessa forma conseguimos realizar a virada de um backend para outro com muita tranquilidade e, além de tudo, conseguimos acompanhar diversas métricas entre o antigo e novo backends. Por exemplo: conversão, bounce rate, tempo de resposta, percentual de erros e muitas outras.

Isso só foi possível por que nós delimitamos sempre as mudanças ao menor tamanho possível. Isso fez com que algumas novas funcionalidades e sistemas fossem utilizados primeiro no legado e, sim, implementamos um monte de coisas que foram jogadas fora. Mas poder fazer essa virada de forma tão sustentável e segura valeu a pena cada linha de código. Até aquelas que ficaram em produção somente algumas semanas.