A Jornada da Shoprocket para Microserviços: Parte 1

Alguns meses após começar meu trabalho na Shoprocket, comecei a ficar frustrado. Tínhamos uma aplicação em PHP sendo desenvolvida por nossa pequena equipe de desenvolvedores brilhantes, espalhados pelo mundo todo. Por que eu estava ficando frustrado? Para mim, parecia que correções de bugs geravam mais bugs, integrar novas funcionalidades não era tão simples quanto poderia ser, e as implantações eram infrequentes e estressantes. A razão para esses problemas: um código altamente acoplado.

Tínhamos uma aplicação monolítica e quase todo o nosso código estava em um único repositório do Github. Atualizações ou correções de uma funcionalidade muitas vezes ocorriam em vários lugares. Para os testes, tínhamos um processo de revisão por pares, onde pelo menos dois outros desenvolvedores tinham que aprovar um branch antes de ser mesclado ao master e implantado. Tudo isso significava que, quando bugs conseguiam escapar sem serem notados, muitas vezes era difícil localizar as mudanças quebra.

Sendo um jovem desenvolvedor ansioso, sempre à procura da novidade, quando encontrei microserviços, pensei que esse estilo arquitetônico resolveria todos os nossos problemas. Não há uma definição formal de microserviços, mas a partir da minha pesquisa, percebi que a arquitetura de microserviços é uma maneira de projetar aplicações de software como sistemas distribuídos de serviços independentes, cada um altamente especializado e com seu próprio ciclo de vida. Para os leitores que desejam uma introdução mais detalhada ao conceito, recomendo o excelente artigo de Martin Fowler.

Havia muitos aspectos dos microserviços que me interessavam, mas dois em particular: Primeiro, a ideia de dividir a aplicação em serviços com limites muito restritos. Isso reduz a chance de lógica específica de um contexto de negócios vazar entre componentes, porque as interfaces entre os limites devem ser cuidadosamente planejadas. Não é tão simples quanto fazer chamadas de função local; Segundo, cada componente pode ter seu próprio ciclo de vida independente. Isso permite que as equipes assumam a responsabilidade de seu código e utilizem uma pilha tecnológica mais adequada ao serviço individual. Além disso, permite um controle mais refinado sobre a aplicação, pois as mudanças podem ser implantadas em um serviço de cada vez e revertidas sem afetar o restante da aplicação se algo der errado.

Então, eu estava convencido. A Shoprocket quebraria o monolito! Este é o primeiro de uma curta série de posts no blog acompanhando essa jornada. Minha esperança é que leitores que planejam ou estão passando por uma transição semelhante aprendam com nossos sucessos e fracassos, e se sintam mais preparados para enfrentar esse desafio em seus próprios projetos.

Meu primeiro desafio não foi técnico, mas humano. Eu tinha que vender a ideia para o restante da equipe. Eles pareciam curiosos, mas não compartilhavam o mesmo entusiasmo e estavam relutantes em abrir horas de desenvolvimento neste estágio inicial da vida do nosso produto. Felizmente, o CTO queria que eu investigasse nossa gestão de sessões e aproveitei a oportunidade convencendo-o de que eu poderia separar um serviço de sessão.

Em retrospectiva, talvez essa tenha sido uma escolha ruim de componente para um primeiro serviço. Nosso produto inclui um plugin em javascript que habilita ecommerce em qualquer site. Tratamos as sessões como um recurso, persistindo informações de sessão no banco de dados para análise detalhada de KPIs como taxas de abandono de carrinho. No entanto, esse recurso não é tão tangível quanto algo como pedidos ou itens de linha. Além disso, estávamos usando o recurso de sessão com quase cada mudança no estado da aplicação. Isso significava que o serviço inevitavelmente teria uma comunicação excessiva com o restante da aplicação, o que eu não previa, mas tornava minha tarefa difícil.

Depois de convencer meu chefe, intensifiquei minha pesquisa sobre microserviços. Além do artigo mencionado, também descobri 'Construindo Microserviços' de Sam Newman, que é um recurso inestimável. Vou me referir a ambos com frequência em meus posts.

Em seu livro, Newman recomenda primeiro reestruturar uma aplicação existente em módulos que reflitam os contextos delimitados do domínio. Depois, uma vez que os desenvolvedores estejam satisfeitos, os módulos podem ser separados em seus próprios serviços. A razão para isso é que é muito mais fácil dividir e reescrever módulos cujos limites foram mal escolhidos do que dividir e reescrever serviços inteiros, com todo seu código de encanamento extra e recursos persistentes. No entanto, devido a restrições de tempo e minha vontade de construir um componente próprio, avancei com o primeiro serviço.

Escolhi uma pilha apenas marginalmente diferente da que estávamos usando para nosso monolito e comecei a construir. A construção em si ocorreu rapidamente, levando algumas semanas para produzir uma aplicação autônoma com uma API REST. Só então as verdadeiras dificuldades começaram.

Eu precisava fazer o serviço se comunicar com o monolito. Foi nesse ponto que aprendi o quão acoplada a gestão de sessões estava com o restante do código. Demorei um tempo para desmontar chamadas de função existentes e traduzi-las em chamadas de API. Isso foi complicado. Como o serviço de sessão e o monolito tinham seus próprios esquemas de banco de dados, tive que reescrever qualquer lógica no monolito que usasse recursos de sessão do antigo banco de dados, reestruturando os dados na fronteira da aplicação para manter a compatibilidade com clientes, como nosso plugin em javascript.

Integrar o serviço com nossa aplicação existente levou mais tempo do que escrever o próprio serviço, e isso não incluía muita da sobrecarga extra que microserviços normalmente trazem, como descoberta de serviços, registro e monitoramento. Além disso, devido ao acoplamento apertado, mudanças foram feitas em muitas áreas do código. Como a equipe havia trabalhado em várias áreas do código em paralelo durante esse tempo, teria exigido muito mais trabalho fundir as mudanças e colocar o serviço de sessão em produção.

O serviço pode em breve ir para produção, no entanto, agora sinto que deveria ter seguido o conselho de Newman e investido meus esforços em modularizar nossa aplicação existente. O benefício de ter um serviço vivendo sozinho é marginal. O verdadeiro benefício virá da divisão de tudo, pelo menos em serviços de granulação grossa, que se comuniquem o mínimo possível. Isso requer limites de componentes muito bem pensados, e ainda não chegamos lá.

Ainda estou convencido da ideia de microserviços, e vejo minha tentativa de separar um serviço como um experimento bem-sucedido. Aprendi muito sobre arquitetura de aplicações e modelagem de domínio nesse processo, e melhorei minha compreensão dos princípios REST, entre outras coisas. Isso teve um efeito imediato em outras áreas do nosso código.

Para leitores que buscam se converter, eu me certificar de ler o máximo possível sobre o assunto e postergar o trabalho até que você esteja muito confiante com seu código existente e seu modelo de domínio. Existem outras maneiras de introduzir estabilidade e resiliência em uma aplicação monolítica. O desenvolvimento orientado a testes e testes automatizados unitários e funcionais ajudam muito. O dimensionamento horizontal também ajuda a tornar as implantações um pouco mais suaves.

A Shoprocket continuará sua jornada para microserviços. Estamos ansiosos para contar mais a vocês na parte 2!