Le mythe de l’interface unique

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

D’aussi loin que je me souvienne — et cela remonte à longtemps —, le chant des sirènes d’une interface unique permettant de visualiser et de gérer l’infrastructure séduit les services informatiques. À l’instar du Saint Graal, elle n’a jamais été trouvée, et bon nombre de professionnels de l’informatique sont devenus sceptiques quant à son existence.

La transformation numérique a définitivement enterré ce concept mythique de gestion et en a fait émerger un nouveau : un plan de contrôle unique.

La bonne nouvelle, c’est que, contrairement à l’interface unique tant recherchée par les intrépides explorateurs informatiques d’autrefois, un plan de contrôle unique pourrait être à notre portée. En effet, il ne repose pas sur une interface graphique, mais sur l’API.

Et pas n’importe quelle API, mais une API déclarative.

Pour comprendre pourquoi, revenons en 2010, à l’époque où le terme « Infrastructure 2.0 » était en vogue.

Au niveau le plus bas de l’architecture se trouve Infrastructure 2.0. Infrastructure 2.0 vise à favoriser le dynamisme et la collaboration au sein de l’infrastructure réseau et de l’infrastructure de fourniture d’applications. Elle permet aux composants fondamentaux des centres de données, traditionnellement déconnectés du point de vue de la communication et de la gestion, de se connecter et de collaborer. Cela repose principalement sur des API ouvertes et fondées sur des normes qui fournissent un ensemble granulaire de fonctions opérationnelles pouvant être appelées par diverses méthodes programmatiques, telles que des systèmes d’orchestration, des applications personnalisées ou l’intégration avec des solutions traditionnelles de gestion des centres de données. Infrastructure 2.0 consiste à rendre le réseau plus intelligent, tant du point de vue de la gestion que de l’exécution, mais dans le cadre de sa relation avec le cloud et l’informatique en tant que service, l’accent est principalement mis sur la gestion.

Infrastructure 2.0 englobe la mise à disposition sous forme de services de tous les éléments, des routeurs aux commutateurs, des répartiteurs de charge à l’accélération des applications, des pare-feu aux composants de sécurité des applications web, jusqu’à l’infrastructure des serveurs (physiques et virtuels). En substance, il s’agit de composants dotés d’API.

Source : <https://devcentral.f5.com/articles/infrastructure-20-cloud-it-as-a-service-an-architectural-parfait>

Cela vous rappelle quelque chose ? Nous ne parlons plus d’Infrastructure 2.0, mais de « déploiement continu », d’« automatisation » et d’autres termes propres au DevOps. Pourtant, le concept reste le même. Cette idée explique en elle-même pourquoi le fameux « tableau de bord unique » n’a jamais vu le jour. En effet, pour qu’un tel concept mythique puisse exister, une solution unique devrait intégrer (au moyen de méthodes manuelles) un vaste éventail de solutions de réseau, de services applicatifs et de sécurité.

Cela n’allait jamais arriver.

Pour être honnête, cela n’allait jamais se produire malgré l’activation des API sur la majeure partie de cette infrastructure. Pourquoi ? Parce que toutes ces API étaient impératives et tout aussi étroitement couplées au modèle objet de chaque appareil que leurs interfaces graphiques. Les API impératives sont intrinsèquement liées à des modèles objets propres à chaque appareil ou service, qui imposent une lourde charge en matière d’expertise opérationnelle à ceux qui tentent de les utiliser. Imaginez maintenant la personne polyvalente de votre service informatique à qui vous faites confiance pour assurer la gestion opérationnelle des routeurs, des commutateurs, des dispositifs de sécurité et de cinq catégories différentes de services applicatifs provenant de plusieurs fournisseurs.

Exactement. Une telle créature, c’est comme le Bigfoot : on en entend souvent parler, mais son existence n’a jamais été prouvée.

Qu’est-ce que je veux dire par là ? Eh bien, ceci :

La manière dont nous représentons, par exemple, un pool, une VIP (adresse IP virtuelle) ou un VLAN (réseau local virtuel) n’est pas la même que celle dont Cisco, Citrix ou Juniper représentent ces mêmes objets réseau. En effet, notre terminologie peut même être différente : nous utilisons le terme « pool », tandis que d’autres fournisseurs d’ADC utilisent « ferme » ou « cluster » pour désigner le même concept. Avec la virtualisation vient encore un autre ensemble de termes, souvent en contradiction avec ceux qu’utilisent les fournisseurs d’infrastructures réseau. « Serveur virtuel » désigne quelque chose de complètement différent selon que ce terme est employé par un fournisseur de solutions de mise à disposition d’applications ou par un fournisseur de solutions de virtualisation tel que VMWare ou Microsoft.

Source : <https://devcentral.f5.com/articles/making-infrastructure-20-reality-may-require-new-standards>

VOILÀ pourquoi nous ne pouvons pas avoir de belles choses, comme une interface unifiée. Parce que le secteur ne dispose pas d’une vision unifiée à travers laquelle il appréhende l’infrastructure.

Mais cet article n’a pas pour but de vous déprimer ni de vous condamner à une vie dans l’informatique éternellement gâchée par une gestion appareil par appareil. Bien au contraire. Les API déclaratives — véritablement déclaratives — peuvent permettre de disposer d’un plan de contrôle unique.

Mais pour y parvenir, nous devons abandonner l’idée selon laquelle une approche déclarative consiste à encoder les configurations de nos appareils en JSON ou en YAML. Ce n’est pas véritablement déclaratif, car cela repose encore sur une expertise opérationnelle propre au domaine, liée à des modèles d’objets spécifiques aux appareils — que personne d’autre ne peut intégrer ni utiliser.

Prenons les descriptions des ressources Service et Endpoint de Kubernetes comme exemple de modèle déclaratif :

Tout ce dont j’ai besoin pour configurer un serveur virtuel se trouve juste ici dans ces définitions très concises et indépendantes de toute implémentation. L’externalIP est l’adresse IP virtuelle, c’est-à-dire l’adresse avec laquelle l’utilisateur ou l’application mobile va communiquer. Le nom « my-Service » décrit un serveur virtuel, tandis que la spec fournit les détails du réseau, notamment les ports à utiliser et le pool (« MyApp »). Les ressources Endpoint décrivent chacun des nœuds qui composent « my-service » et fournissent les membres du pool « MyApp ». La seule chose qui manque ici est un moyen de sélectionner un algorithme d’équilibrage de charge pour les services capables de faire mieux qu’une simple distribution à tour de rôle. Et nous pourrions facilement étendre la partie « spec » de la description du service afin d’y inclure une option « algorithm: RR | WRR | LC | FR », applicable universellement à toutes les solutions d’équilibrage de charge. Voilà. C’est fait.

En théorie, je peux fournir cette même ressource à n’importe laquelle de dix solutions d’équilibrage de charge différentes, et chacune déterminerait comment modéliser et mettre en œuvre l’intention de la description, à savoir configurer un service virtuel situé à l’adresse 80.11.12.10 sur le port 80, qui répartit les requêtes HTTP entre deux instances d’application situées aux adresses 1.2.3.4 et 2.3.4.5 sur le port 80.

Une autre façon de voir les choses consiste à comparer « Je voudrais une pizza au pepperoni » à la formulation plus fastidieuse : « Je voudrais que vous prépariez de la pâte à pizza, puis que vous l’étaliez en un cercle de 10 pouces de diamètre. Recouvrez-la de sauce tomate, puis de mozzarella. Répartissez ensuite du pepperoni sur toute la surface. Faites cuire à 425 degrés pendant 15 minutes. »

L’une de ces approches est plus simple et vous épargne les détails. L’autre vous oblige non seulement à savoir ce que vous voulez — une pizza au pepperoni — mais aussi à savoir comment la préparer. Voilà ce qu’est l’expertise opérationnelle.

À l’instar d’une commande de pizza, la description d’une ressource Kubernetes est générique. Rien dans celle-ci n’impose un modèle d’objet ou une méthode d’implémentation particulière à l’appareil qui reçoit cette ressource. Elle décrit ce qui doit être présent, mais ne dicte en aucun cas comment je dois l’implémenter.

Pour être véritablement déclaratif, il faut fournir les moyens de communiquer l’intention et l’état final souhaité. À l’avenir, il nous suffira de dire « configure un service virtuel pour 'my-app' », et voilà ! Grâce aux métadonnées, aux balises d’application et à une découverte automatisée et intelligente, le service se configurera intégralement de lui-même*.

Si nous voulons un jour atteindre ce nirvana que représente un plan de contrôle unique, nous allons devoir nous atteler à la tâche et élaborer des spécifications déclaratives neutres qui évitent d’avoir à intégrer chaque équipement du centre de données au moyen d’une API impérative. Car l’intégration des API équipement par équipement n’est finalement pas si différente de la gestion équipement par équipement.

Nous voulons ce qu’il y a de mieux. Nous voulons un plan de contrôle unique et unifié. Mais pour y parvenir, le secteur devra faire plus que simplement acquiescer à l’approche déclarative et reconnaître que si personne d’autre ne peut interpréter et utiliser votre interface déclarative, c’est qu’elle n’est pas vraiment déclarative.

*On peut toujours rêver, non ?

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

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 Vittie