FTP que se foi. Downloads que vamos ter.

A Internet, como conhecemos no passado e que foi a pedra fundamental do que temos hoje, não existe mais. =/

Vejo uns focos de resistência aqui e ali (quero acreditar que faço parte deles), mas... Mais cedo ou mais tarde, todos abandonam o barco de um jeito ou de outro, e cabe àqueles que ficaram dar continuidade (ou não).

O povo deve estar mais careca que eu =P de saber que tô desenvolvendo, nas horas vagas, uma tal de Confederação de Micro Serviços Retrô. O principal (pelo menos por enquanto) serviço é uma Search Engine para repositórios de arquivos (FTP principalmente, mas tem alguns em HTTP). E o conhecimento que eu obtive analisando diversos repositórios para construir cada Adapter para internalizar seus dados não me deixou feliz.

Com raras e honrosas exceções, os atuais mantenedores NÃO SABEM o que estão fazendo. Os melhores tentam não estragar nada, mas outros simplesmente rendem o serviço beirando o inusável. (sigh)

Um exemplo segue:

As Bibliotecas Digitais por excelência na Internet são os servidores FTP. Eles foram feitos pra isso: armazenar e servir arquivos, e o arquivo ainda é a principal (se não a única) mídia efetiva no mundo dos computadores e, por tabela, no mundo da Internet.

Existem outras formas de se servir arquivos? ô se tem. Mas quem tentou servir arquivos por HTTP sabe do tremendo trampo que dá manter a coisa escalável - ao mesmo tempo em que o FTP já tinha resolvido, há décadas, quase todos estes problemas!

É um protocolo "arcaico"? O motor à explosão também o é, e nem vou comentar sobre a roda. Não é porque é velho que deixou de ser útil, e não é porque é novo que é melhor! Se você não precisa de streaming, existe uma chance enorme de que o FTP, quando decentemente configurado, seja a melhor opção para você.

Uma reclamação recorrente que vejo nos fóruns dos atuais mantenedores de alguns repositórios é a largura de banda. Lógico que servir arquivos gasta largura de banda, e uma das formas que a geração anterior tinha para mitigar este problema eram os mirrors: "clones" do repositório oficial cuja função era fornecer alternativas para o download do arquivo. Você dá acesso privilegiado para os mirrors, acesso reduzido para o resto do povo, e publicava uma lista dos mirrors oficiais e o povo que se virasse.

Esta solução, no entanto, tinha um problema: a necessidade de se sincronizar os dados entre os repositórios para manter a consistência.

Profissionais competentes já pensam logo em RSYNC, e com razão.

Outros simplesmente ficam reclamando da largura de banda, impõem restrições e ofuscam endereços para "se proteger de leechers" - como se os dados sendo protegidos pertencessem à eles (simplesmente não é o caso na maioria das vezes).

Criar dificuldades para vender facilidades.

Mas os inteligentes vieram com uma alternativa mais barata: o ALLFILES.

Sempre que há uma alteração no repositório (arquivo que entra, arquivo que sai, arquivo atualizado), um processo noturno gera o ALLFILES (ou 00_INDEX.txt, ou ls-LR) com uma listagem de todos os arquivos do repositório. Alguns, mais sofisticados, usam este arquivo para fornecer uma descrição detalhada dos arquivos servidos - excelente para buscas.

Isso deixa tudo muito simples! Um mirror só precisa checar a data/hora da última alteração do arquivo (e, se for paranóico como eu, também o tamanho) e se for igual, não há nada o que fazer. Mas se for diferente, uma mera comparação com a cópia anterior é suficiente para se saber quais são as novidades e, então, tomar os passos necessários para atualizar sua cópia local.

Isso economiza recursos de todos os lados, porque não é necessário atravessar o repositório inteiro checando arquivo por arquivo!!

Então, ao invés de implantar QoS no seu servidor HTTPD, se preocupar com Load Balance, manter um banco de dados cuja única função é mascarar o endereço real do arquivo a ser servido (pra não falar nas constantes atualizações das páginas HTML quando muda o identificador do arquivo), gastar tempo e dinheiro com CAPTCHAs... E então se engajar numa batalha perdida contra Web Crawlers e serviços anti-capchas... Que tal voltarmos um pouco às nossas raízes?

É mais barato. É mais simples. É mais democrático. É mais Internet.

Pensem nisso.

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