Contrôle versus exécution dans le chemin de données

Autrefois, les services d’applications fournissant des applications formaient un chemin de données direct et étroit. Toutes les applications traversaient essentiellement le même ensemble de services sur le même réseau. Cette simplicité architecturale permettait de combiner facilement un point de contrôle unique avec un point d’exécution unique. Cela a, à son tour, conduit à l’essor du contrôleur de distribution d’applications (ADC). Grâce à lui, le trafic des applications pourrait être façonné, dirigé, mis à l’échelle et sécurisé, le tout en un seul endroit. Le contrôle et l'exécution combinés offrent aux opérations un point stratégique dans le chemin de données où toutes sortes de politiques peuvent être appliquées et exécutées.

L’essor du cloud et l’adoption continue des conteneurs ont perturbé ce chemin de données. Nous disposons désormais de chemins de données multiples et parfois dynamiques par lesquels les applications sont livrées. Un point de contrôle et d’exécution unique et stratégique n’est souvent plus réalisable d’un point de vue opérationnel ou architectural.

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 d’application.

Il est important d’avoir le moins de points de contrôle possible via lesquels les services d’application dans le chemin de données peuvent être exploités (déployés, configurés et gérés). Encourager l’utilisation de plusieurs points de contrôle entraîne inévitablement des politiques contradictoires qui causent des problèmes aux consommateurs d’applications. La résolution des problèmes devient plus complexe et prend plus de temps, ce qui suscite la colère et l’angoisse des utilisateurs. Malheureusement, la prolifération des outils est une plainte courante parmi ceux qui gèrent l’ajout d’ architectures cloud natives à un portefeuille d’applications déjà diversifié .

Nous savons, grâce à notre étude 2020 sur l'état des services d'applications, que les opérations sont principalement responsables du fonctionnement des services d'applications, mais ils ne sont pas seuls. DevOps, NetOps et SecOps sont tous investis dans l'exploitation des services d'applications sur site et dans le cloud public. 

Ce qui les distingue souvent, ce sont les fonctions spécifiques des services d’application dont ils sont responsables.

Les DevOps sont en grande partie responsables de la fiabilité, des performances et des politiques spécifiques aux applications. Les NetOps, en revanche, sont, à propos de leur nom, davantage axés sur les attributs du réseau. C'est NetOps qui gère souvent les services d'application du point de vue de l'infrastructure. SecOps, bien sûr, s'intéresse à la sécurité en ce qui concerne l'infrastructure et l'application.

Mais ce n’est pas parce qu’il existe une division des tâches qu’il doit y avoir des outils distincts avec lesquels ils exercent leur art. Aujourd’hui, il existe de nombreuses preuves 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 de choix côté déploiement continu. Une grande partie de la décision réside dans l’adéquation des outils aux méthodes de travail des différents acteurs qui doivent interagir avec les outils au quotidien.

Ainsi, si un outil unique devait émerger pour améliorer la cohérence des politiques, accélérer le dépannage et éliminer la complexité et le coût de la prolifération des outils, il doit disposer des interfaces appropriées pour garantir que tous les principaux composants des services d'application dans le chemin de données soient en mesure d'exploiter l'ensemble d'outils pour effectuer leurs tâches respectives.

Cela est important pour la sécurité globale et la fiabilité des services d’application eux-mêmes. En maintenant un point de contrôle unifié, les organisations peuvent être sûres que les changements sont suivis et compris. Bien qu'il ne s'agisse pas d'une implémentation immuable, elle franchit plusieurs étapes vers cette pratique en centralisant le contrôle dans un seul outil. 

Un exemple d'un tel outil est NGINX Controller .  

Vous remarquerez que, comme prévu, une variété de services d’application (analyse, gestion des API, sécurité et maillage de services) peuvent tous être contrôlés de manière centralisée, même si le fonctionnement et l’exécution sont distribués.

Dans n'importe quel environnement, il est important de réduire le nombre d'outils autorisés à interagir avec les composants du chemin de données (services d'application) afin d'atténuer les problèmes potentiels de mauvaise configuration ou de configurations conflictuelles. Dans un environnement multi-cloud 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 d'application constituant le chemin de données. 

Ce qui est encore plus convaincant pour ceux qui possèdent les budgets, c’est la réduction des dépenses opérationnelles associée à l’élimination des activités manuelles répétitives grâce à l’automatisation.

Unifier le contrôle dans un seul outil est une façon d’y parvenir.