Por que as redes são importantes para a arquitetura de aplicativos

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Tenho escrito bastante sobre a relação, às vezes conturbada, entre as arquiteturas de aplicativos e a rede. Em sua maioria, esses textos se concentraram em como as mudanças na arquitetura dos aplicativos afetam a rede e os serviços de aplicativos usados para proporcionar velocidade, escalabilidade e segurançaHoje, porém, vamos inverter essa relação e analisar como a rede exerce um impacto bastante significativo sobre os aplicativos e, consequentemente, sobre a inovação.

Lembrei-me disso por causa de uma publicação recente no High Scalability, na qual o autor explica por que a rede é importante e como essa evolução ocorreu — chegando aos dias de hoje, com a computação sem servidor, e por que é possível realmente imaginar um mundo em que a Internet seja, de fato, o computador. É um texto longo, mas vale a pena, e recomendo que você reserve um tempo para lê-lo. Vou resumi-lo aqui, mas deixarei de abordar muitos pontos interessantes que você encontrará no artigo original.

Na época do acesso discado à Internet, os sites eram compostos principalmente de texto, talvez com uma ou duas imagens (de baixa qualidade). Se você quisesse algo interativo, abria o gopher ou o telnet e usava um terminal baseado em texto. Simplesmente não havia como a conexão de última milha via acesso discado comportar algo mais complexo.

À medida que a velocidade da conexão discada aumentou, até ser substituída pelas primeiras ofertas de “banda larga”, os aplicativos passaram a exibir mais imagens e a se dividir em várias páginas. Isso porque a rede já era rápida o suficiente para transmitir essas informações sem que o usuário ficasse entediado e fosse jogar Diablo. Esse padrão continuou até que a escalabilidade se tornou um problema. Já não era mais a velocidade que limitava os sites, mas a escala. De repente, o balanceamento de carga virou uma mina de ouro.

As velocidades de rede continuaram aumentando — e não apenas na última milha, mas também dentro dos data centers e ao longo do backbone da Internet. A Web 2.0 apresentou ao mundo o conceito de aplicativos web, trazendo sites responsivos e interativos que aproveitavam a capacidade da rede de garantir a escalabilidade e a velocidade dos dados trocados.

As arquiteturas de aplicações mudaram devido aos avanços das redes. Sem velocidade e escalabilidade, o mundo da Web 2.0 jamais teria surgido, pois simplesmente não teria atendido à necessidade de rapidez inerente a todo consumidor. No entanto, esses aplicativos ainda seguiam um modelo tradicional de três camadas, composto por uma camada de apresentação, uma camada lógica e uma camada de dados. Eles estavam apenas distribuídos pela Internet.

Pouco depois, a SOA (Arquitetura Orientada a Serviços, para vocês, jovenzinhos — e saiam do meu gramado, por sinal) virou a grande sensação. Combinando padrões (SOAP, XML) e aproveitando conceitos já existentes de orientação a serviços, os “serviços web” dominaram o cenário. Os serviços web e a SOA introduziram o conceito de decompor aplicações em serviços individuais. Se isso parece familiar, é porque deveria: hoje chamamos esse conceito de “microsserviços”.

O problema dos serviços web era que o XML é um formato pesado, e analisá-lo no cliente (ou no servidor) levava tempo. Como o XML estava no cerne da SOA, isso significava que cada serviço consumia uma quantidade X de tempo para ser transmitido pela rede e processado. Como há um tempo limitado disponível para processar uma solicitação de um consumidor, isso necessariamente restringia o número de serviços em que uma aplicação poderia ser razoavelmente decomposta. Dois ou três serviços era o máximo que se podia esperar alcançar.

Hoje, as redes são mais rápidas e têm maior capacidade de ponta a ponta. As redes de data centers (e da nuvem) são medidas em gigabits por segundo, não em megabits por segundo, e até mesmo as conexões de banda larga deixariam no chinelo as velocidades das primeiras redes corporativas. Isso significa transferências mais rápidas pela rede. Aliados aos incríveis avanços na velocidade de processamento e de E/S (porque a Lei de Moore está certa), esses ganhos permitiram que as aplicações fossem decompostas em dezenas e até centenas de serviços, que podem ser chamados e executados dentro dos parâmetros de resposta esperados. Chamamos esses serviços de microsserviços.

Essas mudanças na rede viabilizaram arquiteturas de aplicações e APIs modernas. Elas estimularam a troca de informações em tempo real de uma forma que jamais teria sido possível no início dos anos 2000. Assim como a tecnologia passou a ser considerada um componente essencial da estratégia de negócios, em vez de desempenhar seu tradicional papel de suporte, a rede é cada vez mais um componente fundamental das aplicações. Ao observarmos a chegada da próxima onda de arquiteturas (a computação sem servidor), veremos que, sem uma camada altamente responsiva e integrada de serviços de rede e de aplicações, capaz de responder quase instantaneamente a eventos de escalabilidade e segurança, esses modelos de computação são inviáveis.

Agora, a questão é menos a velocidade da rede (estamos chegando aos limites da velocidade da luz) e mais a rapidez da rede em responder a eventos como aumentar ou reduzir a escala, interromper um ataque em andamento ou contornar problemas na rede ou na infraestrutura de aplicativos. A próxima geração de redes é definida por software, orientada por software e viabilizada por software. Ela também está migrando para um modelo de escalabilidade que adota uma abordagem just-in-time, exigindo tempos de reação quase instantâneos dos serviços que fornecem acesso, escalabilidade e segurança aos serviços hospedados nesses contêineres.

“A rede”, como costumamos chamá-la, é composta por serviços executados em diversos tipos de software e hardware. A capacidade de “a rede” responder e fornecer serviços em um modelo just-in-time determinará, em parte, o sucesso desses novos modelos de arquitetura de aplicações.

“A rede” nunca foi tão importante quanto é agora.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie