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.

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

Tout ce dont vous avez besoin pour configurer un serveur virtuel est ici même, dans ces définitions très concises et indépendantes de toute implémentation. L’externalIP correspond à l’adresse IP virtuelle — celle avec laquelle l'utilisateur ou l'application mobile communiquera. Le nom "my-Service" désigne un serveur virtuel, la spec fournissant les détails réseau comme les ports à utiliser et le pool ("MyApp"). Les ressources Endpoint désignent chaque nœud constitutif de "my-service" et définissent les membres du pool "MyApp". Il ne manque plus qu’une façon de choisir un algorithme d’équilibrage de charge pour les services offrant plus que le simple round robin.  Et vous pouvez facilement étendre la partie "spec" de la description du service pour y inclure une option "algorithme : RR | WRR | LC | FR" applicable universellement à toutes les solutions d’équilibrage de charge. Voilà. C’est fait.

En théorie, vous pouvez utiliser cette même ressource avec l’une des dix solutions d’équilibrage de charge disponibles, chacune choisira comment modéliser et appliquer l’intention de la description : configurer un service virtuel à l’adresse 80.11.12.10, 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, également 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 reste générique. Rien n'impose un modèle d'objet ou une méthode d'implémentation spécifique sur l'appareil qui traite cette ressource. Elle indique ce qui doit être en place, sans affecter comment vous choisirez de l'implémenter.

Ê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 ?