Quem N?O olha para os erros do passado, comete os mesmos erros no futuro
Glauco Reis
LinkedIn Top Voice 2024 | Mestre em IA?? | Qiskit Certified Developer ?? | Qiskit Advocate?? | Palestrante??| IBMEr?? | Evangelista?? | Escritor??? | Modernization Expert ???? | Java Dev ?? | Quantum Ambassador at ??
Neste artigo, inusitadamente come?o com uma frase que diz quase tudo a que este artigo se refere. Vou contar uma pequena história (real, n?o é estória) e tentar explicar porque estamos cometendo hoje os mesmos erros do passado. Entendo que as vis?es s?o minhas e também entendo que outros desenvolvedores podem n?o concordar, mas mesmo assim vou expressar minha opini?o neste caso.
Antes da Internet
Antes do advento da Internet, os programas eram todos instaláveis que rodavam em Desktop. Ou seja, rodavam no próprio computador do usuário. Tinha que ser assim, simplesmente porque n?o havia outras formas. Lembre-se de que a internet n?o havia sido inventada. Os processos de instala??o eram custosos. Cada Windows estava configurado de uma forma diferente, tinha DLLs diferentes (lembra do inferno das DLLs?), cada instala??o costumava dar um trabalho significativo para funcionar. Programas como InstallShield e muitos outros foram criados para tentar amenizar a situa??o. Tudo bem, depois de instalado ficava tudo bem, mas a cada nova atualiza??o era necessário ir pessoalmente em cada máquina para fazer o upgrade ou aplicar a corre??o, e torcer para que funcionasse naquela máquina.
Mas ent?o veio a internet
A internet abriu canais de comunica??o ilimitados, e os browsers permitiam acesso a informa??es onde estivessem. Estou falando de uma época onde reinavam Netscape e Mozilla. Podíamos buscar manuais, informa??o e o que mais necessitássemos sem a necessidade do papel. Sem dúvida alguma a internet salvou muitas árvores da poda. N?o se preocupe, o ser humano encontrou outras formas de destruí-las. Somos criativos.
Mas tinha um limitante : as páginas eram estáticas. O que obtínhamos eram páginas HTML. E elas vinham pré-formatadas. N?o dava para gerar conteúdos dinamicos ainda. Gra?as a uma engenhosidade no protocolo HTTP, criamos os CGIs (Common Gateway Interfaces). Os CGIs permitiam que solicitássemos "páginas HTML", e até podíamos passar parametros para estas páginas. Gra?as a uma adapta??o, quando a requisi??o chegava no servidor HTTP ele encontrava "evidências" na URL e redirecionava a requisi??o para um programa, que gerava a página HTML no output (tela). Ele era capturado pelo servidor HTTP e enviado de volta ao usuário do browser.
Desta forma, era como se o usuário estivesse rodando aquele programa remoto na sua máquina, mas sem precisar ter o programa instalado localmente. Ou seja, tínhamos como passar parametros de consulta e tínhamos como obter uma página customizada. Isto é utilizado da MESMA forma até hoje (claro que os mecanismos de gera??o s?o mais sofisticados). O protocolo HTTP com GET, POST, PUT, DELETE s?o usados por todas linguagens. Talvez você n?o veja isto porque está escondido dentro das APIS da linguagem.
Profus?o de linguagens
Neste come?o os CGIs eram escritos em C ou C++. Era a linguagem mais comum, embora n?o acessível para todo mundo. Logo depois usávamos linguagens de script como PERL para fazer esta atividade. Algo parecido com isto aqui (este tutorial aqui me pareceu interessante :
#include <stdio.h>
int main() {
printf( "Content-type: text/html\n\n" );
printf( "<html>\n" );
printf( "\t<head>\n" );
printf( "\t\t<meta charset=\"UTF-8\">\n" );
printf( "\t\t<title>Minha página</title>\n" );
printf( "\t</head>\n");
printf("\t<body>\n" );
printf( "\t\t<h1>Olá mundo!</h1>\n" );
printf( "\t</body>\n");
printf("</html>\n" ); return 0;
}
Funcionava e funciona bem até hoje, mas tem um problema principal : O HTML PRECISA SER GERADO PROGRAMATICAMENTE. E qual o problema disto? N?o dá para editar o HTML com um programa visual. Vários programas que permitiam editar o HTML de forma visual, com drag and drop surgiram nesta época.
A parte boa é que pelo menos dados dinamicos poderiam se misturar com HTML, gerando resultados mais ricos. Poderíamos criar programas de computador que rodassem em browsers, sem ter o ?nus de instalar algo no computador!!!! Isto facilitava demais a administra??o de desktops isolados. Ainda n?o era o ideal.
Uma mudan?a de foco
Mas ent?o surgiu a idéia da mudan?a no foco de como se codificar. Porque n?o inverter a importancia das coisas? Ao invés de colocar o foco no código, colocar o foco na apresenta??o! Como assim? Olha só a diferen?a :
<!DOCTYPE html>
<html>
<body>
<h1>Estamos aprendendo PHP!</h1>
<?php
echo "Vamos prosseguir aprendendo PHP";
?>
</body>
</html>
Olha só!!! Esta é uma legítima página HTML, e que pode ser editada por qualquer editor visual. Tem aquela coisinha do <?php ?> alí, mas o editor visual poderia ignorar tudo que estivesse dentro destas tags. Este foi o caminho adotado pelo PHP, ASP, JSP e muitas outras tecnologias, Mas ainda tinha uma quest?o. Quando invertíamos o foco para visualiza??o, ficava difícil colocar a qualidade nos códigos. Era difícil depurar, instrumentar e testar partes isoladas. Isto era fácil de fazer com ferramentas de desenvolvimento nesta época (de curiosidade trabalhei com o Borland C++, Turbo Pascal e Delphi). ou seja, o ideal seria utilizar os dois de alguma forma.
E porque n?o usarmos os dois ?
E de fato o melhor seríamos utilizar as duas tecnologias, uma que desse o foco no visual (para editarmos com ferramentas visuais poderosas) e outro com foco no programa, para que pudéssemos executar e depurar independente do HTML. Algo assim :
Hoje todas as tecnologias, n?o importa se esteja usando Python, GO, Java, Javascript ou que seja usam uma abordagem parecida com esta (exceto Rich Client, falaremos logo sobre ela). Algum receptor recebe a requisi??o TCP/IP usando o protocolo HTTP, e chama uma tecnologia "programática". Aqui n?o tem HTML nem nada visual. Programas tradicionais na sua linguagem preferida buscam dados em bases relacionais ou n?o, fazem contas, somam e consolidam a informa??o e "guardam" a informa??o em algum lugar. Depois passam o controle para uma tecnologia "visual" que buscam aqueles dados e preenchem "buracos" na tela, utilizando TAGs específicas para isto. N?o atrapalha o designer da página nem o programador da lógica.
Na verdade, com Rich Client, mudamos um pouquinho este desenho :
A idéia do Rich Client foi trazer ao browser poder de processamento, enviando uma página para ele recheada de códigos JavaScript, que interagem com servi?os REST normalmente em algum servidor, recebem os dados e se encarregam de desenhar ou mudar a tela conforme necessário. Isto certamente dá uma melhor percep??o visual ao usuário, tornando os "programas rodando em browsers" mais competitivos. N?o há troca de páginas e o usuário tem a percep??o de que está sempre no mesmo lugar.
Me perdoem os puristas por favor. O que chamamos de Single Page ou Rich Client s?o páginas HTML com um conjunto sofisticado de APIs que rodam em um browser, coisas que comumente ouvimos como Angular, React, Backbone e muitas outras. O que aconteceu é que os computadores ficaram potentes, e deixamos para eles a responsabilidade de receber os dados e formatar da forma como quiserem. Eles mesmos (os browsers) chamam APIs REST, obtém os dados e formatam a tela. Vale salientar que a idéia de Rich Client é bem mais recente do que os CGIs !
Agora come?a o pomo da discórdia.
Vamos voltar lá para os tempos dos CGIs. Tínhamos muitas tecnologias : PHP, C, C++, Java Servlet, DCOM e praticamente qualquer linguagem que quiséssemos. Algumas mais sofisticadas como ASP+.NET e Java forneciam tecnologias "programáticas" e tecnologias "visuais" para que o desenvolvedor fizesse sua escolha. Mas neste momento come?aram a surgir os problemas. Aqueles Dados dinamicos dos desenhos acima. Onde seriam salvos? O protocolo HTTP n?o previa mecanismos sofisticados para salvar os dados que seriam utilizados para rechear as paginas HTML. Pior ainda se n?o fossem Strings. Ainda existiam coisas desejáveis, como termos diferentes "durabilidades" para os dados : alguns dados seriam descartados depois de inseridos nas páginas e outros deveriam durar mais tempo, durante todas as intera??es dos usuários. Também apareceram outras demandas, quando os programas foram ficando mais e mais complexos :
领英推荐
Bem, esta lista é bem grande, e na verdade faria muito sentido termos uma "entidade" que controlasse tudo isto. Algo assim :
Esta entidade de controle foram os servidores de aplica??o. O JEE foi criado com esta finalidade, mas a MicroSoft também seguiu pelo mesmo caminho. Afinal faz sentido. Os servidores evoluíram para termos como configurar as aplica??es sem necessitar compilar os códigos a todo momento. Na verdade para muitas configura??es nem mesmo precisamos parar as aplica??es. Poderíamos aumentar ou reduzir o número de threads em execu??o. Os dados de conex?o com os bancos, como IP, Porta, usuário e senha n?o precisariam mais ficar na aplica??o, e isto foi t?o importante que até um perfil específico de administrador dos servidores surgiu, controlando e configurando como o servidor deveria operar.
Mas ent?o o back to the future
Confesso aqui que muito da culpa deste retrocesso foi causada pelo Java2EE, mais especificamente os Enterprise Java Beans. A vers?o 1.0 foi horrível, você tinha que rodar um programa especial e inserir um monte de parametros que eram gravados em um arquivo n?o portável. A vers?o 1.1 só foi péssima, colocando um XML ao invés de arquivos proprietários, a vers?o 2.0 ficou menos pior, mas os BMPs eram horríveis, e foi e foi e foi. No meio do caminho, críticas e mais críticas. Ent?o que apareceu uma "pessoinha" chamada Rod Johnson. Ele escreveu este livro aqui :
Ele falava abertamente tudo que os desenvolvedores Java reclamavam, e propunha usar uma API no lugar dos EJBs para programa??o de aplica??es Web. Ele foi o criador do Spring, e merece todo mérito por isto. Enquanto o Java2EE era conduzido pelos deuses do Olimpo, que n?o sabiam muito bem o que estavam fazendo, este rapaz trouxe o bom senso para o desenvolvimento Java corporativo. Houve uma migra??o massiva para fora dos EJBs e para o uso de mecanismos mais leves como Spring e Hibernate!
O que come?ou a degenerar foi que, depois do Spring, veio o SpringBoot. Nele a proposta era ir mais além, e nem mesmo do servidor de aplica??es precisávamos! Tínhamos um programa que executava, e tudo era controlado por ele. Gra?as a Deus nos livraríamos dos "malditos" servidores de aplica??o. Só que n?o...
Primeiro que o SpringBoot é um imenso gol de m?o, como do Maradona. Ele n?o omite o servidor de aplica??es. Ele está embutido dentro de um executável.
é como aquelas barracas da 25 de mar?o. Quando você deseja comprar algo, o vendedor monta a mesa, coloca os produtos nela e até coloca um sombreiro para você n?o escolher no Sol. Ou seja, quando você executa o programa ele extrai um Tomcat alí embutido escondido, que faz as vezes de um servidor de aplica??es. Mas existe uma diferen?a fundamental para o passado.
No passado, quando tínhamos servidores de aplica??o (bem, na realidade empresas sérias e preocupadas ainda usam eles) toda configura??o era independente do deploy da aplica??o. O administrador podia aumentar o nível de log, controlar theads e acessos aos bancos sem colocar a m?o na aplica??o. Depois do SpringBoot, como tudo está dentro de um jar executável, você precisa passar de alguma forma por um ciclo de DevOps para reconstruir o executável para que qualquer configura??o seja alterada. Sabe, n?o consigo ver como isto pode ser melhor do que o que tínhamos no passado!
Outro dia estava em um grupo de discuss?o com uma pessoa que criticava o Java porque o argumento dele era : "precisa instalar o Java e um servidor de aplica??es, configurar tudo e só depois colocar sua aplica??o lá para executar". Bem, é uma vis?o imediatista e limitada, e n?o foram consideradas na equa??o os diversos aspectos que precisam ser configurados e controlados, e normalmente n?o s?o preocupa??es de uma aplica??o corporativa.
N?o seria t?o impactante esta abordagem, se o desenvolvedor, que foi responsável pela cria??o e empacotamento da aplica??o, fosse acordado as 3 da manh? para ir lá depurar um programa que está em crise no ambiente produtivo. Mas acontece que, aquela pessoa que perdeu o poder de configurar o servidor, o Administrador do servidor de aplica??es, é quem irá lá tentar resolver os problemas com um programa que é uma caixa soldada sem acesso do lado de fora e com poucas possibilidades de configura??o.
Isto melhorou um pouco com a idéia de Containers, mas eles s?o diferentes dos servidores de aplica??o. A idéia dos containers é abstrair da linguagem de programa??o que está dentro de cada Container.
Nesta imagem, containers vermelhos e containers azuis poderiam representar metaforicamente linguagens de programa??o diferentes. Os vermelhos poderiam ser Java (desejaria que fosse assim) e os azuis poderiam ser Python ou JavaScript. O gerenciador de containers envelopa e cuida de tudo que é COMUM a todas aplica??es. Ciclo de vida, conex?o TCP, balanceamento de carga, mas N?O faz tudo que os servidores faziam :
Ou seja, os containers ajudam nesta nova abordagem, mas n?o s?o o replacement completo para os servidores de aplica??o, que já eram bem evoluidos. Perdemos coisas importantes que tínhamos com os servidores de aplica??o (nem precisa ser Java aqui) em favor de uma pseudo-facilidade em criar programas de forma mais simples, como se um motor de autorama fosse um replacement para um fórmula um.
Enfim é isto, por favor n?o fique com raiva se você odeia Java, mas saiba que tudo foi criado com um propósito e simplesmente esquecemos toda esta história. E agora voltamos ao início do artigo :
Quem N?O olha para os erros do passado, comete os mesmos erros no futuro
Senior Software Engineer @ Ratepay
4 个月De verdade... N?o sei n?o. Nos últimos ~5 anos só usei Spring Boot e AWS . Daí o que a gente faz, em casos como o que você mencionou, é mudar o parametro do container. N?o refazemos build n?o, no máximo reiniciamos a aplica??o. E isso, pra mim, é uma vantagem imensa, porque reiniciar uma aplica??o Spring Boot leva segundos. às vezes, se precisamos mudar algo interno da aplica??o, podemos também usar o Vault da Hashicorp. E daí, mesma coisa, reiniciar a aplica??o. Creio que num futuro próximo, nem isso vamos precisar fazer, porque o health check da aplica??o vai falhar e a AWS vai reiniciar o container por conta própria. O ponto é, eu n?o vejo nada disso sendo feito em JEE. O que me lembro era de usar puppet ou Vagrant ou as duas coisas juntas para administrar servidores de aplica??o, e isso era bem chato. Eu ainda n?o consigo ver um servidor de aplica??o sendo administrado por Docker. Mesmo o JBoss, que ainda é o mais amigável, n?o é recomendado fazer deploy colocando o WAR na pasta. Soa como gambiarra. E o resto.... XML pra cá, XML pra lá. O mundo com Spring Boot é mais simples....
Senior Software Engineer @ Ratepay
4 个月O Spring Boot é compliant com 12 fatores... JEE (salvo algum desconhecimento meu) n?o é. Especialmente quando falamos de configura??es vindas do ambiente - já que , nativamente, o Spring Boot importa configura??es vindas de variáveis de ambiente, o que faz dele ser especialmente amigável com Docker. Eu me lembro de que, uns bons 8 anos atrás, eu já sofria com servidores de aplica??o + Docker. Na época, no caso, era o WebLogic, que n?o detectava WARs numa pasta , tinha que seguir um processo específico para fazer deploy. A forma mais amigável usando Docker era criar um script Python. Gra?as a Deus trabalho com Spring Boot hoje...
LinkedIn Top Voice 2024 | Mestre em IA?? | Qiskit Certified Developer ?? | Qiskit Advocate?? | Palestrante??| IBMEr?? | Evangelista?? | Escritor??? | Modernization Expert ???? | Java Dev ?? | Quantum Ambassador at ??
4 个月Clayton Marques, da nossa conversa, kkkkkkkk