Microserviços e Programação Estruturada - o tempo passa, mas não muda

Essa é só pros velhinhos. :-)

A long time ago, in a galaxy far, far away... A Programação Estruturada começava a pegar tração no Mercado (finalmente!). Estou falando de uma época que começou mais ou menos em 1978 e durou toda a década de 80.

Nesta época, ninguém sabia direito o que era esta tal de Programação Estruturada, muito menos os Gerentes que passaram a exigir que seus desenvolvedores passassem a aplicar isso do dia para a noite. Mas os artigos das Revistas Especializadas (que na época cumpriam o papel da Internet de hoje: propagar FUDs, tendências do momento e outras bobagens patrocinadas) explicavam tudo "direitinho", como segue:

Regras para Programação Estruturada

1. Não usar GOTO
2. Usar Procedures e Functions
3. Cada Procedure e Function deve ter até 15 ou 20 linhas
4. Declarar as variáveis antes de usá-las.

E então o que mais se via era programador pegando aquela maçaroca de código aestruturado (porque nem desestruturado aquilo era =D ), divindo o código em 20 linhas, colocando cada bloco de 20 linhas numa procedure (todas elas chamadas de proc1, proc2, proc3, etc...) e no corpo do programa, chamando as procedures em sequência. :-D

Ah, sim... E declarando todas as variáveis globais.

Hoje em dia isso parece piada, mas isso era realmente o cotidiano no Mercado por esta época. A Gerência simplesmente jogava o conceito na mesa e dizia "agora todo mundo faz assim" e dane-se.

O tempo passou, o Paradigma da Orientação à Objetos chegou e... Aconteceu a mesma coisa. Até hoje tem gente que se recusa terminantemente à usar OOP onde este paradigma é o mais indicado (e, diga-se de passagem, é a maioria dos sistemas de médio e grande porte).

E o tempo passou de novo, e nada mudou outra vez. É assim até hoje. :-)

A Nova Moda do momento são os Microservices. A coisa está tão elástica que, ao contrário da Programação Estruturada, não existe ainda nem mesmo um consenso sobre o que caracterizaria um Microservice. Mas estão todos embarcando na onda - inclusive eu! :-D

Correndo o risco de me tornar parte do problema, ao invés de resolvê-lo, seguem minhas impressões sobre o assunto:

• Microservice é SOA. Se você não sabe o que é SOA, você não vai aprender o que é Microservice.
• A mentalidade corrente ainda está fortemente amarrada ao paradigma anterior e arcaico, dos grandes Portais de serviços.
• Microservice não é uma interface! Não estamos trocando o HTTP-RPC por outra coisa, não é isso!
• As decisões de Arquitetura ainda estão fundamentadas nos paradigmas Cliente-Servidor clássicos. Usar Redis como repositório de dados de Microservices (substituindo SQL) pode ser um erro tão grande como usar SQL para guardar estes mesmos dados!
• Um Microservice deve ser autocontido. Seu core business deve ser exclusivo, logo não há sentido em compartilhar seu core business usando outra interface que não a sua!
• Se todos os dados do seu Microservice precisam estar compartilhados por outros Microservices, então possivelmente você caiu na armadilha do Nanoservice!
• Segue a filosofia UNIX (cara programa deve fazer apenas uma coisa, e fazer muito bem feito), mas assim como este, é claramente incompreendido e frequentemente ignorado.

Ou, em miúdos, pegar a sua grande aplicação monolítica e sair criando uma camada em cima para "simular" microservices não é exatamente diferente de pegar uma maçaroca de linhas e dividir em procedures de 20 linhas acessando variáveis globais e chamar aquilo de Programação Estruturada! :-)

Microservice é um paradigma de Arquitetura, não de Implementação. Óbvio que a implementação segue a Arquitetura, mas deveria ser óbvio que o inverso não é verdade: não é porque você implementou um front-end de "Microserviços" que a sua arquitetura deixou de ser monolítica.

Este paradigma ainda é RiP (Research In Progress). Se você achou este artigo relevante, possivelmente vai ser interessar pelo meu Test Bed, a Confederação de Micro Serviços Retrô.  E sim, usei "Micro Serviços" e não "Microserviços" de propósito - não tenho tanta certeza de que estou de fato implementando Microservices, nem que vou ficar preso neste paradigma com o decorrer do tempo.  O objetivo da ferramenta é prover serviços para a comunidade de retrocomputação, se eles serão microservices ou não, é problema meu! :-)