Arquitetura de Transição: Migrando milhões de requisições utilizando feature flags

Introdução

A arquitetura de software é uma disciplina dinâmica, iterativa e evolutiva. Ao longo do ciclo de vida de um software, componentes que antes eram críticos podem se tornar desnecessários, ao mesmo tempo em que novos componentes podem passar a ser necessários para que o sistema se mantenha sustentável.

Um grande exemplo dessa característica evolutiva da arquitetura de software pode ser encontrado nos microserviços. O autor Martin Fowler, no artigo Monolith First, recomenda iniciar o desenvolvimento a partir de um monólito e, à medida que surgir a necessidade, aplicar microserviços. Essa abordagem descrita por Martin Fowler evidencia que a arquitetura de um sistema não é algo estático.

Ao longo da minha jornada como desenvolvedor de software, já tive que quebrar muitas aplicações em serviços menores e também já tive que fazer o oposto: unir muitos microserviços em uma única aplicação.

Um tipo de mudança arquitetural muito comum que envolve microserviços são as migrações. Migrações são movimentações de componentes ou recursos de um sistema de um ambiente computacional para outro. No contexto de microserviços, as migrações podem envolver a adição, remoção ou substituição de serviços dentro da topologia da arquitetura.

Devido à criticidade desse tipo de modificação, as migrações podem exigir a aplicação de múltiplas disciplinas, incluindo estratégias de deploy, monitoramento, rollback e planos de contingência, todas com o objetivo de permitir a execução desse processo de forma eficaz. É nesse momento que entra em cena um conceito definido por Martin Fowler, chamado de arquitetura de transição. Essa arquitetura envolve desenvolver uma estrutura temporária com o objetivo de facilitar a transição de componentes de um sistema.

Neste artigo, apresento um estudo de caso de arquitetura de transição, no qual adicionamos feature flags à arquitetura com o objetivo de realizar a migração de tráfego de uma aplicação com alto throughput para uma nova aplicação, tudo de forma totalmente transparente para os usuários.

Migrações em microserviços

Como mencionado na introdução deste artigo, a aplicação e a manutenção da arquitetura de microserviços em um sistema envolvem tanto a quebra de uma aplicação em aplicações menores quanto a união de aplicações em uma única aplicação. Observe que, quando me refiro à união de aplicações em uma única aplicação, não estou me referindo a uma união total, o que significaria um retorno à arquitetura monolítica, mas sim à unificação de partes do sistema que funcionariam melhor juntas do que separadas. Os mesmos fatores que motivam a quebra de uma aplicação em partes menores também podem motivar a unificação de aplicações em uma única parte.

Uma etapa importante desse processo de decomposição e unificação de microserviços é a etapa de migração, o momento em que implantamos a nova estrutura dos nossos serviços. Essa etapa é tão importante quanto a própria etapa de concepção do microserviço em si, pois é nesse momento que aquilo que estava em um ambiente controlado passa, de fato, a estar em produção.

Também é nesse momento que temos os primeiros dados observáveis dos novos serviços em produção e em que, caso necessário, colocamos nossa estratégia de rollback e planos de mitigação de falhas em prática.

Em nosso estudo de caso, tivemos que migrar o tráfego de uma aplicação para outra por motivos de decomposição. Possuíamos um serviço original que combinava características que teriam uma eficiência melhor se estivessem em componentes separados.

Migrações com feature flags

Feature Flags podem ser definidas como ferramentas condicionais que habilitam ou desabilitam comportamentos de um sistema em tempo de execução.

Muitos desenvolvedores já implementaram feature flags de forma intuitiva, sem ter consciência de que as estavam implementando. Por exemplo, quando adicionamos um if ao código para controlar algum recurso sem ter que modificar o código relacionado a esse recurso, estamos fazendo uso da forma mais simples de feature flags. Digo forma mais simples porque o escopo das feature flags vai muito além de um simples if que colocamos no código.

Uma das principais características das feature flags é nos dar um controle mais granular daquilo que estamos enviando para os ambientes de produção. Muitos podem não ver valor nesse tipo de funcionalidade, mas, em ambientes onde precisamos de um controle rigoroso do que está indo para produção, as feature flags se mostram como ferramentas valiosas.

Ben Nadel, no livro Feature Flags: Transform Your Product Development Workflow, afirma: “A natureza dinâmica do ambiente de execução não é um mero detalhe; é o fator fundamental que traz segurança psicológica e inclusão para a sua organização”.

Feature flags não são usadas apenas para controlar o lançamento de novas funcionalidades, mas também podem ser utilizadas como ferramentas de migração em estratégias de progressive delivery. Em comparação com a estratégia de deploy blue-green, a granularidade do rollout das feature flags é muito maior, enquanto o blue-green depende diretamente da topologia da infraestrutura.

Por que utilizamos essa estratégia?

A estratégia de deploy utilizando feature flags permite um rollout muito mais granular. Esse nível de granularidade era exatamente o que precisávamos, pois estávamos limitados pela topologia da nossa infraestrutura.

Como nosso objetivo era migrar o trafego de uma aplicação produtiva para uma nova aplicação, necessitávamos que essa nova aplicação estivesse totalmente funcional quando recebesse o trafego, por isso optamos por utilizar uma estratégia de Strangler Fig, essa estratégia consiste em manter as duas aplicações coexistindo de forma que uma sobreponha a outra de forma gradual, esse deploy gradual permite uma monitoração mais precisa do comportamento da nova aplicação.

A aplicação que desejávamos migrar de tráfego era uma aplicação que realizava o envio de comunicações para os canais de email e notificações push. Aplicações que lidam com esses tipos de comunicações possuem a característica de terem efeitos não reversíveis, ou seja, em caso de um bug em produção, mesmo após o rollback não teremos uma restauração completa dos efeitos dos bugs, pois a comunicação já foi enviada e seu processamento ocorre em um ambiente externo ao do nosso sistema. Com base nesse argumento e também no fato de estarmos lidando com uma quantidade muito elevada de requests, necessitávamos de estratégias de rollback muito bem estruturadas e, por isso, optamos pelo uso das feature flags para realizar a migração progressiva.

A estratégia de Strangler Fig, implementada pelo uso de feature flags, nos permitiu realizar a decomposição de toda a migração em partes menores, facilitando o seu monitoramento e permitindo um rollback rápido em caso de falhas.

Considerações finais

As decisões arquiteturais tomadas em nosso caso de uso, assim como tudo na arquitetura de software, envolvem trade-offs e, em nosso contexto, não foi diferente. Os principais trade-offs que identificamos foram o custo adicional de infraestrutura duplicada e a observabilidade mais desafiadora. Além disso, o uso de feature flags para operações de migração não é uma regra imutável, mas também uma decisão arquitetural do time, na qual é possível levar em conta outras estratégias de implantação progressiva, como o uso de API gateway, canary deploy etc. O objetivo deste artigo foi compartilhar como implementamos a estratégia da forma mais adequada ao nosso contexto.

Migrações são eventos muito importantes para a modernização de softwares e envolvem muitas disciplinas. Como complemento das disciplinas aqui abordadas, podemos citar o desenvolvimento de estratégias de decomposição do sistema e a observabilidade durante a migração. A implementação dessas disciplinas contribui de forma conjunta para a modernização de sistemas legados.

Referências

Transitional Architecture, por Martin Fowler: https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html

Feature Flags: Transform Your Product Development Workflow, por Ben Nadel