C10K e Open Web: moldando o futuro das aplicações

Você deve estar se perguntando o porquê desse “rebuliço” em torno do Node.js e do MEAN stack, não? Por que essa “onda” de HTML 5, Angular.js, REST etc? O que deu nas pessoas para ignorarem soluções consagradas, como: Java EE e .NET, em prol de um monte de porcarias, criadas por “garotos da Internet”.

Tudo isso está relacionado com uma nova tendência de aplicações, chamada: Open Web (web aberta).

E uma das inovações tecnológicas que habilitam a Open Web, na parte servidora, é o advento de “Lightweight web servers” (http://slodive.com/web-development/lightweight-alternatives-to-apache-and-iis-web-servers/) , criados para resolver o “Problema C10K” (http://en.wikipedia.org/wiki/C10k_problem). O Node.js (http://nodejs.org/) é apenas uma dessas inovações.

É preciso entender o contexto onde todas essas novidades estão acontecendo, e por que até os gigantes da indústria estão sendo incomodados com isso.

Open Web

É uma nova visão do desenvolvimento de aplicações Web, que foi dominado muito tempo por soluções proprietárias, que descaracterizaram e “encapsularam” as tecnologias e protocolos básicos, como: HTML, CSS, Javascript e HTTP.

Desde o princípio, a Web sempre foi aberta. No início (acreditem, eu vivi isso!) nós desenvolvíamos diretamente em HTML, CSS, Javascript e CGI (perl, C etc). Eram padrões abertos e gratuitos. Porém, não demorou muito tempo para que os fornecedores de soluções proprietárias “bagunçassem o coreto”, lançando produtos que, devido à sua facilidade maior, conquistavam os desenvolvedores, provocando o surgimento de aplicações Web baseadas neles.

Mas não são só as ferramentas, que provocaram o “fechamento” da Web. Padrões fechados, como aqueles criados por entidades privadas, cujo “download” é pago, também contribuíram para esse problema.

Segundo a Wikipedia (http://en.wikipedia.org/wiki/Open_Web), há um excelente artigo de Tantek Çelik (http://tantek.com/2010/281/b1/what-is-the-open-web), que descreve bem os requisitos para termos uma Web aberta:

1. Deve ser possível publicar conteúdo e aplicações na Web, baseado em padrões abertos, como: HTML, CSS, Javascript, JPEG, PNG, Ogg etc;
2. Deve ser possível codificar e implementar os padrões, dos quais o conteúdo e as aplicações dependem. Todos os padrões devem ser abertos, gratuitos e livres de patentes, como a maioria dos padrões W3C e IETF. Padrões que requerem pagamento de taxa para download, ou que estejam sob o domínio de patentes, devem ser evitados;
3. Deve ser possível acessar e usar qualquer conteúdo ou aplicação, independentemente de dispositivo ou de provedor de serviço. Países e provedores que censuram ou que alteram pacotes, violam este requisito;

Para permitir a existência da Open Web, foi pensado um conjunto de tecnologias e padrões aderentes ao conceito, reunidos sob o título “Open Web Platform” (http://www.w3.org/wiki/Open_Web_Platform) ou Plataforma Web Aberta. Entre vários outros, temos:

• HTML 5;
• DOM;
• CSS;
• SVG;
• MathML;
• Javascript (ECMAScript);
• WebSockets, WebWorkers, XMLHttpRequest, Canvas etc;

Apesar de não fazerem parte da Open Web Platform, algumas tecnologias e padrões vêm sendo associados a ela, devido a sua leveza, facilidade de uso e independência de patentes e licenciamento: REST (http://en.wikipedia.org/wiki/Representational_state_transfer) e JSON (http://www.json.org/).

O uso de SOAP / XML se tornou tão “embebido” em frameworks proprietários ou fechados, que sua complexidade aumentou muito, passando a exigir ferramentas específicas para uso. É muito raro vermos desenvolvimento diretamente em HTTP e Javascript usando essas tecnologias.

Essa tendência de Open Web está fazendo com que tecnologias e ferramentas baseadas em “templates” para geração automática de código (HTML, CSS e Javascript), sejam substituídas pelo desenvolvimento direto com as tecnologias e padrões da Open Web. Exemplos de tecnologias server-side template são: Java EE / JSF e Microsoft .NET MVC (ou Web Controls).

O problema C10K

Paralelamente ao ressurgimento da Open Web, outro conceito passou a ganhar peso entre os desenvolvedores de aplicações: Lightweight Web Servers (http://slodive.com/web-development/lightweight-alternatives-to-apache-and-iis-web-servers/). Segundo o excelente artigo de Nisha Patel (SloDive.com), as principais características desses servidores são:

• Alto nível de escalabilidade;
• Estabilidade;
• Configuração simples e fácil;
• Leveza: Baixa carga de CPU, pouco uso de recursos e baixo consumo de memória;

Eles surgiram para tentar resolver o problema que ficou conhecido como “C10K” (http://en.wikipedia.org/wiki/C10k_problem), ou seja, como atender a milhares de conexões concorrentes, com baixo consumo de recursos e bom desempenho (C10K significa 10.000 conexões concorrentes). O excelente artigo de Dan Kegel (http://www.webcitation.org/6ICibHuyd) explica bem a preocupação dos pesquisadores do “Problema C10K”, e lista várias estratégias para otimizar o uso de recursos de servidores web.

O aumento de complexidade dos servidores Web, “encapsulados” pelos frameworks corporativos, provocou uma queda de desempenho e/ou aumento de consumo de recursos. Hoje, um “Container” moderno possui requisitos e consumo de harware bastante altos, resultando em uso ineficiente dos mesmos.

Isso por que houve uma concentração exagerada de responsabilidades sobre o servidor Web, de modo que ele participasse dos frameworks corporativos monolíticos modernos. Existem várias camadas de software, as quais não estão necessáriamente relacionadas com o servidor Web, as quais o “request” deve ultrapassar até chegar ao script servidor que irá tratá-lo.

Para resolver o problema C10K, algumas estratégias de software servidor e de configuração foram estudadas e comparadas com o método tradicional, de abrir um “Thread” por conexão web (http://www.webcitation.org/6ICibHuyd).

A estratégia dos “Lightweight web servers” modernos incluem alguns tópicos comuns: usar um “loop de eventos” assíncrono para processar os requests em um único “thread”, e usar “non-blocking I/O” para comunicação em rede e acesso aos recursos (arquivos e bancos de dados).

Lightweight web servers

Vários produtos surgiram para resolver o problema C10K, e a Wikipedia (http://en.wikipedia.org/wiki/C10k_problem) tem uma lista bem interessante deles. Os mais comuns são:

• NGIX (http://nginx.org/): Ao invés de abrir múltiplos threads para tratar as conexões, ele usa um sistema de eventos assíncrono para isto;
• lighttpd (http://en.wikipedia.org/wiki/Lighttpd): Da mesma forma que o ngix, usa uma arquitetura assíncrona para tratar os requests. Permite programação em PHP, através de interface FastCGI;
• Jetty (http://www.eclipse.org/jetty/): Um “lightweight web server” que é um container Java EE;
• Node.js (http://nodejs.org/): Uma plataforma de criação de aplicações servidoras baseadas em eventos, com NIO (“non-blocking I/O”), que usa o engine Javascript V8, do Google Chrome;

Arquitetura diluída

Conforme venho defendendo aqui (http://www.obomprogramador.com/search/label/arquitetura%20dilu%C3%ADda), é necessário adotarmos uma nova arquitetura de aplicações, onde as responsabilidades sejam diluídas, evitando a concentração maciça no “Container” Java EE. Para isso, podemos usar qualquer linguagem ou plataforma, desde que usemos “Lightweight web servers” e Open Web Platform.

Conforme eu mesmo já demonstrei, é possível usar Java EE dentro desse contexto, diluindo as responsabilidades, por exemplo:

• Camada de apresentação exclusivamente no Cliente, usando HTML 5, Ajax, REST, CSS e Javascript, evitando o “encapsulamento” provocado por tecnologias server-side template (http://www.obomprogramador.com/2014/03/uma-arquitetura-diluida-camada-de.html);
• Camada de lógica de negócios usando um “Lightweight web server”, o Jetty, com a responsabilidade apenas de instanciar um RESTful web service, que usa JSON como formato de dados (http://www.obomprogramador.com/2014/03/uma-arquitetura-diluida-logica-de.html);
• Camada de persistência baseada em NoSQL, usando o MongoDB, sem o pesado mapeamento O/R do JPA (http://www.obomprogramador.com/2014/03/uma-arquitetura-diluida-persistencia.html);

E depois, mostramos a mesma aplicação substituindo a camada de lógica por uma aplicação Node.js (http://www.obomprogramador.com/2014/03/arquitetura-diluida-limando-o-java-ee.html).

É isso que estou pregando há algum tempo, ou seja, evitar o problema C10K e aderir ao máximo possível à Open Web Platform, evitando concentração em ecossistemas fechados e diluindo as responsabilidades em vários elementos.