Os microsserviços surpreenderam nossa indústria. Equipes em todo o mundo abandonaram a construção de grandes softwares monoliticos em busca do sonho dos microsserviços fracamente acoplados, gerenciáveis e de implantação independente. Infelizmente, muitos deles acabaram pior do que estavam antes – no reino dos monolitos distribuídos. Por quê?
O texto abaixo é uma tradução autorizada do artigo escrito por Vladik Khononov. Para acessar a versão original em inglês, clique aqui.
“Se eu tivesse uma hora para resolver um problema, passaria 55 minutos pensando no problema e 5 minutos pensando em soluções” – Albert Einstein
Na minha opinião, essa citação é a chave para resolver a maioria dos problemas que temos ao projetar sistemas baseados em microsserviços. Nós nos apressamos em encontrar soluções sem antes garantir que sabemos exatamente o que é um microsserviço. Neste post, gostaria de tentar responder a essa pergunta.
Antes de nos aprofundarmos nos microsserviços, vamos começar pelo início e falar sobre o termo “serviço”.
O que é um Serviço?
De acordo com a definição OASIS, um serviço é um mecanismo que permite o acesso a um ou mais recursos. No nosso caso, esses recursos podem ser: executar comandos, realizar consultas ou disparar eventos. Todos eles formam a interface pública de um serviço.
Aqui está um exemplo de um sistema de gerenciamento de pendências (backlog):
Agora, vamos ver o que torna um serviço um microsserviço.
O que é um Microsserviço?
Se um serviço é um mecanismo que permite o acesso a uma ou mais operações publicamente executáveis, então um microsserviço é um serviço com uma “micro” interface pública. Ele fornece o mínimo de operações públicas possível – literalmente, um “micro” serviço.
O motivo para essa heurística é autonomia. É o que estamos procurando quando implementamos esse estilo de arquitetura – serviços autônomos. No entanto, um serviço não pode ser totalmente autônomo e independente de seu ambiente. Tal serviço não teria nenhuma interface pública e, consequentemente, não seria capaz de receber ou expor qualquer dado. Ele seria totalmente autônomo, mas inútil. No entanto, podemos aumentar a autonomia, limitando as razões, do serviço e de seus clientes, para alteração: quanto menor a interface pública, menos o serviço está acoplado ao seu ambiente. Assim, é mais autônomo.
Projetar serviços de tal forma que minimize suas interfaces públicas parece simples, certo? Não é.
De Microsserviços a Sistemas
Uma abordagem ingênua seria cada microsserviço expor apenas uma operação pública. Você não pode ter um serviço menor do que isso, certo?
No caso do nosso serviço de gerenciamento de backlog, um microsserviço “ingênuo” pareceria assim:
Essa decomposição faria sentido se estivéssemos no negócio de fornecer microsserviços. Mas nós não estamos. Microsserviços independentes não fornecem nenhum valor para nossos clientes. Eles só fornecem valor quando são compostos em sistemas que funcionam – e é para isso que somos pagos.
Vejamos o que aconteceria se fôssemos compor um sistema de gerenciamento de backlog a partir de um conjunto “ingênuo” de microsserviços.
Visto que queremos microsserviços bem-comportados, cada um deles teria seu próprio banco de dados:
E como todos esses bancos de dados manipulam o mesmo conjunto de entidades de negócios, os dados devem ser replicados e sincronizados entre muitos deles. Para tanto, os serviços terão que expor seus dados de alguma forma – digamos, disparando eventos:
E é assim que os dados fluiriam entre eles:
Começamos com uma operação pública por serviço, mas, para implementar os Casos de Uso do sistema, acabamos com uma média de 4,75 métodos por serviço. Adicionalmente, o número total de operações públicas do sistema passou de 8 para 38! E para piorar ainda mais as coisas, alguns deles ainda teriam que participar de transações distribuídas. Lá se foram os microsserviços autônomos, independentemente implantáveis e gerenciáveis. Ugh!
Vamos ver o que aconteceu aqui. Nós fomos longe demais com a decomposição do sistema em serviços. Eu nem mesmo os chamo de microsserviços! Para suportar os casos de uso do sistema, as interfaces públicas desses serviços cresceram fora de controle e as integrações entre elas dispararam. Essa complexidade acidental da interface nos levou diretamente para o beco sem saída chamado Monolito Distribuído.
Assim sendo…
O que são Microsserviços?
A arquitetura de microsserviços é a decomposição de um sistema em um conjunto de serviços, de modo que todos esses serviços tenham interfaces públicas mínimas.
O limite no qual o sistema pode ser decomposto é definido pelos casos de uso do sistema do qual os microsserviços fazem parte.
Esta definição sustenta o fato conhecido de que cada microsserviço deve ter seu próprio banco de dados. Isso porque, em outro caso, um dos serviços teria que expor seu banco de dados como sua interface pública. E essa enorme interface pública o tornaria um macro-serviço.
P.S.
“Bounded Contexts, Microservices, and Everything in Between”: a palestra que eu proferi na conferência DDDX 2018, onde falei sobre esse tópico – o que exatamente são Microsserviços, estratégias para decompor sistemas em serviços e heurísticas para encontrar os limites dos Microsserviços.
Autor: Vladik Khononov
Publicado originalmente em vladikk.com
Você também pode segui-lo no twitter: @vladikk
