Continuando na minha saga de estudos de system design, me deparei com o seguinte repo no Github, é bem comum ter esses repositórios com vários artigos, indicações de livros, etc sobre determinado assunto, os famosos “Awesome X” (onde X pode ser qualquer coisa).

Dando uma sapiada pelos tópicos, em livros, vi a indicação do Building Microservices, um livro que já me havia sido recomendado para entender mais dessa arquitetura, de maneira geral. E ai, linkando com system design me veio o click. “Mas pera ai, em entrevistas de system design, normalmente você é requisitado a desenhar uma feature X do zero, e isso normalmente envolve utilizar microservices, afinal maioria das vezes estamos interessados em fazer algo altamente escalável, para milhões de usuários, então obviamente saber traçar as bordas, comunicação, etc, desses serviços é algo que é cobrado indiretamente, e é justamente disso que esse livro trata”.

Tudo fez sentido na minha cabeça, então resolvi que era a chance perfeita de apreciar essa maravilhosa obra, afinal também casa um pouco com o que estou desenvolvendo no trabalho (atuando em ambientes distribuídos).

Obviamente os tópicos e soluções discutidas em entrevistas de system design não fazem parte da grande maioria das pessoas, afinal, nem todo mundo trabalha em FAANGs e afins, mas pasmem, tem empresinha por ai com 1000 MAUs pedindo pra vc desenhar o sistema de search da Amazon ¯_(ツ)_/¯.

O que é um microsserviço?

Começando do começo, afinal. o que é um microsserviço?

Microsserviço é um serviço que pode ser deployado independentemente e que é modelado baseado em um domínio de negócio. Traduzindo, um serviço que representa alguma capacidade do negócio e que é independente, no sentido que pode ser feitos novos releases sem prejudicar outros serviços (perceba que essa independência é uma das maiores forças dos microsserviços).

Então, pensando em um sistema de ecommerce por exemplo, poderíamos ter um serviço de catálogo, um de gestão de pedidos e outro de entregas / encomendas.

SOA (Service Oriented Architecture)

Acho importante destacar que uma arquitetura orientada a microsserviços é um exemplo específico de arquitetura orientada a serviços, ou seja, Microsserviços é SOA porém o contrário não é válido, afinal, constraints específicos de microsserviços como independência de release, definição clara das bordas entre serviços, etc, fazem com que microsserviços se diferencie de outros approaches em que SOA pode ser aplicado.

Características chave de microsserviços

Algumas características são chave para que os serviços estejam aderentes ao conceito de microsserviços, como:

Deploy independente

Já mencionei anteriormente esse ponto, mas tome ele como o mais importante. Focando em deploys independentes somos forçados a seguir e fazer direito muitos outros pontos, ou seja, conseguindo executar corretamente esse ponto, conseguimos um monte de outros benefícios auxiliares.

Para termos um deploy independente somos forçados a definir de maneira clara contratos entre os serviços e seguirmos esses contratos a risca, além disso, devemos garantir que os serviços sejam desacoplados, sem compartilhar banco de dados por exemplo, ou outros recursos, como máquinas. Por isto a ideia de containers casa tão bem com microsserviços.

Modelado baseado em um domínio de negócio

Aplicando conceitos de domain driven design conseguimos fazer com que nosso código represente melhor o mundo real e o domínio de negocio em que ele está incluído. Com a arquitetura de microsserviços podemos aplicar essas mesmas ideias para definir as bordas de nossos serviços, ou seja, até onde é domínio de um serviço ou de outro.

Essa é uma outra parte crucial da arquitetura, conseguir definir de maneira eficiente as bordas dos serviços evita com que mudanças em uma única feature requisite que múltiplos serviços sejam alterados (um claro smell de que suas bordas podem estar erradas).

Dono do seu próprio estado

Aqui é um ponto bem específico, microsserviços NÃO COMPARTILHAM ESTADO, ou seja, possuem seus próprios banco de dados. Se um serviço precisa de acesso a dados que estão em outro serviço, este precisa requisitar de alguma forma o dado do outro serviço (request HTTP, mensageria, etc).

Essa característica faz com que os detalhes de implementação de cada serviço seja desconhecida (diminuindo o acoplamento entre os serviços), forçando cada serviço ter uma API especifica de o que é ofertado a outros serviços (contratos bem definidos). Além disso, diminuindo o acoplamento conseguimos de uma maneira mais simples deploys independentes (perceba como tudo está conectado).

Como modelamos nossos serviços baseado em domínios de negócio, então temos cada serviço como uma representação de uma capacidade do negócio, conseguimos reduzir os custos para que uma alteração específica deste domínio seja feita, ou seja, conseguimos uma coesão grande com as funcionalidades do negócios.

Alinhamento de arquitetura e divisão organizacional da empresa

Relacionando novamente com a questão da modelagem em torno dos domínios de negócio, conseguimos assim alcançar uma arquitetura que está intimamente ligada com a estrutura organizacional da empresa.

Mudanças que antes iriam exigir coordenação de múltiplos times agora exige somente a coordenação dos membros de um time, tornando todo o processo de entrega de novas funcionalidades mais rápido.

Por este motivo, mais uma vez reforçando, é de extrema importância conseguir fazer de maneira correta a delimitação das bordas de cada serviço.

Tamanho de um serviço

Aqui é um parêntesis para um ponto que talvez não seja tão relevante assim, mas que normalmente é uma pergunta muito comum. Qual o tamanho ideal de microsserviço?

Embora não haja resposta correta (pois isso depende de diversos fatores), esse questionamento se mostra pouco importante quando comparamos com as outras características. Se conseguirmos fazer certo as outras partes essa pergunta perde o sentido.

Flexibilidade

A flexibilidade em termos de escolha de tecnologia que microsserviços habilitam é um outro ponto importante de mencionar, obviamente essa flexibilidade vem com um custo, que é toda a complexidade gerada para se manter um sistema distribuído, portanto, devemos sempre balancear os custos de adotar uma tecnologia nova em um novo serviço vs os reais benefícios que teríamos no processo.

Conclusão

Então, apresentadas a definição de microsserviços e suas principais características, falaremos mais pra frente sobre vantagens e desvantagens, principalmente quando comparados com o outro tipo de arquitetura tradicional (em camadas, monolito), pra que, obviamente, quem leu os posts não seja pego de surpresa quando essa pergunta (que parece meio básica mas complexa de responder) apareça na sua próxima entrevista de emprego.