Diurno

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

por: Fabrício Alves

data: 02/01/2019

Compartilhar no facebook
Compartilhar no twitter
Compartilhar no whatsapp
Compartilhar no linkedin
Compartilhar no facebook
Compartilhar no twitter
Compartilhar no whatsapp
Compartilhar no linkedin

Existe uma receita que nos permite ter o mesmo prato utilizando fornos, ingredientes e anos de prática diferentes? Talvez observando e aprendendo com o colega ao lado, um dia consigamos fazer essa mágica. O caminho para saber quando utilizar microserviços é parecido.

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.

Mas antes de entrar nessa esfera…

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.

quando utilizar microserviços

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 APIs (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.

quando utilizar microserviços

Agora com os conceitos relembrados, vamos voltar a nossa pergunta.

Quando utilizar microserviços?

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.

quando utilizar microserviços

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 aplicação possui um requisito específico de negócio

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.

Uma aplicação que processa pagamentos 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.

Times distintos, separados e donos do serviço

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.

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

Base de dados naturalmente separada

Essa talvez seja a característica mais clara e direta de um microserviço. A figura a seguir nos ajuda a ilustrar essa diretriz.

quando utilizar microserviços

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.

Necessidade de compartilhamento de dados

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.

quando utilizar microserviços

É 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.

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.

Isso nos traz alguns problemas — ou desafios — como por exemplo:

  • Fica cada vez mais difícil visualizar a arquitetura e comunicações entre as aplicações.
  • Se temos mais serviços comunicando entre si, temos mais requisições e consequentemente mais probabilidade de falhas.
  • 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.
  • Com base proprietária, os microserviços tentem a aumentar sua dependência com outras APIs. Mais dependências, maior a probabilidade de falhas.

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 ouça nosso podcast– Os Agilistas – disponível em spotify, itunes, soundcloud e plataformas similares!