Comment les interfaces déclaratives démocratisent l'infrastructure

Les API sont la nouvelle CLI. Mais les règles déclaratives sont primordiales lorsqu'il s'agit du type d'API que vous créez.

Une API (une interface de programmation d’application) est aujourd’hui une capacité essentielle. Les organisations les ont au niveau de l'entreprise, pour promouvoir l'intégration des partenaires et l'innovation par ce que l'on appelle les « développeurs citoyens ». Les applications en disposent pour faciliter l'intégration et découpler la logique métier, qui peut changer fréquemment, des interfaces, qui ne devraient pas changer aussi fréquemment. Et les infrastructures en ont. Des commutateurs aux routeurs, des services d’application aux intergiciels et aux bases de données, l’infrastructure qui comprend les pipelines de livraison et de déploiement est activée avec des API.

Cela devrait en soi être une raison de s’arrêter et de réfléchir à ce que cela signifie pour la communauté NetOps émergente. Car si les organisations ont tendance à se standardiser sur quelques composants clés de l’infrastructure d’application, elles sont moins susceptibles de se standardiser sur quelques composants clés de l’infrastructure des services réseau et d’application.

Parmi les seize services d'application différents que les organisations utilisent en moyenne pour rendre leurs applications plus rapides et plus sûres, il est certain qu'ils sont fournis par plus d'une poignée de composants d'infrastructure. Si nous supposons généreusement que le ratio est de trois services d’application par composant, cela représente toujours cinq appareils différents – avec cinq API différentes.

Le problème est que les fournisseurs d’infrastructure prennent souvent la déclaration « L’API est la nouvelle CLI » un peu trop au pied de la lettre. Autrement dit, l’API n’est qu’une simple réflexion de la CLI compatible REST.

Quiconque a travaillé avec des CLI sur plusieurs composants d’infrastructure comprend que la navigation CLI correspond très étroitement au modèle d’objet de l’infrastructure. Les API ne parviennent souvent pas à faire plus que de transférer cette conception vers HTTP. Ce qui signifie que ceux qui tentent de profiter de l’API doivent nécessairement également apprendre le modèle d’objet de l’appareil en question.

Ce niveau d’abstraction entrave la progression de l’automatisation et de l’orchestration, car nous devons désormais trouver non seulement des talents en automatisation, mais des talents en automatisation dotés d’une certaine expertise dans cinq modèles d’infrastructure réseau différents ou plus. Le niveau d’expertise requis exige souvent également des connaissances du domaine, allant de la compréhension rudimentaire de la configuration et du routage VLAN aux relations entre les serveurs virtuels, les adresses IP virtuelles, les nœuds, les membres et les pools.

Exposer la complexité sous-jacente de l’infrastructure nuit à l’encouragement de l’adoption et à l’activation de l’automatisation. L’objectif des interfaces devrait être d’abstraire les modèles et la logique pour protéger les utilisateurs et les opérateurs de leur complexité. L'interface graphique fait cela en éliminant le besoin de parcourir les hiérarchies d'objets pour configurer un service simple.

C’est pourquoi il est souvent frustrant de constater que l’API a réintroduit ce cauchemar de navigation.

Ce problème n’est pas propre aux infrastructures réseau et applicatives.  En effet, MuleSoft, dans son étude « The Rising Value of APIs », a constaté que la demande la plus forte (47 % des répondants) de la part des clients et des partenaires pour l'intégration d'API concernait « des API personnalisées qui répondent à un besoin commercial spécifique ». Derrière cela se cachent une meilleure documentation (19 %), des modèles d'intégration « sans code » (19 %) et des wrappers SDK pour les API dont ils ont besoin et qu'ils utilisent (13 %).

Tout cela peut se résumer en un plaidoyer en faveur de la simplification. Et en technologie, simplification signifie abstraction.

Et cela nous amène au point de cet article, à savoir que les interfaces déclaratives sont cette abstraction. En simplifiant les interfaces utilisées pour provisionner, configurer, gérer et intégrer l'infrastructure aujourd'hui, les interfaces déclaratives démocratisent l'infrastructure et ouvrent des opportunités. 

Déclaratif versus impératif

D’une manière générale, les API déclaratives et impératives peuvent être considérées comme des types d’API. Les API impératives sont celles auxquelles vous pensez lorsque quelqu'un parle d'API. Elles indiquent au système cible exactement comment faire quelque chose. Si vous souhaitez ajouter un serveur virtuel, vous devez lui indiquer exactement comment procéder, même si cela nécessite cinq, dix ou plus d'appels d'API distincts.

Cela signifie lui dire de créer un objet spécifique avec les attributs appropriés, par exemple un nœud avec une adresse IP. Ensuite, vous devez indiquer séparément au système de créer le pool auquel il sera affecté, avec un nom. Alors il faut… eh bien, vous avez compris l’idée maintenant. Les API impératives imposent à leurs utilisateurs la tâche de comprendre non seulement le système et son modèle d'objet, mais également les étapes nécessaires pour atteindre les résultats escomptés.

C'est la taxe API que vous payez avec impératif.

Dans l’ensemble, les API impératives ne sont pas une mauvaise chose. Elles sont très importantes lorsque vous créez une interface graphique ou que vous intégrez d'autres systèmes qui ont besoin du type de granularité que vous obtenez avec une API impérative. Nous avons également besoin d'API impératives, mais pas pour les solutions d'automatisation et d'intégration NetOps et DevOps.

Mais pour le reste d’entre nous, nous n’avons pas besoin de connaître ce niveau de détail. En fait, exiger une telle profondeur de connaissances peut être décourageant et ralentir les efforts d’automatisation et d’orchestration. Cela ne se prête certainement pas à la démocratisation de l'infrastructure et à la mise en place de modèles de libre-service pour DevOps et les développeurs, sans parler de NetOps en dehors du domaine d'infrastructure spécifique.

C'est là que les API déclaratives entrent en jeu.

Les interfaces déclaratives précisent ce que vous voulez faire et laissent la logique et le flux de travail au système pour qu'il les détermine. Ainsi, plutôt que de demander spécifiquement au système de créer un nœud et un pool et d'exécuter toute la logique appropriée sur les objets requis, vous les décrivez ainsi que leurs relations.

Certaines interfaces déclaratives utilisent JSON, d'autres XML, et certaines se rabattent même sur des données de formulaire simples. Ce qu’ils ont tous en commun, c’est qu’ils supposent que les données décrivent les objets d’une manière simple et directe qui nécessite très peu de compréhension des modèles d’objets et des hiérarchies de systèmes.

Par exemple, cette déclaration est assez lisible par un humain. Cela suppose un niveau de base de compréhension du modèle d'objet, mais pas au point de nécessiter une certification dans un produit spécifique pour rédiger la déclaration : 

"web_pool": {
"classe": "Pool",
"moniteurs": [
"http"
],
"membres": [
{
"servicePort": 80,
"adresses du serveur": [
"192.0.1.10",
"192.0.1.11"
]
}
]
}

C'est là que la valeur des interfaces déclaratives devient évidente : dans la réduction des connaissances du domaine et de la complexité de l'approvisionnement et de la configuration de l'infrastructure. En réduisant le niveau d’expertise requis, non seulement NetOps peut travailler plus rapidement et plus efficacement, mais il peut désormais encourager DevOps et les développeurs à tirer parti de cette capacité.

L’adoption d’interfaces déclaratives comme méthode standard de gestion de l’infrastructure élargit immédiatement le vivier de talents dans lequel vous pouvez puiser pour fournir des capacités de libre-service et d’automatisation avancées. L'interface déclarative ci-dessus nécessite très peu d'explications pour que DevOps et les développeurs puissent la comprendre et l'utiliser. D’un autre côté, une interface impérative nécessiterait beaucoup plus d’attention pour apprendre le modèle et les flux de travail spécifiques à l’infrastructure avant de pouvoir espérer des résultats.

Les interfaces déclaratives démocratisent l’infrastructure en simplifiant le provisionnement, la configuration et la gestion nécessaires pour automatiser les pipelines de déploiement et intégrer les systèmes à d’autres services d’infrastructure. Et la démocratisation des infrastructures signifie une automatisation plus rapide et plus intelligente et la capacité d’encourager la collaboration et la coopération entre les domaines opérationnels nécessaires pour tirer parti des mouvements NetOps et DevOps.