A atração gravitacional dos aplicativos está bifurcando a rede
A rede está se bifurcando. Bifurcando. Dispersando. Você pode usar qualquer termo que desejar para descrever o fenômeno de serviços de rede se deslocando do subúrbio tranquilo que é a rede corporativa para bairros urbanos agitados e barulhentos no lado da aplicação da rede do data center. A terminologia não é o ponto da discussão de hoje, mas hoje vamos refletir sobre o motivo pelo qual isso está acontecendo.
Alguns podem dizer: “Bem, Lori, é óbvio que a rede corporativa é muito baseada em hardware e o hardware simplesmente não tem a flexibilidade e agilidade necessárias para se adaptar ao ambiente mais moderno e ágil que acontece em desenvolvimento e operações”.
Bem, não. Não é tanto sobre hardware ou software porque, na verdade, você tem que ter hardware não importa o que faça (recursos como RAM, computação e acesso à rede não se materializam do nada, sabia?). Tem mais a ver com a cultura operacional e as realidades que governam cada uma das duas redes que estão levando alguns serviços de um lado para o outro.
Na verdade, eu diria que o que realmente está acontecendo é que os aplicativos agora são o centro de gravidade e estão atraindo todos os serviços afins de aplicativos para eles, da mesma forma que a lua é atraída para a terra.
O problema é que serviços afins de aplicativos – como balanceamento de carga, cache, aceleração e segurança de aplicativos da web – são todos muito peculiares a um determinado aplicativo. Esses não são serviços do tipo “tamanho único”. Pelo contrário, esses são serviços altamente focados e centrados em aplicativos, cujas políticas visam fornecer, proteger e otimizar UM aplicativo.
Nem todos eles. Nem todos são do mesmo tipo. Só uma. Aquele ali.
Isso é muito diferente de, digamos, um firewall de rede ou IPS/IDS cuja operação não é tão específica para um aplicativo. Os aplicativos da Web são executados na porta 80, então abra-a e permita o acesso pelo firewall. Há muito pouca especificidade de “aplicação” nisso, além de, bem, eles usarem o mesmo protocolo (HTTP) e rodarem na mesma porta.
Por outro lado, definir uma política de segurança que determine que tipo de dados (string? inteiro? alfanumérico?) bem como a quantidade de dados (15 caracteres? 12? 100?) pode ser associado a um único campo de entrada (nome de usuário? e-mail? comentário?) que está associado a um único URI (/login.x) é bem específico do aplicativo. O mesmo ocorre com as políticas que regem a minimização e a concatenação de folhas de estilo, além do monitoramento de integridade associado a um aplicativo no serviço de balanceamento de carga.
Por que a afinidade é importante
Atualmente, estima-se que uma empresa média gerencia cerca de 508 aplicativos. De acordo com nossa pesquisa, 31% das organizações têm 500 ou mais, mas esse também não é o ponto, é apenas uma linha de base. E é uma linha de base porque muitas organizações estão planejando criar muito mais aplicativos. E há aquelas organizações que estão adotando uma arquitetura de microsserviços que não estão necessariamente mudando o número de aplicativos, mas estão mudando o número de "sistemas", se preferir, que precisarão dos serviços afins de aplicativos mencionados anteriormente.
Então. Imagine que uma organização esteja pensando em dobrar o número de aplicativos sob gerenciamento. Digamos que eles começaram com 500 e agora de repente terão 1000. Eles precisam provisionar, configurar e gerenciar cada política. Digamos que cada aplicativo precisa apenas de 2 – um para escala e um para segurança – para tornar a matemática agradável e fácil. São 2000 políticas com as quais você precisa lidar. Preparar? Ir.
Sim. O problema não é que o “hardware” na rede corporativa não consiga lidar com isso. Pelo contrário, pode, precisamente, porque é um hardware desenvolvido especificamente e, portanto, tem capacidade muito além de um servidor de uso geral. O problema são os processos e a mão de obra necessários para fazer tudo isso. Não é apenas o número de dispositivos necessários, mas o número de políticas exclusivas (afins ao aplicativo) que devem ser implantadas.
E não apenas implantado, mas atualizado. Como as políticas afins ao aplicativo são configuradas especificamente para um aplicativo, há uma probabilidade maior de que, quando um aplicativo é atualizado ou uma correção é introduzida, suas políticas de serviço de aplicativo associadas também precisem ser atualizadas. E com as organizações querendo fazer implantações com mais frequência, bem... você pode imaginar que o pessoal da rede corporativa ficaria completamente sobrecarregado.
Do outro lado da cerca, na rede de aplicativos, os desenvolvedores e as operações estão famintos. Ansiosos para que os aplicativos sejam entregues e implantados. Eles estão prontos para usar suas novas habilidades em automação e orquestração para acelerar esse processo.
E é isso que eles estão fazendo, assumindo a responsabilidade por mais e mais serviços afins a aplicativos e incorporando-os em suas arquiteturas e processos de implantação. Com a conscientização crescente sobre DevOps e algum incentivo do setor por meio de SDN, quase todos os serviços de rede são habilitados com APIs. Muitos outros são habilitados com modelos que se encaixam como uma luva nas mãos de operadores que empregam uma abordagem de “infraestrutura como código” para gerenciar e implantar a infraestrutura necessária para dar suporte aos aplicativos.
É por isso que cada vez mais “serviços de aplicação” estão surgindo na rede de aplicações e mudando o centro de gravidade da TI empresarial para a aplicação.
É uma estratégia de escala operacional e empresarial. É uma maneira de lidar com o rápido crescimento do portfólio de aplicativos sem infringir a Lei de Brooks, aumentando o número de funcionários da rede ou dos aplicativos no problema. É uma maneira de permitir que a TI entregue aplicativos ao mercado com mais rapidez e frequência, sem a interrupção causada pela necessidade repentina de as operadoras de rede gerenciarem duas, três ou mais vezes o número de políticas que gerenciam atualmente.