quarta-feira, 4 de janeiro de 2017

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! :-)

8 comentários:

  1. 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).

    ResponderExcluir
    Respostas
    1. Exato!

      Digamos que é o SOA, revisitado por alguém que curte REST. :-)

      Excluir
  2. 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.

    ResponderExcluir
    Respostas
    1. Sim, 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

      Excluir
  3. Gostei do visual retrô (meio barata elétrica) do seu site! http://service.retro.lisias.net/

    ResponderExcluir
    Respostas
    1. Dá uma fuçada também em:

      http://www.lisias.net
      http://sandbox.lisias.net
      http://home.lisias.net:8080

      (este último é um HTTP server que fiz em BASH rodando no Raspberry!!)

      Excluir
  4. 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!

    ResponderExcluir
    Respostas
    1. A idéia é prover serviços até no microndas da cozinha, se o treco rodar Python! :-)

      Pra 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! :-)

      Excluir

(c)2005 a 2016 por Lisias Toledo.
Reproduções parciais autorizadas somente com menção da fonte e com fins não comerciais.
Qualquer outra utilização, comercial ou não, somente com autorização expressa do autor.