Existe uma receita que nos permite ter o mesmo prato utilizando fornos, ingredientes e anos de prática diferentes. O caminho para saber quando utilizar microserviços é parecido. Talvez observando e aprendendo com o colega ao lado, um dia consigamos fazer essa mágica.
Achar um checklist que mostre se você deve ou não adotar uma arquitetura de microserviços é bem semelhante ao caso acima. Infelizmente não existe receita de bolo. Cada caso dependente da estrutura organizacional e das pessoas envolvidas com a solução.
<div id="toc_container" class="toc_white no_bullets">Sum&aacute;rio<ul class="toc_list"><li><a href="#Antes-de-conceituar-microservicos">1 Antes de conceituar microserviços</a></li><li><a href="#Quando-utilizar-a-arquitetura-de-microservicos">2 Quando utilizar a arquitetura de microserviços?</a><ul><li><a href="#Em-seu-livro-Architeting-for-Scale-Lee-Atchison-propoe-quatro-aspectos-que-podem-ser-a-fronteira-para-decidir-utilizar-ou-nao-microservicos-Sao-eles">2.1 Em seu livro Architeting for Scale, Lee Atchison propõe quatro aspectos que podem ser a fronteira para decidir utilizar ou não microserviços. São eles:</a><ul><li><a href="#A-aplicacao-possui-um-requisito-especifico-de-negocio">2.1.1 A aplicação possui um requisito específico de negócio</a></li><li><a href="#Times-distintos-separados-e-donos-do-servico">2.1.2 Times distintos, separados e donos do serviço</a></li></ul></li></ul></li><li><a href="#Base-de-dados-naturalmente-separada">3 Base de dados naturalmente separada</a></li><li><a href="#Necessidade-de-compartilhamento-de-dados">4 Necessidade de compartilhamento de dados</a></li><li><a href="#Isso-nos-traz-alguns-problemasou-desafioscomo-por-exemplo">5 Isso nos traz alguns problemas — ou desafios — como por exemplo:</a></li></ul></div>
<h2>Antes de conceituar microserviços</h2>
Precisamos relembrar o que é uma aplicação monolítica, um microserviço e o que seria uma arquitetura baseada em microserviços.
Segundo Lee Atchison, quando possuímos mais de um time trabalhando em diferentes propósitos de negócio na mesma aplicação, ela com certeza cresceu monolítica. E, durante esse tempo se tornou cada vez mais complexa.
<img fetchpriority="high" decoding="async" class="aligncenter wp-image-3970 size-full" title="quando utilizar microserviços" src="https://dtidigital.com.br/wp-content/uploads/2019/01/1.png" alt="quando utilizar microserviços" width="252" height="219" />
De maneira diferente, um microserviço é uma aplicação simples. Possui um único objetivo e sua própria base de dados. Quando temos mais de um desses microserviços interagindo entre si, conversando por meio de <a href="https://dtidigital.com.br/blog/a-importancia-de-um-api-gateway-na-arquitetura-de-microsservicos/">APIs</a> (Application Programming Interface) sem ter a necessidade de entender como é a lógica por dentro de cada um, temos “grandes chances” de ter uma arquitetura baseada em microserviços. Entenderemos o porque de “grandes chances” quando falarmos sobre os times responsáveis por essas aplicações.
<img decoding="async" class="aligncenter wp-image-3971 size-full" title="quando utilizar microserviços" src="http://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/2.png" alt="quando utilizar microserviços" width="301" height="239" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/2.png 301w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/2-300x238.png 300w" sizes="(max-width: 301px) 100vw, 301px" />
Agora com os conceitos relembrados, vamos voltar a nossa pergunta.
<h2>Quando utilizar a arquitetura de microserviços?</h2>
Novamente, não existe uma resposta direta. O que temos, são direcionamentos que devem ser utilizados durante uma discussão a cerca desse tema . Sim! Esse é um tema complexo. Permita que outras pessoas com experiências diferentes da sua participem dessa decisão.
<img decoding="async" class="aligncenter wp-image-3972 size-full" title="quando utilizar microserviços" src="https://dtidigital.com.br/wp-content/uploads/2019/01/3.png" alt="quando utilizar microserviços" width="256" height="251" />
<h3>Em seu livro Architeting for Scale, Lee Atchison propõe quatro aspectos que podem ser a fronteira para decidir utilizar ou não microserviços. São eles:</h3>
<h4>A aplicação possui um requisito específico de negócio</h4>
Se a sua aplicação armazena ou processa dados críticos de negócio como transações bancárias e ações judiciais, ela é uma forte candidata a ser um microserviço. Por muitas vezes, essas aplicações possuem particularidades intrínsecas ao seu processo.
<a href="https://dtidigital.com.br/blog/transformacao-digital-em-instituicoes-financeiras/">Uma aplicação que processa pagamentos</a> por exemplo, deve armazenar de forma segura os dados de cartões de créditos dos clientes .  Com acesso restrito . E, possivelmente precisará escalar de forma distinta das demais aplicações em determinado momento do dia, semana, mês ou ano.
Já uma aplicação que confere transações judiciais, certamente deve atender a requisitos técnicos legais para que possa funcionar . Requisitos que não necessariamente devem se aplicar as interfaces que utilizam essa aplicação.
<h4>Times distintos, separados e donos do serviço</h4>
Aliado a escalabilidade, essa talvez seja a justificativa mais requisitada para defender essa nova abordagem. Geralmente as aplicações nascem por um propósito e são simples na sua concepção. Porém, a necessidade de evolução tende a torna-las monolíticas. Principalmente quando são colocados vários times para trabalharem no mesmo código.
Voltando um pouco ao conceito discutido no início. A “grande chance” de se ter uma arquitetura baseada em microserviços só se torna concreta, se tivemos apenas um time responsável pelo microserviço.
<blockquote>A team can own or manage more than one service, but a service should be owned and managed by only one team. 
Architecting for Scale 
Lee Atchison</blockquote>
<h2>Base de dados naturalmente separada</h2>
Essa talvez seja a característica mais clara e direta de um microserviço. A figura a seguir nos ajuda a ilustrar essa diretriz.
<img loading="lazy" decoding="async" class="aligncenter wp-image-3973 size-full" title="quando utilizar microserviços" src="http://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/4.png" alt="o que são microserviços" width="567" height="218" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/4.png 567w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/4-300x115.png 300w" sizes="(max-width: 567px) 100vw, 567px" />
Em resumo, se sua aplicação possui sua própria base de dados acessível apenas via APIs, ela é uma forte candidata a ser um microserviço. Porém, se a base da sua aplicação pode ser acessada diretamente por outros serviços, ela não é uma boa candidata.
<h2>Necessidade de compartilhamento de dados</h2>
Se você precisa compartilhar informações a cerca de um domínio específico entre diversos serviços, na verdade, talvez exista uma necessidade de um microserviço. Um serviço simples. Sem lógica de negócio complexa que simplesmente compartilhe dados gerais de fornecedores seria um bom exemplo.
<img loading="lazy" decoding="async" class="aligncenter wp-image-3974 size-full" title="quando utilizar microserviços" src="http://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/5.png" alt="quando utilizar microserviços" width="267" height="291" />
É importante ressaltar que essa é uma diretriz e não uma regra. Nesse exemplo, a centralização pode ser útil para manter as informações em apenas um lugar. Porém, podem existir dados de fornecedores que são específicos para o Serviço A ou para o Serviço C. Nesses casos, talvez fosse melhor hospedar essas regras nos próprios serviços A e C do que no serviço E, que só seria consumido em algumas ocasiões.
Ok! Agora já tenho um norte e como estamos começando um novo projeto. Faremos TUDO utilizando microserviços.
<img loading="lazy" decoding="async" class="aligncenter wp-image-3975 size-full" src="http://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/6.png" alt="arquitetura de microserviços " width="441" height="295" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/6.png 441w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/6-300x201.png 300w" sizes="(max-width: 441px) 100vw, 441px" />
Como Daniel Stori nos conta, essa nova abordagem é atraente. Principalmente quando vemos cases como a Spotify e a Netflix.
Porém, não deve ser adotada as cegas. Cada vez que dividimos um serviço ou um domínio, diminuímos a complexidade daquela aplicação e aumentamos a complexidade do todo.
<h2>Isso nos traz alguns problemas — ou desafios — como por exemplo:</h2>
<ul>
<li>Fica cada vez mais difícil visualizar a arquitetura e comunicações entre as aplicações.</li>
<li>Se temos mais serviços comunicando entre si, temos mais requisições e consequentemente mais probabilidade de falhas.</li>
<li>Dependendo da frequência de utilização e quantidade de clientes, alterações bruscas nos microserviços como troca de base e ou tecnologia se tornam mais complexas pela possibilidade de afetarem serviços críticos.</li>
<li>Com base proprietária, os microserviços tentem a aumentar sua dependência com outras APIs. Mais dependências, maior a probabilidade de falhas.</li>
</ul>
Diante disso, talvez o segredo esteja em entender a situação atual do seu ambiente organizacional e qual alvo o seu time deve buscar aliado a um objetivo maior traçado pela organização.
Comece então pelos conceitos básicos.  Desenvolvimento orientado a domínio (DDD), bancos proprietários, serviços pequenos e um time responsável. E, evolua a análise baseada nas fronteiras discutidas ao longo do artigo. Essa pode ser, talvez, o começo da receita que queremos para saber quando utilizar microserviços.
Aqui na dti utilizamos microserviços em muitos projetos. Dentro do desenvolvimento ágil os microserviços tem um papel bastante relevante. Para saber mais sobre o mindset ágil e como o aplicamos aqui na dti <a href="http://www.cms.dtidigital.com.br/podcast/">ouça nosso podcast</a>&#8211; Os Agilistas &#8211; disponível em spotify, itunes, soundcloud e plataformas similares!

Você sabe quando utilizar microserviços em um projeto?

Desbloqueie o futuro do seu negócio

Confira outros artigos