A atração gravitacional dos aplicativos está fragmentando a rede

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

A rede está se dividindo. Bifurcando-se. Dispersando-se. Você pode usar o termo que preferir para descrever o fenômeno dos serviços de rede saindo do subúrbio tranquilo que é a rede corporativa e se mudando para os bairros urbanos agitados e barulhentos do lado das aplicações na rede do data center. A terminologia não é o foco da discussão de hoje; em vez disso, vamos refletir sobre o motivo pelo qual isso está acontecendo.

Alguns poderiam dizer: “Bem, Lori, é óbvio que a rede corporativa depende muito de hardware, e o hardware simplesmente não tem a flexibilidade e a agilidade necessárias para se adequar ao ambiente mais moderno e ágil das equipes de desenvolvimento e operações.”

Bem, não. Não se trata tanto de hardware ou software porque, na verdade, você precisa de hardware independentemente do que faça (recursos como RAM, capacidade computacional e acesso à rede não surgem do nada, como você sabe). A questão está mais relacionada à cultura operacional e às realidades que regem cada uma das duas redes e que estão levando alguns serviços de um lado para o outro.

Na verdade, eu diria que o que realmente está acontecendo é que as aplicações agora são o centro de gravidade e estão atraindo para si todos os serviços relacionados a elas, de forma muito semelhante à atração que a Terra exerce sobre a Lua.

A questão é que os serviços vinculados a aplicações — como balanceamento de carga, armazenamento em cache, aceleração e segurança de aplicações web — são muito específicos para cada aplicação. Não são serviços do tipo “tamanho único”. Pelo contrário, são serviços altamente especializados e centrados na aplicação, cujas políticas visam disponibilizar, proteger e otimizar UMA aplicação.

Não todos eles. Nem mesmo todos do mesmo tipo. Apenas um. Aquele ali.

Isso é muito diferente, por exemplo, de um firewall de rede ou IPS/IDS, cujo funcionamento não é realmente tão específico para uma aplicação. As aplicações web são executadas pela porta 80, então basta abri-la e permitir o acesso pelo firewall. Há pouquíssima especificidade de “aplicação” nisso, além do fato de que, bem, elas usam o mesmo protocolo (HTTP) e são executadas na mesma porta.

Por outro lado, definir uma política de segurança que determine que tipo de dado (string? inteiro? alfanumérico?) e qual quantidade de dados (15 caracteres? 12? 100?) pode ser associada a um único campo de entrada (nome de usuário? e-mail? comentário?), que por sua vez está associado a um único URI (/login.x), é algo extremamente específico da aplicação. O mesmo vale para as políticas que regem a minificação e a concatenação de folhas de estilo, bem como o monitoramento da integridade associado a uma aplicação no serviço de balanceamento de carga.

Por que a afinidade é importante

Atualmente, estima-se que uma empresa média gerencie cerca de 508 aplicações. De acordo com nossa pesquisa 31% das organizações têm, de fato, 500 aplicações ou mais, mas esse também não é o ponto; trata-se apenas de um parâmetro de referência. E é um parâmetro porque muitas organizações planejam desenvolver muito mais aplicações. Há ainda aquelas que estão adotando uma arquitetura de microsserviços e que não estão necessariamente alterando o número de aplicações, mas sim o número de “sistemas”, por assim dizer, que precisarão dos serviços com afinidade de aplicação mencionados anteriormente.

Então, imagine que uma organização esteja planejando dobrar o número de aplicações sob sua gestão. Digamos que ela tenha começado com 500 e, de repente, passe a ter 1.000. Será necessário provisionar, configurar e gerenciar cada uma das políticas. Para facilitar as contas, vamos supor que cada aplicação precise de apenas duas: uma para escalabilidade e outra para segurança. Isso significa 2.000 políticas com as quais você terá de lidar. Preparado? Vamos lá.

Pois é. O problema não é que o “hardware” da rede corporativa não consiga dar conta disso. Pelo contrário, ele consegue justamente porque é um hardware desenvolvido especificamente para essa finalidade e, portanto, tem uma capacidade muito superior à de um servidor de uso geral. O problema está nos processos e na mão de obra necessários para fazer tudo isso. Não se trata apenas da quantidade de dispositivos necessários, mas também do número de políticas exclusivas (específicas para cada aplicação) que precisam ser implantadas.

E não se trata apenas de implantar, mas também de atualizar. Como as políticas vinculadas a aplicações são configuradas especificamente para uma aplicação, é mais provável que, quando um aplicativo for atualizado ou uma correção for implementada, as políticas de serviços de aplicação associadas a ele também precisem ser atualizadas. E, com as organizações querendo fazer implantações com mais frequência, bem... dá para imaginar que as equipes responsáveis pela rede corporativa ficariam completamente sobrecarregadas.

Do outro lado, na rede de aplicativos, as equipes de desenvolvimento e operações estão ávidas. Ávidas por entregar e implantar aplicativos. Elas estão prontas para usar suas novas habilidades em automação e orquestração para acelerar esse processo.

E é exatamente isso que estão fazendo, ao assumir a responsabilidade por um número cada vez maior de serviços relacionados às aplicações e incorporá-los às suas arquiteturas e aos seus processos de implantação. Com a crescente conscientização sobre DevOps e algum incentivo do setor proveniente das SDNs, quase todos os serviços de rede passaram a contar com APIs. Muitos outros contam com modelos que se encaixam perfeitamente às necessidades dos operadores que adotam uma abordagem de “infraestrutura como código” para gerenciar e implantar a infraestrutura necessária para dar suporte às aplicações.

É por isso que cada vez mais “serviços de aplicação” estão surgindo na rede de aplicações e deslocando o centro de gravidade da TI empresarial para a aplicação.

É uma estratégia de escalabilidade operacional e dos negócios. É uma forma de lidar com o rápido crescimento do portfólio de aplicações sem contrariar a lei de Brooks ao simplesmente aumentar o número de profissionais de redes ou aplicações para resolver o problema. É uma forma de permitir que a TI disponibilize aplicações ao mercado com mais rapidez e frequência, sem a disrupção causada por exigir repentinamente que os operadores de rede gerenciem duas, três ou mais vezes o número de políticas que gerenciam atualmente.

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