L'attraction gravitationnelle des applications divise le réseau

Le réseau est en train de se bifurquer. Bifurquant. Se disperser. Vous êtes libre d’utiliser le terme que vous souhaitez pour décrire le phénomène de relocalisation des services réseau de la banlieue tranquille qu’est le réseau d’entreprise vers les quartiers urbains agités et bruyants du côté applicatif du réseau du centre de données. La terminologie n’est pas le sujet de la discussion d’aujourd’hui, mais plutôt la raison pour laquelle cela se produit.

Certains pourraient dire : « Eh bien, Lori, il est évident que le réseau d’entreprise est en grande partie basé sur le matériel et que le matériel n’a tout simplement pas la flexibilité et l’agilité nécessaires pour s’adapter à l’environnement plus branché et agile qui règne dans le développement et les opérations. »

Eh bien non. Ce n'est pas tant une question de matériel ou de logiciel , car en réalité, vous devez disposer de matériel quoi que vous fassiez (des ressources comme la RAM, le calcul et l'accès au réseau ne se matérialisent pas de nulle part, vous savez). Il s’agit davantage de la culture opérationnelle et des réalités qui régissent chacun des deux réseaux et qui font circuler certains services d’un côté à l’autre.

En fait, je dirais que ce qui se passe réellement, c’est que les applications sont désormais le centre de gravité et qu’elles attirent vers elles tous les services liés aux applications, de la même manière que la lune est attirée par la terre.

Le problème est que les services liés aux applications (comme l’équilibrage de charge, la mise en cache, l’accélération et la sécurité des applications Web) sont tous très particuliers à une application donnée. Il ne s’agit pas de services « universels ». Au contraire, il s’agit de services hautement ciblés et centrés sur les applications, dont les politiques visent à fournir, sécuriser et optimiser UNE application.

Pas tous. Pas même tous du même genre. Un seul. Celui-là, là-bas.

C’est très différent, par exemple, d’un pare-feu réseau ou d’un IPS/IDS dont le fonctionnement n’est pas vraiment spécifique à une application. Les applications Web s'exécutent sur le port 80, ouvrez-le donc et autorisez l'accès via le pare-feu. Il y a très peu de spécificité « d’application » à cela, à part qu’ils utilisent le même protocole (HTTP) et fonctionnent sur le même port.

À l'inverse, définir une politique de sécurité qui dicte quel type de données (chaîne ? entier ? alphanumérique ?) ainsi que quelle quantité de données (15 caractères ? 12? 100 ?) peut être associé à un seul champ de saisie (nom d'utilisateur ? e-mail ? commentaire ?) associé à un seul URI (/login.x), ce qui est assez spécifique à l'application. Il en va de même pour les politiques qui régissent la minification et la concaténation des feuilles de style, ainsi que la surveillance de l’état associée à une application dans le service d’équilibrage de charge.

Pourquoi l’affinité est importante

Aujourd’hui, on estime qu’une entreprise moyenne gère environ 508 applications. Selon nos recherches, 31 % des organisations en comptent en réalité 500 ou plus, mais ce n'est pas non plus le problème, c'est juste une base de référence. Et c’est une base de référence car de nombreuses organisations prévoient de créer beaucoup plus d’applications. Et puis il y a les organisations qui adoptent une architecture de microservices qui ne changent pas nécessairement le nombre d'applications mais qui changent le nombre de « systèmes », si vous voulez, qui vont avoir besoin de ces services affines aux applications mentionnés ci-dessus.

Donc. Imaginez qu’une organisation envisage de doubler le nombre d’applications sous gestion. Disons qu’ils ont commencé avec 500 et que soudainement ils vont en avoir 1000. Ils doivent provisionner, configurer et gérer chaque politique. Disons que chaque application n’en a besoin que de deux – une pour l’échelle et une pour la sécurité – pour rendre les calculs simples et agréables. Cela représente 2000 politiques auxquelles vous devez faire face. Prêt? Aller.

Ouais. Le problème n’est pas que le « matériel » du réseau d’entreprise ne peut pas gérer cela. Au contraire, c'est possible précisément parce qu'il s'agit d'un matériel spécialement conçu et qu'il possède donc une capacité bien supérieure à celle d'un serveur à usage général. Le problème réside dans les processus et la main-d’œuvre nécessaires pour tout faire. Ce n’est pas seulement le nombre d’appareils nécessaires qui compte, mais aussi le nombre de politiques uniques (affectées aux applications) qui doivent être déployées.

Et pas seulement déployé, mais mis à jour. Étant donné que les stratégies d'application affines sont configurées spécifiquement pour une application, il est plus probable que lorsqu'une application est mise à niveau ou qu'un correctif est introduit, ses stratégies de service d'application associées doivent également être mises à jour. Et avec des organisations souhaitant déployer plus fréquemment, eh bien... vous pouvez imaginer que les responsables du réseau d'entreprise seraient complètement débordés.

De l’autre côté de la barrière, dans le réseau d’applications, les développeurs et les opérateurs ont faim. Nous avons hâte de voir nos applications livrées et déployées. Ils sont prêts à utiliser leurs nouvelles compétences en automatisation et en orchestration pour accélérer ce processus.

Et c’est ce qu’ils font, en assumant la responsabilité de services de plus en plus liés aux applications et en les incorporant dans leurs architectures et processus de déploiement. Avec une prise de conscience croissante de DevOps et certains encouragements de l’industrie en faveur du SDN, les services réseau sont presque tous activés avec des API. De nombreux autres sont dotés de modèles qui s’adaptent comme un gant à la main des opérateurs utilisant une approche « infrastructure en tant que code » pour gérer et déployer l’infrastructure requise pour prendre en charge les applications.

C’est pourquoi de plus en plus de « services applicatifs » apparaissent dans le réseau applicatif et déplacent le centre de gravité de l’informatique d’entreprise vers l’application.

Il s’agit d’une stratégie de mise à l’échelle commerciale et opérationnelle. C'est un moyen de faire face à la croissance rapide du portefeuille d'applications sans enfreindre la loi de Brooks en augmentant les effectifs du réseau ou des applications pour résoudre le problème.  Il s'agit d'un moyen de permettre au service informatique de proposer des applications sur le marché plus rapidement et plus fréquemment, sans subir les perturbations causées par le fait de demander soudainement aux opérateurs réseau de gérer deux, trois ou plus de politiques qu'ils gèrent actuellement.