Au royaume des conteneurs, la configuration déclarative est reine

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

La transformation numérique interne est essentielle pour permettre la transformation numérique externe. L’un des piliers de la transformation numérique interne est l’automatisation, qui repose en grande partie sur le plan de contrôle. Le plan de contrôle est l’espace où s’opère l’automatisation. Aux débuts de l’informatique, nous l’appelions le « réseau de gestion » et utilisions des protocoles tels que SNMP pour assurer la surveillance, la configuration et le contrôle.

Aujourd’hui, le réseau de gestion existe toujours, du moins en théorie, en tant que support sur lequel nous effectuons les mêmes tâches par l’intermédiaire du plan de contrôle. Le plan de contrôle est un univers complexe composé d’API, de nœuds maîtres et même de files d’attente de messages, qui permettent aux différents composants d’un système distribué complexe de se gérer eux-mêmes de manière (presque) automatique. Il repose de plus en plus sur les événements, ce qui exige de rompre avec les anciens modèles centralisés de commande et de contrôle, qui s’appuyaient principalement sur des modèles de gestion impératifs. Autrement dit, un système central donne implicitement des instructions aux composants au moyen d’appels d’API spécifiques qui déclenchent des changements. À l’inverse, les environnements actuels reposent sur des modèles déclaratifs qui répartissent entre les composants la responsabilité de se modifier eux-mêmes.

Ce phénomène n’est nulle part plus manifeste que dans les environnements conteneurisés. Vus de l’extérieur, ces systèmes semblent presque livrés à eux-mêmes : messages et événements sont publiés et déclenchés à tout-va, sans autorité centrale pour déterminer qui ou quoi doit y réagir. Le plan de contrôle ne relève désormais plus tant du contrôle que de la distribution au sein d’un plan qui s’apparente davantage à un maillage qu’aux architectures en étoile des systèmes de gestion d’autrefois. Dans le monde traditionnel, nous utilisions des API et des protocoles pour transmettre les changements aux composants. Dans le monde numérique et conteneurisé, nous utilisons des API pour récupérer les informations nécessaires afin qu’un composant puisse se modifier lui-même.

Ce nouveau monde est réactif et délaisse le modèle impératif (piloté par API) du plan de contrôle traditionnel, au profit d’un modèle déclaratif plus ouvert permettant d’atteindre l’état final automatisé souhaité.

Cela n’a rien de surprenant. À mesure que nous avons adopté une approche de plus en plus pilotée par logiciel dans tous les domaines (sous la bannière du DevOps, du cloud et de la NFV), nous avons dû simultanément faire face à une échelle opérationnelle considérable. Un modèle de gestion impératif en étoile ne passe pas efficacement à l’échelle, car toutes les modifications reposent sur un contrôleur central capable de communiquer, au moyen d’un éventail déroutant d’API, avec un nombre presque illimité de composants. Il s’agit d’un modèle « push », dans lequel le gestionnaire (contrôleur) transmet les modifications à chaque composant concerné. Il devient alors le goulot d’étranglement dont dépend la réussite ou l’échec de l’ensemble du système.

Un modèle piloté par les événements, reposant sur la récupération des données par les composants, est nécessaire pour passer à l’échelle et alléger la charge du contrôleur. Cela suppose que les composants souhaitant participer à ce plan de contrôle soient à l’aise avec un modèle de configuration déclaratif. En effet, au lieu de transmettre les changements via une API (approche impérative), les conteneurs nous amènent à les récupérer au moyen de configurations déclaratives. Il incombe aux fournisseurs de composants, qu’ils soient open source ou commerciaux, de s’abonner correctement aux changements, puis de récupérer les informations nécessaires pour les appliquer immédiatement.

Si cela évoque l’infrastructure en tant que code, c’est tout à fait normal. Les configurations déclaratives sont essentiellement du code, ou du moins des artefacts de code. L’automatisation repose de plus en plus sur ce principe, qui dissocie la configuration du service auquel elle se rapporte. Dans un modèle utopique idéal, ces configurations déclaratives seraient totalement indépendantes des solutions utilisées. Autrement dit, elles pourraient être interprétées par n’importe quel produit de n’importe quel fournisseur, qu’il soit commercial ou open source, dès lors qu’il prend en charge le service concerné. Par exemple, une configuration déclarative décrivant le service approprié (serveur virtuel) et les applications qui composent son pool de ressources pourrait être assimilée et mise en œuvre aussi bien par le service X que par le service Y.

Les fichiers de ressources Kubernetes constituent un bon exemple de modèle de configuration déclarative dans lequel on décrit ce que l’on souhaite obtenir, sans jamais préciser comment y parvenir. Cette approche diffère nettement de celle des systèmes qui s’appuient sur des API d’infrastructure et dont la mise en œuvre exige de connaître – parfois dans les moindres détails – la manière d’obtenir les résultats souhaités.

Le modèle déclaratif permet également de traiter l’infrastructure comme du bétail. Si une instance tombe en panne, il suffit de la supprimer et d’en lancer une nouvelle. Toute la configuration dont elle a besoin se trouve dans le fichier de ressources ; il n’y a pas de bouton « Enregistrez votre travail, sinon il sera perdu », car il n’y a aucun travail à perdre. Cette infrastructure est presque immuable et résolument jetable ; elle est indispensable dans les systèmes qui évoluent de minute en minute, voire de seconde en seconde, afin de réduire au minimum l’impact des défaillances.

À mesure que nous évoluons vers des systèmes à grande échelle toujours plus automatisés et — oserais-je l’avancer ? — plus sécurisés, nous devrons adopter des modèles déclaratifs pour gérer la myriade d’appareils et de services qui composent le chemin des données applicatives, sous peine d’être ensevelis sous une avalanche de dette opérationnelle engendrée par des méthodes manuelles d’intégration et d’automatisation.

À 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