Microsserviços? Esqueças as API's

Pois é, você não leu errado. Esqueça as API's. Mas, respire! Vou explicar melhor...

Frequentemente vejo empresas entrando na modinha de criar microsserviços para tudo, mesmo quando o negócio não precisa, apenas para satisfazer o ego dos developers ou parecer uma empresa descolada e ficar nos trendings. Como já disse em outro artigo por aqui, você precisa mesmo? Realmente não precisa, quase nunca.

No entanto, partindo do pressuposto de que realmente você tenha essa necessidade, sou capaz de apostar que a comunicação definida entre todos os microsserviços, é através das API's, certo? Pois é, você está fazendo isso errado! Quase sempre.

Microservice is not an API!

Erroneamente vejo pessoas associando um microsserviço à uma API, definindo os contextos da aplicação em funcionalidades comuns à uma API. E isso está errado! Absolutamente. Um MS é muito mais do que uma API e não é obrigatóriamente uma API! Ele pode ser simplesmente um executável plugado a um canal de comunicação TCP que processa algo e emite uma resposta, sem nenhum tipo de comunicação HTTP, sem nenhum tipo de conectividade com banco de dados ou algo do gênero. E sim, pode ser.

How HTTP works

Entender o funcionamento do protocolo HTTP é fundamental para compreender como abordarei essa questão nos próximos parágrafos. Para isso, se você ainda não sabe, recomendo a leitura desse artigo. Observe que é não é uma tarefa simplória realizar a comunicação REST, que é pesada, onerosa e pasmem - uma das menos performáticas. Dito isso, se você está adotando a estratégia de microsserviços, provavelmente está buscando performance, né? Então pare de usar API's para comunicar-se entre seus microsserviços.

Desmistificando o padrão RESTful

Bem, eu poderia escrever aqui minha própria opinião sobre o assunto, mas certamente não conseguiria superar a precisão do Elemar neste artigo aqui. https://www.eximiaco.tech/pt/2019/09/13/origem-e-significado-de-rest-e-restful/

É fato que o REST pode trafegar praticamente qualquer coisa no payload, mas noto que majoritariamente as empresas adotaram o JSON como padrão de dados. Considerando que a comunicação entre processos/máquinas não precisa ser verbosa, o JSON definitivamente não é a melhor opção para trabalhos de alta performance.

Forget JSON, adopt gRPC

O JSON é bonitinho, mas ordinário. Em muitos casos na comunicação entre microservices, não precisamos da verbosidade do JSON, precisamos de performance. E nesse caso, há protocolos que desempenham essa função com melhores resultados, dentre eles o gRPC.

Um framework de comunicação distribuída, open-source, que pode ser executado em praticamente todos ambientes. Diferentemente do REST (baseado em HTTP/1), que é um request-response, o gRPC (baseado em HTTP/2) permite ainda streamming de dados de maneira bi-direcional, habilitando assim os microsserviços a "se falarem em realtime", de fato.

É óbvio que não é uma regra, tão pouco uma recomendação irrestrita de "substitua o JSON ou REST por gRPC", mas é um alerta de que na maioria das vezes o REST não é a melhor escolha.

Para fechar...

Além da já citada falta de necessidade para arquiteturar projetos de microservices, vejo empresas fazendo isso de maneira equivocada, com padrões e modelos mentais da época dos (quase) finados ESB. Arquiteturas que visem centralizar as requisições em um ponto central, ou em um orquestrador centralizado, vão de encontro aos propósitos de haver uma arquitetura distribuída, onde serviços se comunicam com serviços, o mais livremente possível.

Quando projetos envolvendo microsserviços são arquitetados, quase sempre são pensados como se API fossem, se comunicando (quase) sempre via RESTful, esquecendo de considerar protocolos de comunicação mais performáticos.

Para comunicação entre serviços/microsserviços, dê preferencia a um protocolo de mais baixo nível, menos verboso e que te trará mais performance e menor consumo de processamento, como o gRPC. Já para comunicar-se externamente (com o consumer), o melhor caminho ainda é o HTTPs.

p.s.: API é uma das maneiras de se expor métodos/funções de um ou mais microsserviços, e não é necessáriamente a forma como os microsserviços devem se comunicar internamente.

Mas deixe seus comentários aí. Como suas aplicações estão arquitetadas hoje?

abraço,

Lucas Massena