Por que as redes são importantes para a arquitetura de aplicativos
Tenho escrito muito sobre o tema da relação, às vezes tumultuada, entre arquiteturas de aplicativos e a rede. Na maior parte, eles se concentraram em como as mudanças na arquitetura do aplicativo impactam a rede e os serviços do aplicativo usados para fornecer velocidade, escala e segurança . Hoje, no entanto, vamos reverter esse relacionamento e analisar como a rede tem um impacto bastante significativo nos aplicativos e, por sua vez, na inovação.
Fui lembrado disso por uma postagem recente sobre Alta Escalabilidade, na qual seu autor ilustra por que a rede é importante e como a evolução ocorreu — até hoje com o serverless e por que é possível realmente considerar um mundo no qual a Internet é efetivamente o computador. É longo, mas é uma boa leitura, e recomendo que você reserve um tempo para lê-lo. Vou resumir aqui, mas há muita coisa que não abordei e que você achará interessante no artigo de origem.
Na época do acesso discado à Internet, os sites eram compostos principalmente de texto, com talvez uma ou duas imagens (de baixa qualidade). Se você quisesse algo interativo, iniciava o gopher ou o telnet e usava um terminal baseado em texto. Simplesmente não havia como a conexão discada de última milha proporcionar algo mais complexo.
À medida que a velocidade da conexão discada aumentava, eventualmente sendo substituída pelas primeiras ofertas de “banda larga”, os aplicativos começaram a exibir mais imagens e a se dividir em várias páginas. Porque a rede era rápida o suficiente para transmitir essas informações sem que o consumidor ficasse entediado e saísse correndo para jogar Diablo. Esse padrão continuou até que a escala se tornou um problema. Não era mais a velocidade que estava impedindo o avanço dos sites, mas sim a escala. O balanceamento de carga de repente se tornou uma mina de ouro.
As velocidades da rede continuaram a aumentar – e não apenas na última milha, mas dentro do data center e ao longo da espinha dorsal da Internet. A Web 2.0 introduziu a noção de aplicativos da web ao mundo, dando-nos sites interativos e responsivos que aproveitavam a capacidade da rede de garantir a escala e a velocidade dos dados trocados.
As arquiteturas de aplicativos mudaram devido aos avanços da rede. Sem velocidade e escala, o mundo da Web 2.0 nunca teria surgido, porque simplesmente não teria satisfeito a necessidade de velocidade que é inata em todo consumidor. Mas esses aplicativos ainda eram de um modelo tradicional de três camadas, compreendendo uma camada de apresentação, uma camada lógica e a camada de dados. Eles foram simplesmente distribuídos pela Internet.
Logo depois, SOA (Arquiteturas Orientadas a Serviços, para vocês, jovens – saiam do meu gramado, a propósito) estava na moda. Usando uma combinação de padrões (SOAP, XML) e desenvolvendo conceitos existentes orientados a serviços, os “serviços web” assumiram o controle. Os serviços web e SOA introduziram o conceito de decomposição de aplicativos em serviços individuais. Se isso lhe parece familiar, é porque deveria, porque hoje chamamos esse conceito de “microsserviços”.
O problema dos serviços web era que o XML era um formato robusto e analisá-lo no cliente (ou servidor) levava tempo. Como o XML estava no centro do SOA, isso significava que cada serviço consumia X quantidade de tempo para ser trocado pela rede e processado. Como há um tempo limitado disponível para processar uma solicitação de um consumidor, isso necessariamente limita o número de serviços nos quais um aplicativo pode ser razoavelmente decomposto. Dois ou três serviços eram o máximo que se podia esperar alcançar.
Hoje, as redes são mais rápidas e completas de ponta a ponta. Redes de data center (e nuvem) são medidas em gigabits por segundo, não megabits por segundo, e até mesmo conexões de banda larga fariam as primeiras velocidades de rede corporativa passarem vergonha. Isso significa transferências mais rápidas pela rede. Combinado com aumentos incríveis na velocidade de computação e E/S (porque a Lei de Moore está certa), os aplicativos foram capazes de se decompor em dezenas e até centenas de serviços que podem ser chamados e executados dentro dos parâmetros de resposta esperados. Nós chamamos isso de microsserviços.
Essas mudanças na rede possibilitaram arquiteturas de aplicativos e APIs modernas. É incentivada a troca de informações em tempo real de uma forma que nunca teria sido possível no início do século XX. Da mesma forma que a tecnologia agora é considerada um componente essencial da estratégia de negócios, em vez de assumir seu papel tradicionalmente de suporte, a rede é cada vez mais um componente essencial dos aplicativos. À medida que observamos a próxima onda de arquiteturas chegando (sem servidor), notamos que, sem uma rede altamente responsiva e integrada e uma camada de serviço de aplicativo que forneça resposta quase instantânea a eventos de escala e segurança, esses modelos de computação são inatingíveis.
Agora, o mais importante é a velocidade da rede (estamos atingindo os limites da velocidade da luz) e mais a velocidade da rede para responder a eventos como aumento e redução de escala, interromper um ataque em andamento ou contornar problemas na rede ou na infraestrutura do aplicativo. A próxima geração de redes é definida por software, orientada por software e habilitada por software. Ele também está migrando para um modelo de escalabilidade que adota uma abordagem just-in-time, exigindo velocidades de reação quase instantâneas dos serviços que fornecem acesso, escala e segurança aos serviços hospedados nesses contêineres.
“A rede”, como costumamos chamá-la, é composta de serviços que residem em uma variedade de software e hardware . A capacidade da “rede” de responder e fornecer serviços em um modelo just-in-time determinará, em parte, o sucesso desses modelos de arquitetura de aplicativos emergentes.
“A rede” nunca foi tão importante quanto agora.