Revisitando microsserviços

Nas aulas anteriores da nossa disciplina, já discutimos alguns padrões arquiteturais, como a arquitetura baseada em microsserviços, a partir do material do Prof. Dr. Marco Túlio Valente, da Universidade Federal de Minas Gerais (UFMG). Agora, vamos retomar essa discussão, aplicando-a um contexto próximo à nossa realidade universitária.

🤯 Situação problema

Considere a seguinte situação:

Até aqui, certamente você já deve ter percebido que essas soluções tendem a ser implementadas como sistemas distintos, já que há particularidades relacionadas às regras de negócio (um sistema de votação é bastante diferente de um sistema de biblioteca).

Além disso, é comum que, a depender do contexto, sistemas COTS (software de prateleira) sejam utilizados em algumas ocasiões. No caso da UFMT, por exemplo, o sistema utilizado na biblioteca é um sistema COTS.

Note também que, na situação apresentada, um determinado conjunto de informações (ou seja: a lista de estudantes matriculados) precisa ser acessada por diferentes sistemas.

Em um primeiro momento, podemos pensar: simples, basta que todos os sistemas tenham acesso ao servidor de banco de dados e, então, execute as operações necessárias. Esta é, com certeza, uma possibilidade, que envolve algumas questões relacionadas a banco de dados (discutiremos mais à frente, ao longo da disciplina).

Pensando na perspectiva do projeto de arquitetura, podemos organizar diversos sistemas de software, cada um contendo um conjunto de classes (no caso de um programa orientado a objetos) capaz de tratar objetos da classe Estudante e, então, realizar algumas operações sobre esses objetos.

Neste caso, há um outro fator para considerarmos: o reúso de software.

💰 Reúso

Nas disciplinas introdutórias de programação, aprendemos que a repetição de implementações não é uma prática interessante. Com vistas ao reúso, implementamos, funções, procedimentos e bibliotecas.

Voltando ao caso atual, imagine a seguinte situação: se o tratamento das informações de Estudante precisar ser implementado em cada programa, podemos fazer reúso da implementação desde que essas soluções tenham sido desenvolvidas na mesma linguagem de programação. Se o sistema do Restaurante Universitário for implementado em PHP e o sistema de gestão de bibliotecas for implementado em JavaScript, o reúso direto do código não será possível, pois cada sistema monolítico teria sua própria implementação separada.

Para contornar essa limitação, embora ela também tenha suas limitações, podemos adotar uma arquitetura baseada em microsserviços. Dentre as principais vantagens dessa abordagem, pode-se citar a perspectiva de consumir um determinado serviço.

🧩 Aplicando microsserviços

A Figura a seguir apresenta uma ilustração de uma possível solução arquitetural que faz uso de microsserviços para o cenário discutido aqui.

O ponto-chave está na criação de um microsserviço chamado Estudantes, que pode ser consumido pelas outras aplicações. Deste modo, sempre que as aplicações específicas necessitarem consultar a lista de estudantes ou certificar que um estudante está com matrícula ativa, podem solicitar tal informação para o microsserviço de Estudantes, minimizando a necessidade de reimplementação de determinadas classes.

Outra vantagem é que cada microsserviço, como seu nome já indica, passa a ter um escopo menor. Ou seja: se a função de um programa relacionado ao Restaurante Universitário é registrar a venda de refeições, esse programa não precisa implementar regras de negócio para tratar as dinâmicas do vínculo acadêmico, sendo esta tarefa atribuída para um microsserviço específico, que poderá ser reutilizado pelas demais aplicações.

Um aspecto bastante interessante relacionado aos microsserviços está no fato de que cada um dos sistemas a seguir pode ser implementado em uma linguagem de programação diferente. O microsserviço de Estudantes, por exemplo, pode ser implementado em Python. O sistema da biblioteca em Java. O sistema do Restaurante Universitário em TypeScript. O sistema de votação pode ser implementado em Perl.

Ao mesmo tempo em que essa flexibilidade é vantajosa, por possibilitar a comunicação entre vários sistemas distintos, sua adoção deve ser cautelosa. A diversidade de plataformas tecnológicas pode dificultar a manutenção e evolução dos sistemas a longo prazo, pois a equipe precisará dominar várias linguagens e tecnologias diferentes. Num contexto em que há grande rotatividade, isto pode ser bastante problemático.

A seguir, veremos como possibilitar a comunicação entre esses diversos microsserviços.