Três lições que aprendi com o Hype de Microsserviços
Peter Rausch 
Você realmente precisa de microsserviços?
Monolith First
A primeira data era 3 de junho de 2015 e Martin Fowler escreveu um artigo “MonolithFirst” aconselhando para sempre iniciar uma nova solução com um monolito, organizá-lo em módulos e dividir em microsserviços somente quando ele se tornar um problema. Isso diminui o custo de desenvolvimento, o tempo de liberações e no final das contas, temos uma solução mais simples, visto que não precisamos lidar com os desafios de uma arquitetura distribuída.
Don´t start with a monolith
A segunda data era pouco menos de uma semana depois, em 9 de junho de 2015, Stefan Tilkov contra argumentou, em seu artigo “Don’t start with a monolith”, que é muito difícil manter os módulos tão bem isolados uns dos outros como uma arquitetura de microsserviços precisa. Quando você inicia com uma arquitetura de microsserviços você é forçado, naturalmente, a desenvolver serviços bem desacoplados.
It all depends
A terceira data era meados de 2016–2017 quando eu recebi uma solicitação de um projeto que era basicamente um blog de conteúdo em que o cliente queria que fosse desenvolvido com arquitetura de microsserviços.
Tempo depois, realizei uma consultoria, para uma empresa da área de indústria, onde avaliei a arquitetura de software de um sistema que controlava UMA máquina e que havia sido construído com 28 microsserviços.
Vi também soluções que poderiam ser facilmente solucionadas com um worker trabalhando em background e escala horizontal virando complexos 23 implantáveis.
3 lições
Particularmente, eu gosto bastante da definição de microsserviços da Amazon:
Na maioria das vezes que nós desenvolvedores discutimos assuntos da nossa área, temos o costume de enxergar só a parte técnica. Sério, é SENSACIONAL ver uma estrutura de microsserviços funcionando perfeitamente. Aquele monte de componentes se comunicando com requisições pra cá e pra lá, mensageria, processos assíncronos. É muito massa! Fala verdade!
Mas vocês perceberam um detalhe muito importante na definição da Amazon? A adoção de uma arquitetura de microsserviços não começa na parte técnica, mas sim na estrutura ORGANIZACIONAL do desenvolvimento de software. Um microsserviço é um software INDEPENDENTE que pertence a UMA EQUIPE.
Primeiramente, Lei de Conway.
Isso nos leva a primeira grande lição, Lei de Conway:
- As organizações que projetam sistemas são obrigadas a produzir designs que são cópias das estruturas de comunicação dessas organizações.
Interessante, não? E podemos até considerar invertê-la:
- As organizações que projetam sistemas são obrigadas a estruturar comunicações que são cópias dos designs destes sistemas.
Indo ou voltando, no final das contas, a organização da sua empresa e a estrutura do seu software devem estar em sintonia para que a comunicação, o desenvolvimento e a estratégia sejam construídos de maneira adequada e eficiente.
Segundamente, Scale Cube.
A segunda lição diz respeito ao principal argumento técnico que ouço pra adoção de microsserviços: escalar o software. E gosto de responder esse argumento com o Scale Cube, que nos apresenta 3 maneiras de escalar software:
XAxis
No eixo X temos replicação horizontal. Seu sistema está preparado para escala horizontal? Se eu criar novas instâncias, incluir um Load Balancer na frente ele vai continuar funcionando? Quais componentes extras precisam ser construídos pra isso funcionar? Um ótimo exemplo desse cenário é o Stack Overflow. São 1.3 bilhões de page views por mês com um monolito com escala horizontal.
YAxis
No eixo Y temos decomposição funcional, ou seja, macro/microsserviços. Nesse ponto começamos a pensar sobre escala não somente de software, mas escala organizacional. A complexidade de implementação aumenta, visto que é necessário mudanças técnicas e organizacionais. É necessário um entendimento muito claro de equipes, setores e processos da sua empresa para que tudo funcione corretamente.
ZAxis
No eixo Z vamos separar coisas similares, ou seja, vamos ter o sistema sendo executado com um subset de informações. É uma solução mais comum do que imaginamos. Empresas que implantam seu sistema por cliente, por exemplo, escalam dessa maneira.
O Scale Cube nos apresenta caminhos que podem ser utilizados separadamente ou combinados para construirmos uma estratégia sólida para escala da aplicação. Mas qualquer que seja a estratégia, ela começa pelo business.
Em terceiro lugar, Domain Driven Design.
Em terceiro lugar, mas não menos importante, gostaria de falar sobre Domain Driven Design. O termo foi cunhado por Eric Evans em 2003.
Implementei meu primeiro sistema utilizando DDD entre final do ano de 2014 início de 2015. Naquela época, estruturei o sistema com direito a todas as peças que eu achava importante: Entities, Repositories, Domain and Applications Services…
A experiência foi ótima, mas demorei para entender que DDD não era tanto sobre construir software, mas sobre entender o negócio. A parte técnica ou tática é bem bacana, mas a parte estratégica é verdadeiramente fascinante. Como entender o negócio pode fazer tanta diferença na construção de sistemas? E acredite em mim, FAZ.
Pra mim hoje, não faz sentido construir sistema longe do business. Não tem como levantar requisitos arquiteturais de um software sem entender o negócio. Não consigo sequer escrever um bom código sem entender o problema que ele realmente precisa resolver.
Domain Driven Design mudou minha forma de desenhar sistemas. Comecei a desenhar sistemas em uma época onde tudo se começava pelo desenho do banco de dados. Pensávamos primeiro nos dados para depois encaixar as funcionalidades neles. Hoje começo pelos PROCESSOS. Dados são consequências dos processos. Com processos bem desenhados, fica mais fácil desenhar módulos, microsserviços, arquitetura e infraestrutura. E o DDD possui diversas ferramentas que auxiliam nessa construção incluindo a parte estratégica, domínios e processos do negócio.
Comece simples, evolua conforme a complexidade
Desenvolver sistema distribuídos ou microsserviços aumentam complexidade. Quando você tem uma estrutura organizacional e um sistema gigantescos faz sentido quebrar essa complexidade em pequenas peças que andam independentes. Isso realmente acelera o todo. Mas quando você tem um sistema de pequeno e médio porte, não faz sentido trazer essa complexidade na maioria dos casos. Avalie sempre o tamanho da sua organização e a estratégias que se adequam ao seu momento atual.
Só de começar a pensar em uma arquitetura distribuída me vem em mente:
- Quais serviços vou precisar construir? Normalmente começo com o de identidade, mas e depois?
- Quais componentes extras como o de caching distribuído vou precisar?
- Quais padrões de comunicação vou utilizar e como tratar idempotência e resiliência? Não só como vou escalar horizontalmente CADA serviço, mas como vou garantir elasticidade deles?
- O negócio está preparado para tornar seus processos assíncronos? Não há microsserviços sem mensageria.
- O negócio está preparado para não ter consistência dos dados o tempo inteiro? Teorema CAP (Consistency, Availability, Partition Tolerance)
- Como vamos implementar transações distribuídas? (SAGA/SEC Patterns)
- Quais ferramentas vou precisar para ter um monitoramento de tudo isso?
- etc, etc…
Eu adoro ver discussões entre lados opostos. É essencial acompanhar pessoas que se dispõe a discutir. Acredito que sempre existem pontos de vista diferentes e, pra mim, isso é pensar de maneira estratégica. Aprendo muito nessas horas porque simplesmente eu preciso pensar e formar minha própria opinião. Olhar o problema sendo discutido de óticas diferentes, analisar e falar um bom e velho “DEPENDE”.
Bom e qual minha opinião? Você deve utilizar microsserviços ou não? Acabei de responder, certo? DEPENDE!
É importante analisarmos caso a caso e avaliar se a solução cabe no problema. Não é uma verdade que se funciona no Netflix, Uber ou Twitter vai funcionar no teu negócio também. Você não é um deles. Os problemas são diferentes e precisam de soluções diferentes.
Rodrigo Hülsenbeck 
