Dans le monde des conteneurs, la configuration déclarative est reine
La transformation numérique à l’intérieur est essentielle pour permettre la transformation numérique à l’extérieur. L’un des composants fondamentaux de la transformation numérique interne est l’automatisation, qui repose fortement sur le plan de contrôle . Le plan de contrôle est l'endroit où l'automatisation se produit. À l’époque de l’informatique, nous l’appelions « réseau de gestion » et utilisions des protocoles comme SNMP pour assurer la surveillance, la configuration et le contrôle.
Aujourd’hui, le réseau de gestion existe toujours, du moins théoriquement, en tant que support sur lequel nous effectuons les mêmes tâches via le plan de contrôle. Le plan de contrôle est un terrain encombré d'API, de nœuds maîtres et même de files d'attente de messages qui permettent aux composants individuels d'un système distribué complexe de se gérer (presque) automatiquement. Elle est de plus en plus axée sur les événements, ce qui nécessite un changement de mentalité par rapport aux modèles de commandement et de contrôle centralisés du passé, qui reposaient principalement sur des modèles impératifs de gestion. Autrement dit, un système central donne des instructions implicites aux composants à l’aide d’appels d’API spécifiques qui provoquent des modifications. Les environnements d’aujourd’hui, en revanche, s’appuient sur des modèles déclaratifs qui répartissent la responsabilité de leur propre changement.
Dans aucun système cela n’est plus évident que dans les environnements conteneurisés. De l’extérieur, de tels systèmes semblent être presque de nature malveillante ; les messages et les événements sont publiés et déclenchés à volonté, sans aucun chef suprême pour déterminer qui ou quoi doit réagir à eux. Le plan de contrôle n’est plus tant une question de contrôle que de distribution sur un plan qui est davantage un maillage que les architectures en étoile des systèmes de gestion archaïques. Dans le monde traditionnel, nous utilisions des API et des protocoles pour appliquer des modifications aux composants. Dans le monde numérique et conteneurisé, nous utilisons des API pour extraire les informations nécessaires à un composant pour qu'il puisse se modifier.
Ce nouveau monde est réactif et évite le modèle impératif (piloté par API) du plan de contrôle traditionnel, s'appuyant plutôt sur un modèle déclaratif plus ouvert pour atteindre l'état final automatisé souhaité.
Cela n’est pas surprenant. Alors que nous adoptons de plus en plus une approche axée sur les logiciels pour tout (sous le nom de DevOps, Cloud et NFV), nous devons simultanément faire face à une échelle opérationnelle massive. Un modèle de gestion impératif en étoile n'est pas efficace car la charge de tous les changements repose sur un contrôleur central capable de communiquer via un ensemble déroutant d'API avec un groupe presque illimité de composants. Il s’agit d’un modèle « push », dans lequel le gestionnaire (contrôleur) pousse les modifications vers chaque composant affecté. Cela devient le goulot d’étranglement qui fait la réussite ou l’échec de l’ensemble du système.
Un modèle piloté par les événements qui s'appuie sur l'extraction par composants est nécessaire pour faire évoluer et alléger la charge sur le contrôleur, ce qui nécessite à son tour que les composants qui souhaitent participer à ce plan de contrôle soient à l'aise avec un modèle de configuration déclaratif. Car plutôt que de pousser les changements via une API (impératif), les conteneurs nous poussent à tirer les changements via des configurations déclaratives à la place. Il incombe aux fournisseurs de composants (qu'ils soient open source ou commerciaux) de souscrire correctement aux modifications, puis d'extraire les informations appropriées requises pour mettre en œuvre ces modifications immédiatement.
Si cela ressemble à une infrastructure en tant que code, c'est normal. Les configurations déclaratives sont essentiellement du code, ou du moins des artefacts de code. L’automatisation dépend de plus en plus de son principe qui dissocie la configuration de son service. Dans un modèle utopique idéal, ces configurations déclaratives sont complètement agnostiques. Autrement dit, ils seraient lisibles par n’importe quel produit de n’importe quel fournisseur (commercial ou open source) prenant en charge ce service. Par exemple, une configuration déclarative décrivant le service approprié (serveur virtuel) et les applications qui compromettent son pool de ressources pourrait être ingérée par le service X ou le service Y et implémentée.
Les fichiers de ressources Kubernetes sont un bon exemple de modèle de configuration déclaratif dans lequel ce qui est souhaité est décrit, mais nulle part comment cela est prescrit. Cela diffère sensiblement des systèmes qui s’appuient sur des API d’infrastructure qui nécessitent que l’implémentation soit familière – parfois intimement – avec la manière d’obtenir les résultats souhaités.
Le modèle déclaratif permet également de traiter les infrastructures comme du bétail. Si l’une d’entre elles échoue, il est simple de la tuer et de lancer une nouvelle instance. Toute la configuration nécessaire se trouve dans le fichier de ressources ; il n’y a pas de bouton « enregistrer votre travail ou il sera perdu » car il n’y a aucun travail à perdre. Il s’agit d’une infrastructure quasiment immuable et définitivement jetable, et c’est une nécessité dans les systèmes qui changent à chaque minute, voire à chaque seconde, pour minimiser l’impact d’une défaillance.
À mesure que nous évoluons de plus en plus vers des systèmes automatisés à grande échelle et – oserais-je dire ? – sécurisés, nous devrons adopter des modèles déclaratifs pour la gestion de la myriade d’appareils et de services composant le chemin de données des applications, sinon nous risquons d’être ensevelis sous une avalanche de dettes opérationnelles résultant de méthodes manuelles d’intégration et d’automatisation.