Pourquoi un modèle déclaratif est-il important pour l’automatisation NetOps ?

Si vous souhaitez automatiser toutes les choses, vous devrez opter pour une approche déclarative. Voici pourquoi.

Nous martelons le tambour déclaratif depuis un certain temps dès que nous parlons d’automatisation, notamment en ce qui concerne NetOps et les services applicatifs. Mais nous n’avons pas encore vraiment étudié pourquoi c’est important et quels sont les avantages. J’ai l’intention de rectifier cela dès maintenant.

Pour vous rafraîchir la mémoire, il existe actuellement deux modèles utilisés pour automatiser la configuration et le déploiement de... tout.

La première est impérative, dans laquelle nous disons au système cible exactement comment faire ce que nous voulons faire. Si vous avez déjà ouvert un tunnel SSH vers un système et saisi un ensemble spécifique de commandes sur la CLI, vous avez utilisé le modèle impératif de configuration.

La deuxième (et préférée) est déclarative, dans laquelle nous disons au système cible ce qu'il doit faire, mais pas comment. Il s’agit du modèle adopté par la plupart des solutions d’automatisation de réseau pour un certain nombre de raisons, la plus importante étant le coût et le temps considérables nécessaires pour apprendre et intégrer les centaines d’appareils et de systèmes possibles qui pourraient se trouver dans un environnement donné.

Ainsi, dans un modèle impératif, nous devons spécifier chaque commande (ou appel d'API) requise pour configurer un système. Dans un modèle déclaratif, nous spécifions simplement des paires clé-valeur (généralement) qui décrivent ce que nous voulons et laissons un autre système s'occuper des commandes pour y parvenir.

C'est facile, il suffit de presser un citron.

Maintenant, répondons à la question : pourquoi cela est-il important ? L’adoption d’un modèle déclaratif présente quatre avantages principaux lorsque vous souhaitez automatiser toutes les tâches.

1. Réduire les erreurs humaines

Nous savons qu’environ 22 % des pannes de production sont dues à des erreurs humaines. Certains incidents assez médiatisés, que je n’évoquerai pas encore une fois, ont été directement attribués à une simple erreur humaine. Dans un modèle impératif, reposant sur des appels d’API, chacun d’eux est un incident potentiel qui attend de se produire. Si vous n’avez pas vérifié une variable, ou oublié de vérifier un code d’erreur, ou une centaine d’autres scénarios possibles, vous pouvez rencontrer un événement générateur de CV. C’est une mauvaise chose.

Un modèle déclaratif est basé sur un modèle ou un fichier de configuration d'un certain type qui sera analysé et validé avant que les appels d'API ne soient utilisés pour s'exécuter. Bien que vous puissiez certainement toujours gâcher un fichier de configuration ou un modèle, les possibilités de le faire sont limitées car vous réduisez le code requis. Et moins de code signifie généralement moins d’opportunités de faire une erreur.

2. Réduire la dette technique

La dette technique est cette métaphore amusante que nous avons reprise du développement et qui nous rappelle le coût à long terme de nos choix. La dette technique augmente avec les modèles impératifs de plusieurs manières. Tout d’abord, il y a le couplage des scripts à l’API de notre système cible. Il est peu probable que cette API prenne en charge autre chose , ce qui signifie que nous développons des scripts pour chaque système. Les étapes de configuration varieront probablement également d’une application à l’autre : tout n’est pas HTTP et toutes les applications basées sur HTTP ne nécessitent pas exactement la même configuration de service. Nous créons désormais des scripts pour chaque application et chaque système. Cela représente beaucoup de scénarios et beaucoup de dettes qui s'accumulent à cause de ce choix.

À l’inverse, une méthode déclarative peut utiliser le même script de processus de déploiement et le même système. Bien que le modèle/la configuration soit probablement toujours spécifique à l’application et au système, il s’agit d’un fichier unique. Il élimine la complexité et le nombre de scripts et réduit ainsi considérablement la dette technique. La réalité est qu’il y aura toujours une certaine dette engendrée par nos choix ; la minimiser est l’objectif. 

3. Éliminer les conflits de versions

Lorsque vous liez vos processus de configuration et de déploiement à une API, vous êtes lié à cette version de l'API. Il existe de nombreuses communautés sur Internet avec des développeurs hostiles et en colère qui dénoncent les modifications apportées à une API et le travail nécessaire pour modifier leur application. La même chose peut se produire (et se produira) avec les services réseau et applicatifs. Donc, si vous êtes lié à une version de l'API et que quelque chose change, devinez quoi ? Vous allez mettre à jour (ou peut-être réécrire) des scripts jusqu'à la fin des temps*.

Mais si vous avez adopté un modèle déclaratif, vous pourrez probablement ignorer toute modification apportée à l'API. Après tout, vous n'utilisez pas l'API pour indiquer au système comment déployer un service, vous lui indiquez simplement ce qui doit être déployé.

4. Réduire les exigences en matière d'expertise du domaine

Soyons réalistes, si je souhaite utiliser une API pour un réseau ou un service d’application, je dois comprendre le système. Si vous ne connaissez pas la différence entre une IP virtuelle et un serveur virtuel, eh bien, vous êtes déjà dans le pétrin et nous avons à peine abordé la question des nœuds par rapport aux membres. Les méthodes impératives basées sur l'API nécessitent que vous compreniez suffisamment le système cible pour naviguer dans sa configuration.

En utilisant un modèle déclaratif, vous avez besoin de moins d’expertise dans le système cible, ce qui signifie que les développeurs et DevOps sont plus susceptibles de pouvoir utiliser la méthode pour gérer eux-mêmes les applications. Bien sûr, vous aurez toujours besoin d’experts, mais les exigences envers les consommateurs de services sont réduites et la charge de provisionnement et de déploiement est répartie sur un ensemble plus large de parties prenantes.

Il existe d’autres raisons pour lesquelles vous souhaiteriez adopter un modèle déclaratif pour vos efforts d’automatisation NetOps, mais ces quatre-là sont les plus convaincantes. C’est parce qu’ils profitent à NetOps, à l’entreprise et à l’élargissement des groupes qui ont besoin d’un accès en libre-service au réseau et aux services d’application qui rendent les applications plus rapides et plus sûres.