Como a componentização de aplicações afeta o desempenho e a segurança

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

Nos bons e velhos tempos, as empresas podiam contar com o uso de proxies implantados estrategicamente para melhorar o desempenho das aplicações. Isso porque as aplicações tradicionais — monólitos e arquiteturas de três camadas — geralmente utilizavam um único caminho de dados entre o cliente e o servidor.

Em termos simples, havia apenas uma rota para todo o conteúdo — fosse ele estático ou dinâmico, texto ou imagem. Isso significava que um controlador de entrega de aplicações (proxy) podia ficar entre eles e, se fosse a solução adequada, otimizar o desempenho. Isso era — e, aliás, ainda é — frequentemente obtido por meio do ajuste de diversos parâmetros de IP, TCP e até HTTP. Podemos observar o uso desses tipos de técnica na implantação de serviços de aplicação, como cache, compactação e técnicas de aceleração específicas para cada tipo de conteúdo.

Mas os aplicativos modernos já não são autossuficientes. Atualmente, segundo a Sonatype, eles são compostos, em sua maioria (80% a 90%), por componentes de terceiros (e cada vez mais de código aberto). Isso fica evidente na quantidade de scripts e outros códigos injetáveis encontrados em aplicativos web. Às vezes, esse script é executado remotamente e retorna uma imagem, um anúncio ou outro conteúdo, como fontes web e sprites. Em outros casos, o próprio script é carregado em tempo de execução e executado dentro dos limites do navegador, como o jQuery.

Isso é o que se conhece como componentização — ou atomização, se preferir. Trata-se da divisão de aplicações em várias partes menores. No lado do cliente, nós as chamamos de componentes, pois geralmente são executadas no mesmo espaço. No lado do servidor, cada vez mais as chamamos de microsserviços e as implantamos em contêineres. Em ambos os casos, o impacto é semelhante: acabamos com um número imprevisível de caminhos de dados que afetam diretamente o desempenho.

Basicamente, você tem controle sobre um único caminho de dados, que talvez corresponda a 20% da sua aplicação. Isso significa que você tem pouquíssimo controle sobre a experiência do usuário, pois tem pouquíssimo controle sobre o desempenho.

Isso também vale para a segurança — obrigado por notar. A questão é que estamos aprendendo rapidamente a aproveitar técnicas de código do lado do cliente para melhorar a segurança. Isso não funciona tão bem quando se trata de desempenho, porque a maioria dos aplicativos é móvel ou web, e nenhum dos dois realmente oferece a oportunidade ou a possibilidade de mexer na pilha de rede.

Uma das maneiras de combater esse problema é retomar o controle. O interessante de retomar o controle é que você também pode se beneficiar dos efeitos colaterais positivos para a segurança.

GANHA-GANHA: REDUZA OS RISCOS e MELHORE O DESEMPENHO

Se seus aplicativos costumam carregar componentes dinamicamente de sites externos, pare com isso. Pare agora. Isso é tanto uma questão de segurança quanto de desempenho. Você está implicitamente dando carta branca para que um script de origem externa seja executado no contexto do seu aplicativo. Acredite: em caso de violação de segurança, o usuário não conseguirá distinguir seus componentes daqueles carregados externamente. Como aprendemos com a recente crise envolvendo a vulnerabilidade do contêiner runc, a injeção de código malicioso em recursos carregados de registros ou sites de terceiros representa um risco à segurança.

Se for um script, é melhor cloná-lo e disponibilizá-lo em sua própria infraestrutura. Assim, você reduz os riscos ao manter o controle e pode ajustar configurações que melhoram o desempenho para os usuários. Isso inclui o DNS, que comprovadamente exerce o maior impacto — muitas vezes negativo — sobre o desempenho dos aplicativos. Ao carregar componentes de sites externos, você depende da infraestrutura de DNS deles para obter o desempenho esperado. Carregar componentes de seus próprios sites pode reduzir drasticamente esse impacto, simplesmente porque o cache DNS local do usuário passa a trabalhar a seu favor.

Hospedar scripts em seu próprio site também permite empregar otimizações de TCP, descarregamento de SSL/TLS ou técnicas gerais de aceleração de aplicações para melhorar o desempenho como um todo. Isso também oferece a oportunidade de realizar verificações de segurança nesses scripts para garantir que não haja surpresas ocultas em seu código.

A componentização é excelente para o desenvolvimento e certamente ajuda a acelerar a geração de valor. No entanto, ela pode afetar negativamente o desempenho e a segurança. Esteja ciente dos riscos à segurança e à satisfação dos usuários e saiba o que você pode fazer para combatê-los.

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