Autrefois, les services applicatifs assurant la mise à disposition des applications formaient un chemin de données simple et direct. Toutes les applications empruntaient essentiellement le même ensemble de services sur le même réseau. Cette simplicité architecturale permettait de réunir facilement un point de contrôle unique et un point d’exécution unique. C’est ainsi qu’est apparu le contrôleur de mise à disposition d’applications (ADC). Grâce à lui, le trafic applicatif pouvait être façonné, orienté, mis à l’échelle et sécurisé, le tout depuis un seul et même endroit. La combinaison du contrôle et de l’exécution offrait aux équipes d’exploitation un point stratégique dans le chemin de données, à partir duquel toutes sortes de politiques pouvaient être appliquées et exécutées.
L’essor du cloud et l’adoption croissante des conteneurs ont bouleversé ce chemin de données. Les applications sont désormais acheminées par des chemins de données multiples et parfois dynamiques. Il n’est souvent plus possible, sur le plan opérationnel comme architectural, de disposer d’un point stratégique unique de contrôle et d’exécution.
Mais cela ne signifie pas qu’un point de contrôle unifié n’est plus possible, même lorsque l’exécution est déléguée à un ensemble disparate de services applicatifs.
Il est important de limiter autant que possible le nombre de points de contrôle permettant d’exploiter (déployer, configurer et gérer) les services applicatifs situés sur le chemin des données. Encourager l’utilisation de plusieurs points de contrôle entraîne inévitablement des conflits entre les politiques, ce qui pose des problèmes aux utilisateurs des applications. La résolution des incidents devient plus complexe et chronophage, suscitant colère et inquiétude chez les utilisateurs. Malheureusement, la prolifération des outils est un problème fréquemment signalé par les personnes chargées d’intégrer des architectures cloud natives à un portefeuille d’applications déjà diversifié.
Notre étude 2020 sur l’état des services applicatifs nous apprend que les équipes d’exploitation sont principalement responsables du fonctionnement de ces services, mais qu’elles ne sont pas seules. Les équipes DevOps, NetOps et SecOps participent toutes à l’exploitation des services applicatifs, aussi bien sur site que dans le cloud public.
Ce qui les distingue souvent, ce sont les fonctions spécifiques des services applicatifs dont ils sont responsables.
Les équipes DevOps sont principalement responsables de la fiabilité, des performances et des politiques propres aux applications. Les équipes NetOps, quant à elles, se concentrent davantage, comme leur nom l’indique, sur les caractéristiques du réseau. Ce sont souvent elles qui assurent la maintenance des services applicatifs du point de vue de l’infrastructure. Les équipes SecOps, bien entendu, s’occupent de la sécurité de l’infrastructure et de l’application.
Mais ce n’est pas parce qu’il peut exister une répartition des responsabilités que chacun doit disposer d’outils distincts pour exercer son métier. Aujourd’hui, de nombreux éléments montrent que les pipelines CI/CD et de déploiement continu reposent sur des ensembles d’outils disparates. Jenkins et les dépôts git dominent le pipeline CI/CD, tandis qu’Ansible et Python sont les outils privilégiés pour le déploiement continu. Le choix consiste en grande partie à adapter les outils aux méthodes de travail des différentes parties prenantes qui doivent les utiliser au quotidien.
Ainsi, si un outil unique venait à s’imposer pour améliorer la cohérence des politiques, accélérer le dépannage et éliminer la complexité et les coûts liés à la prolifération des outils, il devrait disposer des interfaces adéquates afin que toutes les principales parties prenantes des services applicatifs situés sur le chemin des données puissent exploiter cet ensemble d’outils pour accomplir leurs tâches respectives.
C’est important pour la sécurité et la fiabilité globales des services applicatifs eux-mêmes. En conservant un point de contrôle unifié, les organisations peuvent avoir l’assurance que les modifications sont suivies et comprises. Bien qu’il ne s’agisse pas d’une mise en œuvre immuable, cette approche s’en rapproche à plusieurs égards en centralisant le contrôle dans un outil unique.
Un exemple d’un tel outil est NGINX Controller.
Vous remarquerez que, comme prévu, divers services applicatifs (analyse, gestion des API, sécurité et maillage de services) peuvent tous être contrôlés de manière centralisée, même si leur fonctionnement et leur exécution sont distribués.
Dans tout environnement, il est important de limiter le nombre d’outils autorisés à interagir avec les composants du chemin de données (services applicatifs) afin de réduire les risques liés à une mauvaise configuration ou à des configurations contradictoires. Dans un environnement multicloud moderne, il est encore plus essentiel de centraliser le contrôle en raison de la complexité engendrée par la croissance souvent exponentielle des services applicatifs qui composent le chemin de données.
La réduction des dépenses opérationnelles permise par l’automatisation, qui élimine les tâches manuelles répétitives, constitue un argument encore plus convaincant pour les responsables des budgets.
Unifier le contrôle au sein d’un outil unique est un moyen d’y parvenir.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.