La marchandisation des opérations

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

Autrefois, les voitures étaient équipées de boîtes de vitesses manuelles. Certains les appelaient parfois « boîtes à levier », en référence au mécanisme utilisé pour changer de vitesse. À l’époque, une boîte automatique était un équipement particulier qu’il fallait souvent commander en option. Son nom vient du fait que la voiture changeait automatiquement de vitesse à votre place. Ce qui, à vrai dire, est plutôt appréciable. Après tout, il faut gérer de nombreux paramètres lorsqu’on essaie de changer de vitesse manuellement.

Aujourd’hui, les boîtes automatiques sont devenues la norme. Pour la plupart des gens, les boîtes manuelles restent un mystère. J’ai essayé d’apprendre à chacun de mes trois aînés à en conduire une. Si vous envisagez de faire de même, je vous le déconseille. Du moins, si vous tenez à ce que la boîte de vitesses de votre voiture reste en état de marche.

J’évoque cette évolution des attentes et des normes en guise de préambule à une réflexion sur les opérations, principalement celles liées à l’infrastructure des réseaux et des services applicatifs, même si ce constat vaut également au-delà de ces domaines.

Attentes opérationnelles

La transition se fait certes vers l’automatisation, mais elle concerne également les attentes quant aux connaissances requises pour exploiter l’infrastructure.

Pour reprendre mon analogie avec la boîte de vitesses, si vous conduisez un véhicule équipé d’une boîte manuelle, vous devez gérer de nombreux paramètres. Vous devez coordonner l’embrayage et l’accélérateur. Vous devez écouter le moteur et savoir quand changer de vitesse. Vous devez également savoir quel rapport est engagé, lequel vous souhaitez engager et comment déplacer le « levier de vitesses » pour y parvenir.

Cela correspond aux types de connaissances nécessaires pour déployer manuellement une infrastructure de services réseau et applicatifs. Vous devez très bien comprendre le fonctionnement du réseau afin de garantir que le trafic soit acheminé d’un point à un autre.

L’adoption du cloud a commencé à faire évoluer les attentes en les éloignant de cette « norme ». S’il reste nécessaire de comprendre certains concepts réseau de base, il n’est pas indispensable de savoir précisément comment ils fonctionnent. Avec l’arrivée des conteneurs, les attentes se sont encore davantage déplacées vers la droite, au point qu’il n’est pratiquement plus nécessaire de se préoccuper des adresses IP.

Cela modifie les attentes en matière d’exploitation. Nous passons d’une économie fondée sur une exploitation experte à une économie fondée sur une exploitation banalisée. Aujourd’hui, les aspects opérationnels du déploiement des infrastructures de services réseau et applicatifs doivent être accessibles à un plus large éventail de fonctions au sein de l’organisation. Pour y parvenir, une simplification est nécessaire.

Plus précisément, une simplification opérationnelle. Il ne suffit pas de proposer des services réseau et applicatifs en libre-service : ils doivent être faciles à utiliser par celles et ceux qui vont effectivement s’en servir. Leur utilisation doit être encore plus simple qu’elle ne l’est aujourd’hui.

Cela peut impliquer de sacrifier la configurabilité au profit de la facilité d’exploitation.

Configurabilité ou exploitabilité

Comme pour le cloud et les conteneurs, les abstractions superposées à l’infrastructure des services réseau et applicatifs s’étendent à l’utilisation même de ces abstractions. J’entends par là le langage employé. La terminologie. Le modèle de données. La configuration proprement dite.

Pour les lecteurs qui ne sont pas programmeurs, cela signifie que chaque structure possède un ensemble d’attributs associés qui constituent l’« objet ». Un objet Serveur virtuel possède une adresse IP, un pool d’applications, des événements, un nom et de nombreuses autres caractéristiques. Certaines de ces caractéristiques sont elles-mêmes des objets, ou des listes d’objets. Parcourir ces structures peut s’avérer complexe. Car la configurabilité est essentielle pour ajuster précisément l’infrastructure. Il faut pouvoir modifier des caractéristiques très spécifiques — par exemple activer ou désactiver l’algorithme de Nagle, ou encore ajuster la taille de la fenêtre TCP — afin d’optimiser les performances ou la capacité.

Désormais, dans un modèle d’exploitation standardisé — et c’est vers cela que nous nous dirigeons — la facilité d’exploitation prime sur la configurabilité. Moins d’options, une mise en service plus rapide.

Mais cela ne signifie pas qu’il faille simplement supprimer des options. Le simple fait d’éliminer la possibilité de les ajuster ne répond qu’aux exigences de base en matière d’exploitabilité ; cela ne répond pas aux attentes d’une expérience d’exploitation simplifiée. Il faut toujours comprendre le modèle objet. Il est nécessaire d’abstraire ce modèle pour le rendre plus simple. Par exemple, réduire un serveur virtuel à une adresse IP, un nom et une liste d’instances d’application.

La banalisation exige une standardisation

Il s’agit d’une entreprise de grande envergure, car il n’existe aucun modèle commun sur lequel repose l’infrastructure des services applicatifs. La représentation des serveurs virtuels, du contrôle des flux entrants et des politiques de sécurité varie d’un produit à l’autre et d’un service à l’autre.

Les équipes opérationnelles, qu'elles interviennent côté développement ou côté informatique, doivent en pratique comprendre une multitude de modèles afin de déployer et d'exploiter les quatorze services applicatifs utilisés en moyenne pour fournir et sécuriser les applications. Les différences sont nombreuses, ce qui a conduit par le passé à la création d'une multitude de certifications visant à attester l'expertise nécessaire à la gestion de ces services.

L’autre évolution opérationnelle consiste à s’éloigner de cette approche. Elle traduit une attente de simplicité, de facilité d’utilisation et d’harmonisation entre les différentes offres, afin de réduire la dette technique engendrée par des modèles d’exploitation propres à chaque équipement. Il s’agit d’une attente de standardisation ; non pas des protocoles et des comportements réseau, qui existent déjà dans le domaine des infrastructures réseau, mais de la manière dont nous représentons ces protocoles et ces comportements réseau.

Cette tendance se confirme dans les enquêtes sur la conteneurisation, où près d’un répondant sur quatre (24 %) cite le manque de compétences requises comme un obstacle majeur à l’adoption, tandis que 33 % le considèrent comme un obstacle modéré. Sous l’effet de la pénurie de compétences et de la recherche de rapidité, l’infrastructure — qui englobe assurément les conteneurs et les systèmes d’orchestration de conteneurs, compte tenu de leur prévalence actuelle dans les environnements de production — évolue vers une banalisation des opérations.

Ce désir et ce besoin se manifestent par l’adoption spontanée de fichiers de ressources Kubernetes visant à décrire les services d’infrastructure en question. Ces ressources imposent à toutes les équipes d’exploitation l’utilisation d’un modèle (format) de données commun et standardisé pour décrire le déploiement et la configuration d’un service donné. Sachant que les opérations informatiques constituent aujourd’hui le principal moteur de l’adoption des conteneurs (35 %) au sein des organisations (selon l’enquête 2019 de Diamanti sur l’adoption des conteneurs) — avec une influence près de deux fois supérieure à celle des développeurs (16 %) et quatre fois supérieure à celle des équipes DevOps intégrées (9 %) —, il est important de prendre acte de cette évolution et d’examiner attentivement comment les nouvelles infrastructures s’intègrent (ou non) dans un environnement d’exploitation standardisé.

Avec ou sans initiatives officielles (de groupes de travail ou de fondations), la banalisation imposera de fait une norme dans les opérations informatiques. Et cette norme de fait privilégiera l’exploitabilité à la configurabilité.

À 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