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 EstruturadaE 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
- Não usar GOTO
- Usar Procedures e Functions
- Cada Procedure e Function deve ter até 15 ou 20 linhas
- Declarar as variáveis antes de usá-las.
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.
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! :-)
AS FAR AS I UNDERSTOOD... Microservice é SOA. Foi também a primeira impressão que eu tive sobre a similaridade do paradigma Microservice com o paradigma SOA. ( pattern command_and_control) onde há uma coerência no formato da mensagem sem haver a necessidade de um contrato ( fracamente acoplado) porém com um "quê" de EDA ( pattern publish_and_subscribe).
ResponderExcluirExato!
ExcluirDigamos que é o SOA, revisitado por alguém que curte REST. :-)
ESSE NEGÓCIO DE METHODS COM NO MÁXIMO 30 LINHAS... é também um paradigma da "Best Pratice" em Modern C++. É uma tendência por granularidade e modularidade de funcionalidades e sua reusabilidade por combinações.
ResponderExcluirSim, mas é uma heurística pra ser usada com critério, não uma regra pra ser aplicada cegamente como se fez um bocado pela década de 80. Eu tava começando ainda, e lá por 88 ou 89 eu cheguei a pegar código dessa época. Com esses problemas! =D
ExcluirGostei do visual retrô (meio barata elétrica) do seu site! http://service.retro.lisias.net/
ResponderExcluirDá uma fuçada também em:
Excluirhttp://www.lisias.net
http://sandbox.lisias.net
http://home.lisias.net:8080
(este último é um HTTP server que fiz em BASH rodando no Raspberry!!)
Lisias: estou com uma VM Solaris 11 e também um Linux 7. Posso "experimentar" esta ferramenta em qualquer um dor dois ou você sugere que eu use uma das minhas RASPBERRY PI para fazer a brincadeira? Abraço meu caro amigo!
ResponderExcluirA idéia é prover serviços até no microndas da cozinha, se o treco rodar Python! :-)
ExcluirPra brincar, do jeito que tá tá valendo. Mas em algumas semanas vai sair funcionalidades novas na "Confederação", e você teria que atualizar tudo.
Se você quer algo no estilo "fire-and-forget", é melhor esperar. Mas se você quer fuçar no que eu fiz (e como), a hora é agora! :-)