Como podemos definir um contexto de um microserviço?
No site da AWS, existe a definição: Microsserviços são uma abordagem arquitetônica e organizacional do desenvolvimento de software na qual o software consiste em pequenos serviços independentes que se comunicam usando APIs bem definidas. Esses serviços pertencem a pequenas equipes autossuficientes.fonte: https://aws.amazon.com/pt/microservices/
Já no site da redhat: Microsserviços são uma abordagem de arquitetura para a criação de aplicações. O que diferencia a arquitetura de microsserviços das abordagens monolíticas tradicionais é como ela decompõe a aplicação por funções básicas. Cada função é denominada um serviço e pode ser criada e implantada de maneira independente. Isso significa que cada serviço individual pode funcionar ou falhar sem comprometer os demais.
fonte: https://www.redhat.com/pt-br/topics/microservices/what-are-microservices
Certo, mas quando sei que uma parte do meu software, pode ser um microsserviço?
Antes de mais nada, antecipo que não existe uma regra, mas sim, algumas praticas que estão funcionando para muitas empresa. Uma delas, talvez a mais difundida, seja a segregação dos microsserviços por contexto de negócio. Essa segregação tem acontecido com frequência por conta do movimento das squads e times scrums que são formadas por contextos de negócio e costumam se tornar responsáveis por determinados contextos de negócio.
E quais fatores eu deveria considerar quando penso em criar microsserviços?
Eu costumo considerar os seguintes fatores:
- Quantidade de desenvolvedores/engenheiros e de times - microsserviços muito pequenos, podem prejudicar a manutenibilidade por aumentar a quantidade de aplicações dentro da corporação.
- Contexto de negócio - por experiencia, tenho percebido uma maior facilidade de trocar informações com os responsáveis de negócio ou product owner.
- Uso individual - esse é um ponto bem importante. Se uma parte do seu negócio pode ser usado independente de outras partes, de forma individual, é coerente pensar em criar um microsserviço para esse contexto. Vou dar um exemplos que surgiu em um bate papo com um colega:
- Discutimos a possibilidade de criar um microsserviço de endereço, mas nos deparamos com a seguinte questão: Onde usaríamos esse serviço, sem necessariamente estar atrelado ao outro microsserviço que possuímos (o microsserviço de usuário). Logo, percebemos que não seria viável quebrar o contexto de endereço para fora de usuário, pois esse contexto não teria uso fora do contexto de usuário. Entendemos que usuário tem um endereço e endereço não é nada sem o usuário (no nosso cenário).
- Código duplicado - entendo também que não é bacana duplicar código em diferentes microsserviços. Então, quando ocorrer essa situação, seria interessante isolar esse contexto, porém, esse contexto, para ser um microsserviço, deveria estar diretamente relacionado ao negócio (para não ferir os principio acima). Então, se não for um contexto de negócio (por exemplo, endereço - no meu caso), poderíamos criar uma simples API ou uma biblioteca para compartilhar o código entre os microsserviços.
A sugestão que posso te dar, é seguir o que busco seguir com minha equipe. Sempre buscamos discutir e pensar juntos. Envolver alguém de negócio, que possua um viés técnico, pode ser interessante.