Micro serviços: O que são e para que servem?

Bem, vamos começar a falar sobre micro serviços! Você sabe o que são micro serviços? Então tá... Vamos falar um pouco sobre o assunto nesse post.

Essa é a preparação para meu novo tutorial e, talvez, para um novo livro sobre o assunto. Mas não pretendo esgota-lo em um post apenas. É só uma introdução.

Um micro serviço é um componente de alta coesão, baixo acoplamento, autônomo e independente, que representa um contexto de negócio de uma aplicação.

Arquitetura de micro serviços

Particionar sua aplicação em unidades independentes, autônomas, de alta coesão e baixo acoplamento. Uma das grandes vantagens é que os micro serviços devem ser criados, mantidos, executados e distribuídos de forma totalmente independente.

Como distribuir micro serviços

Você poderia desenvolver seus micro serviços como módulos do seu sistema, certo? Poderia embutir os JARs dentro de um WAR e ficaria tudo bonito, certo? Errado! Duas características importantes de micro serviços são: Autonomia e Independência. Isso significa que eu poderia fazer "deploy" de um micro serviço, sem ter que recompilar os outros ou os seus "clientes".

Para evitar esse acoplamento, o correto é que cada micro serviço seja instalado em um "host" diferente. Isso não significa máquina física. Pode ser em uma arquitetura de VMs, ou de Light Containers LXC. 

E os micro serviços se comunicam entre si e com os clientes usando mecanismos padrões e agnósticos de tecnologia, como HTTP e REST.

Tecnologicamente agnósticos

Os micro serviços são componentes autônomos e de baixo acoplamento, logo, não há necessidade que sejam construídos com a mesma linguagem ou que sejam processados na mesma plataforma.

Podemos ter um mix como esse:

Como ficam as nossas aplicações?

Tradicionalmente, fazemos aplicações monolíticas, que são distribuídas em um grande pacotão, como um WAR ou EAR. Se for necessário alterar um detalhe de um módulo, é necessário distribuir o pacotão todo inteiro.

Com micro serviços, podemos criar novas aplicações por composição, agregando os micro serviços que julgarmos necessários, sem camada de persistência, pois os dados são tratados apenas por cada micro serviço específico.

Porém, eu já sei que você vai pensar: "Hmmmmm.... Isso é ruim, pois agora, a UI tem que ficar chamando vários serviços...". Tem um padrão que evita esse tipo de problema:

O padrão "Backends for Frontends" consiste em criar módulos agregadores, para cada página, que consomem os micro serviços e montam as áreas de conteúdo para a página.

Mas, não seria melhor "orquestrar" com um ESB? 

Isso é orquestração: 

Há um módulo que controla os serviços. Isso viola dois princípios básicos: Autonomia e independência.

O melhor seria usar algum tipo de coreografia, baseada em eventos:

E como podemos distribuir os micro serviços? 

Podemos usar instâncias remotas, por exemplo no AWS, e instalar containers LXC, com o Docker. Então, podemos distribuir nossos micro serviços como aplicações Docker. 

Mas isso é um assunto para outro post. Aguarde.

Ah, se você gostou desse artigo, vai adorar este: "YAGNI e as pelancas do software corporativo"