Aplicações MONOLÍTICAS, CLIENT/SERVER e MICROSERVIÇOS: Uma Breve História do Tempo

Há muito tempo atrás, na época do bit lascado e dos CPDs frios como geladeiras e imaculados como uma sala de cirurgia, surgiram as aplicações MONOLÍTICAS!

Em COBOL, NATURAL e outras linguagens menos conhecidas e mais esotéricas, o programador escrevia sua aplicação, que interagia com o usuário e conectava diretamente no banco de dados.

Esgueirando-se pela selva de pedra, pequenos animais admiravam a majestade dos grandes sistemas, invejando sua capacidade de processamento.

Para não ficarem para trás, desenvolveram a capacidade de se comunicar em rede – e surgiram novos animais: dBase, Clipper, FoxPro.

Ainda eram aplicações monolíticas, mas rodavam em PCs, onde alguns executavam a aplicação e um centralizador ficava com o banco de dados.

Os PCs evoluíram, criaram a GUI (vulgo interface gráfica) e evoluíram para novos sabores: Delphi.

Mas ainda monolíticas, cada PC onde era instalada a aplicação tinha de ter instalado também o DRIVER de comunicação com o banco de dados.

Atualizações de versão eram um pesadelo; orquestrar a parada de todos os usuários para que pegassem a versão mais atualizada da aplicação e garantir que apenas esta versão fosse utilizada por todos.

Em uma nova evolução, idealizaram a comunicação entre aplicações, onde uma seria responsável pela interação com o usuário (o cliente) e outra aplicação seria responsável pela comunicação com o banco de dados (o servidor): nascia o CLIENT/SERVER!

Os nomes CORBA, DCOM, ObjectBroker, MIDAS passaram a fazer parte do dia a dia dos desenvolvedores – e dos seus mais íntimos pesadelos!

Mas o mundo continuava evoluindo até que, em 94, um novo animal começou a andar por estes pastos: A INTERNET!

Ainda na infância, recém-saída dos laboratórios das universidades e aos poucos caminhando para se tornar uma plataforma comercial, era um brinquedo interessante – conteúdo institucional estático alimentado por eventuais conteúdos dinâmicos gerados via CGI (nada a ver com gráficos, mas com a Common Gateway Interface).

Mas alguns desenvolvedores perceberam que a internet poderia ser útil para a troca de informações, com sua capacidade de conectar redes distintas e a longa distância – faltava um protocolo comum: assim surgiu o SOAP e o XML!

O SOAP implementava a ideia de "mensagem", onde o envio de um dado poderia ser feito diretamente entre aplicações de diferentes plataformas e locais físicos, tudo via a novidade: WEB!

Mas o SOAP precisava de um formato aberto para que a mensagem pudesse ser envelopada e entendida facilmente: o XML!

O XML, apesar de algo confuso e denso, permitia que aplicações de diferentes desenvolvedores trocassem informações, bastando saber os campos e dados que tinham de ser enviados (independentemente da plataforma de origem e de destino) – era uma verdadeira revolução!

Mas, para tentar colocar ordem na casa e tentar facilitar a documentação das estruturas XML, surgiu o WSDL (Web Services Description Language), um descritivo que permitia aos desenvolvedores saber de antemão como o destino esperava a informação.

Apesar dos sistemas ainda serem, na sua maioria, monolíticos (localmente) e cliente-servidor (localmente), a semente da ideia de sistemas que pudessem ser separados geograficamente e ligados pela internet (web) já estava lançada.

A complexidade do SOAP e do WSDL, com suas inúmeras especificações e a verbosidade do XML, começou a mostrar suas desvantagens. A internet, agora uma adolescente irrequieta, exigia agilidade e leveza. Nesse cenário, um novo protocolo despontou, minimalista e elegante: o REST (Representational State Transfer).

Baseado no protocolo HTTP, já onipresente e bem compreendido, o REST utilizava verbos HTTP (GET, POST, PUT, DELETE) para interagir com recursos identificados por URIs. A troca de informações, antes presa ao rígido XML, ganhou flexibilidade com o JSON (JavaScript Object Notation), um formato leve, legível e de fácil manipulação.

A combinação REST e JSON simplificou drasticamente o desenvolvimento e a integração de sistemas. A necessidade de descrever detalhadamente cada serviço com WSDL tornou-se obsoleta; a própria URI e os verbos HTTP já indicavam a funcionalidade. Essa simplicidade impulsionou a criação de APIs (Application Programming Interfaces) RESTful, interfaces de acesso a funcionalidades de um sistema, expostas na web e prontas para serem consumidas por outras aplicações.

A popularização das APIs RESTful e a crescente demanda por escalabilidade e flexibilidade evoluíram para um novo animal nas pastagens: os microsserviços.

Em vez de gigantes monolíticos, os sistemas podem ser compostos por pequenos serviços independentes, cada um responsável por uma funcionalidade específica e comunicando-se entre si através de APIs RESTful.

Essa arquitetura permitiu o desenvolvimento e a implantação de cada microsserviço de forma independente, utilizando diferentes tecnologias e linguagens de programação, sem afetar os demais.

Isso matou os sistemas monolíticos? Não – mesmo hoje em dia, quando um desenvolvedor cria uma aplicação que se conecta diretamente com o banco de dados, ainda é, grosso modo, uma aplicação idêntica ao COBOL dos CPDs de décadas atrás.

Usar uma API já garante ser microsserviço? Não – mesmo hoje em dia, quando um desenvolvedor cria uma aplicação que se conecta a outra (ainda que via API), mas que esta final detém todas as regras de negócio e a comunicação com o banco de dados, acaba sendo uma aplicação cliente-servidor, só que usando API e AJAX.

Microsserviços implicam em: aplicações diferentes, no melhor estilo "caixa-preta", cada uma especializada – podendo ter seu próprio banco de dados e linguagem de programação.

Toda aplicação irá se beneficiar de microsserviços? Ainda é um pouco cedo para saber – afinal, desenvolver em microsserviços tem impactos e complexidades – que podem ser bem resolvidas por sistemas mais simples, monolíticos ou cliente/servidor.

Vamos ver que novos animais a evolução trará para estas paragens.