# A jornada do Shoprocket rumo aos microsserviços, parte 1: o que eu errei ao quebrar o monolito > Post da equipe de engenharia dos primeiros anos do Shoprocket sobre a primeira tentativa de extrair um serviço de um monolito em PHP. Por que escolhi o primeiro serviço errado, o que o acoplamento forte me ensinou e o conselho do Newman que eu deveria ter seguido antes. Winston Berty - 17 de março de 2016 - 5 min de leitura Alguns meses depois de entrar no Shoprocket, eu estava ficando frustrado. Tínhamos uma aplicação em PHP mantida por uma equipe pequena de desenvolvedores afiados, espalhados pelo mundo, e para mim parecia que correções de bugs geravam mais bugs, integrar novos recursos não era tão simples quanto deveria ser e os deploys eram raros e estressantes. O motivo: código altamente acoplado. Tínhamos uma aplicação monolítica, quase toda em um único repositório do GitHub. Atualizações ou correções em um recurso muitas vezes exigiam mudanças em vários lugares. Para os testes, tínhamos um processo de revisão por pares em que pelo menos outros dois desenvolvedores precisavam aprovar uma branch antes de ela entrar no master e ir para produção. Tudo isso significava que, quando um bug passava, muitas vezes era difícil localizar a mudança que o causou. Quando achávamos, a correção passava pelo mesmo processo, e a aplicação inteira precisava de um novo deploy. Como um jovem desenvolvedor empolgado, sempre atrás da novidade, quando topei com os microsserviços achei que aquilo ia resolver todos os nossos problemas. ## O que eu achava que eram os microsserviços Não existe uma definição formal de microsserviços, mas, pelas minhas pesquisas, entendi que a arquitetura de microsserviços é uma forma de projetar aplicações de software como sistemas distribuídos de serviços independentes, cada um altamente especializado e com o seu próprio ciclo de vida. Para uma introdução detalhada, o [artigo](https://martinfowler.com/articles/microservices.html) de Martin Fowler é excelente. Dois aspectos me fisgaram. Primeiro, a ideia de dividir a aplicação em serviços com fronteiras rígidas. Isso reduz a chance de a lógica específica de um contexto de negócio vazar entre componentes, porque as interfaces entre as fronteiras precisam ser planejadas com cuidado. Não é tão simples quanto fazer chamadas de função locais. Segundo, cada componente pode ter o seu próprio ciclo de vida independente. As equipes podem ser donas do seu código e usar a stack mais adequada ao serviço, e as mudanças podem ser implantadas um serviço por vez e revertidas sem afetar o resto. Eu estava convencido. O Shoprocket ia quebrar o monolito. Esta é a parte 1 de uma série curta que acompanha a jornada. Espero que os leitores que planejam ou estão passando por uma transição parecida aprendam com os nossos acertos e erros. ## O primeiro desafio foi humano, não técnico Eu precisava vender a ideia para o resto da equipe. Eles estavam curiosos, mas não compartilhavam o entusiasmo, e relutavam em abrir mão de horas de desenvolvimento nessa fase inicial da vida do produto. Por sorte, o CTO queria que eu olhasse o nosso gerenciamento de sessões, então aproveitei o momento: convenci-o de que eu podia separar um serviço de sessões. Em retrospecto, foi uma escolha ruim para o primeiro serviço. O nosso produto inclui um widget em JavaScript que [habilita o e-commerce em qualquer site](https://v3.shoprocket.io/pt/funcionalidades/vender-em-qualquer-site.md). Tratamos as sessões como um recurso, persistindo as informações de sessão no banco de dados para analisar abandono de carrinho e outros KPIs. Mas esse recurso não é tão tangível quanto algo como pedidos ou itens de pedido, e usávamos sessões em quase toda mudança de estado da aplicação. Isso significava que o serviço inevitavelmente conversaria muito com o resto da aplicação, o que eu não previ e que tornou a minha tarefa mais difícil. ## O que aprendi construindo de fato Aumentei o ritmo da pesquisa. Ao lado de Fowler, o livro **Building Microservices**, de Sam Newman, se mostrou um recurso indispensável. O conselho de Newman, em retrospecto, era o conselho que eu deveria ter seguido: primeiro, reestruture a aplicação existente em módulos que reflitam os contextos delimitados do domínio. Quando os desenvolvedores estiverem satisfeitos com as fronteiras, *aí sim* separe os módulos em serviços próprios. O motivo é que é muito mais fácil desmontar e reescrever módulos com fronteiras ruins do que desmontar e reescrever serviços inteiros, com todo o código de infraestrutura extra e os recursos persistentes. Eu não segui esse conselho. Ansioso para construir um componente meu, segui em frente com o serviço de sessões. Escolhi uma stack só um pouco diferente da do monolito e comecei a construir. O serviço em si ficou pronto rápido, levando algumas semanas para produzir uma aplicação independente com uma API REST. Não foi aí que estava a parte difícil. A parte difícil foi fazer o serviço conversar com o monolito. O gerenciamento de sessões se mostrou fortemente acoplado ao resto da base de código. Trocar chamadas de função por chamadas de API foi um trabalho lento. Como o serviço de sessões e o monolito tinham esquemas de banco de dados separados, tive de reescrever toda a lógica do monolito que usava recursos de sessão do banco antigo, reestruturando os dados na fronteira da aplicação para manter compatíveis clientes como o nosso widget em JavaScript. Integrar levou mais tempo do que construir. E isso ainda sem contar a maior parte da sobrecarga que os microsserviços normalmente trazem: descoberta de serviços, logs, monitoramento, rastreamento distribuído. Pior, o acoplamento forte fazia as mudanças se espalharem por muitas áreas do código. Como a equipe vinha trabalhando em paralelo nesse período, fazer o merge e colocar o serviço de sessões em produção exigiria muito mais coordenação do que eu havia estimado. ## A avaliação honesta O serviço pode entrar em produção em breve. Mas hoje sinto que deveria ter seguido o conselho de Newman e concentrado o esforço em modularizar primeiro a aplicação existente. O benefício de ter um serviço vivendo sozinho é marginal. O benefício real vem de dividir o todo, pelo menos em serviços de granularidade grossa que conversem o mínimo possível entre si. Isso exige fronteiras de componentes bem pensadas, e ainda não estávamos nesse ponto. Continuo convencido dos microsserviços como ideia. Vejo a minha tentativa como um experimento útil. Aprendi muito sobre arquitetura de aplicações, modelagem de domínio e princípios REST, e essas lições tiveram efeitos em cascata em outras partes do nosso código. Para quem está pensando em uma transição parecida, minhas recomendações honestas: - Leia o máximo possível sobre o assunto antes de se comprometer - Adie o trabalho até estar realmente seguro da sua base de código atual e do seu modelo de domínio - Lembre-se de que existem outras formas de dar estabilidade e resiliência a um monolito. Testes unitários e funcionais automatizados ajudam enormemente. O desenvolvimento orientado a testes reduz regressões. A escala horizontal torna os deploys menos dolorosos - Comece modularizando o seu monolito antes de extrair serviços O Shoprocket vai seguir a sua jornada. A parte 2 é onde fica mais interessante. --- *Publicado originalmente como o primeiro de uma série curta que documenta a migração inicial do Shoprocket para longe de um monolito em PHP. A jornada completa, incluindo os erros corrigidos em iterações posteriores, continuou a cada grande reescrita da plataforma desde então.* --- - HTML version: https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito - Language: Português (pt) - Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Deutsch](https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Español](https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito.md), [Français](https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit.md), [Italiano](https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Türkçe](https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)