Le mythe de la vitre unique

Depuis aussi longtemps que je me souvienne - et je m'en souviens très longtemps - l'appel des sirènes d'une seule vitre à travers laquelle visualiser et exploiter l'infrastructure a attiré l'informatique. Comme le Saint Graal, il n’a jamais été découvert et bon nombre de professionnels de l’informatique sont devenus cyniques quant à son existence.

La transformation numérique a enfoncé le dernier clou dans le cercueil de cette construction de gestion mythique et a donné naissance à une nouvelle : un plan de contrôle unique.

La bonne nouvelle est que, contrairement à la vitre unique recherchée par les intrépides explorateurs informatiques du passé, un plan de contrôle unique est peut-être à notre portée. C'est parce qu'il n'est pas basé sur une interface graphique, mais sur l'API.

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

Pour comprendre pourquoi, permettez-moi de vous ramener en 2010, lorsque le terme « Infrastructure 2.0 » était en vogue.

Au niveau le plus bas de l’architecture se trouve l’Infrastructure 2.0 . L'infrastructure 2.0 vise à permettre le dynamisme et la collaboration au sein de l' infrastructure réseau de distribution application . Il s’agit de la manière dont les composants fondamentaux des centres de données traditionnellement déconnectés (d’un point de vue communication et gestion) sont dotés de la capacité de se connecter et de collaborer. Cela est principalement réalisé via des API ouvertes et basées sur des normes qui fournissent un ensemble granulaire de fonctions opérationnelles qui peuvent être invoquées à partir d'une variété de méthodes programmatiques telles que les systèmes d'orchestration, les applications personnalisées et via l'intégration avec les solutions de gestion de centre de données traditionnelles. L'infrastructure 2.0 vise à rendre le réseau plus intelligent, tant du point de vue de la gestion que de l'exécution, mais dans le cas de sa relation avec le cloud et l'informatique en tant que service, la vision est principalement axée sur la gestion.

L'infrastructure 2.0 inclut l'activation des services de tout, des routeurs aux commutateurs, des équilibreurs de charge à l'accélération des application , des pare-feu aux composants de sécurité des application Web jusqu'à l'infrastructure du serveur (physique et virtuelle). Il s’agit, réduit à son essence même, de composants compatibles API.

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

Cela vous semble familier ? Nous ne l'appelons plus Infrastructure 2.0, nous l'appelons « déploiement continu », « automatisation » et d'autres termes de type DevOps. Mais le concept est le même. Cette idée est à l’origine de la raison pour laquelle un « panneau de verre unique » n’a jamais vu le jour. Car pour qu’une telle construction mythique puisse exister, une solution unique devrait incorporer (intégrer via des méthodes manuelles) une vaste gamme de solutions de réseau, de services application et de sécurité.

Cela n’aurait jamais dû arriver.

Pour être honnête, cela n’aurait jamais pu se produire malgré l’intégration d’API dans la plupart de ces infrastructures. Pourquoi? Parce que toutes ces API étaient impératives et tout aussi étroitement liées au modèle objet de chaque appareil que l’étaient leurs interfaces graphiques. Les API impératives sont intrinsèquement liées à des modèles d’objet spécifiques aux appareils/services qui imposent une lourde charge d’expertise opérationnelle à ceux qui tentent de les utiliser. Imaginez maintenant le touche-à-tout de votre organisation informatique à qui vous faites confiance pour gérer de manière opérationnelle les routeurs, les commutateurs, les dispositifs de sécurité et cinq catégories différentes de services application auprès de plusieurs fournisseurs.

Exactement. Une telle créature ressemble à Bigfoot. On en entend souvent parler, mais son existence n’a jamais été prouvée.

Qu'est-ce que je veux dire par là ? Je veux dire ceci :

La manière dont nous représentons, par exemple, un pool ou un VIP (adresse IP virtuelle) ou un VLAN (LAN virtuel) n'est pas la même que celle dont Cisco , Citrix ou Juniper représentent les mêmes objets réseau. En effet, notre terminologie peut même être différente ; nous utilisons pool, d’autres fournisseurs d’ADC utilisent « farm » ou « cluster » pour représenter le même concept. Ajoutez la virtualisation à ce mélange et un autre ensemble de termes est ajouté au mélange, souvent en conflit avec ceux utilisés par les fournisseurs infrastructure réseau . Le terme « serveur virtuel » a une signification complètement différente lorsqu'il est utilisé par un fournisseur de distribution application que lorsqu'il est utilisé par un fournisseur de virtualisation comme VMWare ou Microsoft .

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

C'est la raison pour laquelle nous ne pouvons pas avoir de belles choses, comme une simple vitre. Parce que l’industrie ne dispose pas d’une seule vitre à travers laquelle elle observe les infrastructures.

Mais cet article n’a pas pour but de vous déprimer ou de vous conduire sur le chemin d’une existence informatique gâchée par une gestion appareil par appareil pour toujours. Au contraire. Les API déclaratives – véritablement déclaratives – peuvent conduire à un plan de contrôle unique.

Mais pour ce faire, nous devons nous éloigner de l’idée selon laquelle déclaratif signifie encoder nos configurations d’appareils en JSON ou YAML. Ce n’est pas vraiment déclaratif car cela repose toujours sur une expertise du domaine opérationnel liée à des modèles d’objets spécifiques à l’appareil – et personne d’autre ne peut les ingérer et les utiliser.

Permettez-moi d’utiliser les descriptions des ressources de service et de point de terminaison Kubernetes comme exemple de modèle déclaratif :

Tout ce dont j'ai besoin pour configurer un serveur virtuel se trouve ici, dans ces définitions très concises et indépendantes de la mise en œuvre. L' externalIP est l'adresse IP virtuelle - l'adresse avec laquelle l'utilisateur ou l'application mobile va communiquer. Le nom « my-Service » décrit un serveur virtuel, la spécification fournissant les détails du réseau tels que 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 plus que du round robin.  Et nous pourrions facilement étendre la partie « spec » de la description du service pour inclure un « algorithme : Option « RR | WRR | LC | FR » universellement applicable à toutes les solutions d’équilibrage de charge. Là. Fait.

En théorie, je peux alimenter cette même ressource vers l'une des dix solutions d'équilibrage de charge différentes et chacune déterminerait comment modéliser et mettre en œuvre l' intention de la description - qui est de configurer un service virtuel situé sur le port 80.11.12.10 qui met à l'échelle les requêtes HTTP sur deux instances application situées sur 1.2.3.4 et 2.3.4.5 sur le port 80.

Une autre façon de voir les choses est de faire la différence entre « Je voudrais une pizza au pepperoni » et la phrase plus fastidieuse : « Je voudrais que tu mélanges de la pâte à pizza et que tu l'étales en un cercle de 10 pouces de diamètre. » Recouvrez-le de sauce tomate. Couvrez avec du fromage mozzarella. Placez ensuite du pepperoni partout sur le dessus. Cuire au four à 425 degrés pendant 15 minutes.

L’une de ces choses est plus simple et vous occulte les détails. L'autre vous oblige non seulement à savoir ce que vous voulez - une pizza au pepperoni - mais aussi comment la préparer. C'est ce qu'on appelle une expertise opérationnelle.

Comme pour commander une pizza, la description des ressources Kubernetes est générique. Rien dans ce document n’impose un modèle d’objet particulier ou une méthode d’implémentation sur l’appareil qui ingère cette ressource. Il décrit ce qui doit être présent, mais n’influence en rien la manière dont je pourrais le mettre en œuvre.

Être véritablement déclaratif signifie fournir les moyens de communiquer l’intention et l’ état final souhaité . À un moment donné dans le futur, nous pourrons simplement dire : « configurer un service virtuel pour 'mon-application' » et le tour est joué ! À l’aide de métadonnées et de balises application et d’une découverte automatisée et intelligente, le service se configurera de haut en bas*. 

Si nous voulons un jour atteindre ce nirvana d’un plan de contrôle unique, nous allons devoir nous y mettre et élaborer des spécifications déclaratives neutres qui éliminent le besoin d’intégrer via une API impérative chaque appareil du centre de données. Parce que l’intégration d’API appareil par appareil n’est pas vraiment différente de la gestion appareil par appareil.

Nous voulons de belles choses. Nous voulons un plan de contrôle unifié et unique. Mais pour y parvenir, l’industrie va devoir faire mieux que de se contenter d’un hochement de tête en faveur du déclaratif et reconnaître que si personne d’autre ne peut ingérer et utiliser votre interface déclarative, elle n’est pas vraiment déclarative en premier lieu.

*Une fille peut rêver, n'est-ce pas ?