La marchandisation des opérations
Autrefois, les transmissions des voitures étaient manuelles. Certains les auraient appelés « bâtons » en raison du mécanisme par lequel on changeait de vitesse. À cette époque, une transmission automatique était quelque chose de spécial qu'il fallait souvent commander. Son nom vient de la façon dont la voiture change automatiquement les vitesses pour vous. Ce qui, pour être honnête, est plutôt sympa. Après tout, il y a beaucoup de variables à gérer lorsque vous essayez de changer de vitesse manuellement.
Aujourd’hui, les transmissions automatiques sont la norme. Le manuel est un mystère pour la plupart. J’ai essayé d’apprendre à chacun de mes trois enfants les plus âgés à en conduire un. Je ne vous recommande pas de tenter cette expérience, si vous l'envisagez. Pas si vous aimez une transmission fonctionnelle dans votre voiture.
Je mentionne ce changement dans les attentes et les normes comme prélude à une discussion sur les opérations. Il s'agit principalement de l'infrastructure des services réseau et applicatif, mais cela est également vrai en dehors de ces domaines.
Attentes opérationnelles
L’évolution se fait vers l’automatisation, certes, mais c’est aussi un changement dans les attentes concernant les connaissances requises pour exploiter l’infrastructure.
Pour revenir à mon analogie avec la transmission, si vous conduisez une transmission manuelle, vous avez beaucoup de variables à gérer. Il faut coordonner l'embrayage et l'accélérateur. Vous devez écouter le moteur et savoir quand changer de vitesse. Il faut également savoir dans quel rapport vous êtes, dans quel rapport vous allez et comment déplacer le « manche » pour y arriver.
Ils reflètent les types de connaissances dont vous avez besoin pour déployer manuellement l’infrastructure de services réseau et d’application. Vous devez en savoir beaucoup sur le fonctionnement du réseau afin de garantir que le trafic passe d’un endroit à un autre.
L’adoption du cloud a amorcé la transition des attentes par rapport à cette « norme ». Même si vous devez encore comprendre certains concepts de base du réseau, vous n’êtes pas nécessairement obligé de comprendre leur fonctionnement. Avec l'introduction des conteneurs, les attentes se sont déplacées encore plus vers la droite, avec peu ou pas d'obligation de penser aux adresses IP.
Cela a pour effet de modifier les attentes opérationnelles. Nous passons d’une économie d’opérations expertes à une économie d’opérations marchandisées . Aujourd’hui, les aspects opérationnels du déploiement de l’infrastructure des services réseau et applicatifs devraient être accessibles à un ensemble plus large de rôles au sein de l’organisation. Pour y arriver, la simplification est nécessaire.
Pour être plus précis, une simplification opérationnelle . Il ne suffit pas de fournir des services réseau et applicatifs via des options en libre-service, il faut que ces services soient utilisables par ceux qui les utiliseront. Cela doit être encore plus simple que maintenant.
Cela peut signifier sacrifier la configurabilité au profit de l'opérabilité.
Configurabilité versus opérabilité
Comme pour le cloud et les conteneurs, les abstractions posées sur l’infrastructure des services réseau et applicatifs s’étendent à l’utilisation de ces abstractions. Je veux dire par là la langue vernaculaire. La terminologie. Le modèle de données. La configuration actuelle .
Ce que je veux dire par là, pour les non-programmeurs qui lisent, c'est que chaque construction a un ensemble d'attributs qui lui sont associés et qui constituent « l'objet ». Un objet Serveur Virtuel possède une adresse IP, un pool d’applications, des événements, un nom et tout un tas d’autres caractéristiques. Certaines de ces caractéristiques sont en fait des objets – ou des listes d’objets. Traverser ces constructions peut être complexe. Parce que la configurabilité est impérative lors du réglage fin de l’infrastructure. Vous souhaitez pouvoir modifier des caractéristiques très spécifiques (comme activer l'algorithme de Nagle ou modifier la taille de la fenêtre TCP) pour optimiser les performances ou la capacité.
Désormais, dans un modèle d’opérations standardisé – vers lequel nous nous dirigeons – l’opérabilité est plus importante que la configurabilité. Moins d'options, une disponibilité plus rapide.
Mais cela ne signifie pas simplement supprimer des options. Le simple fait d’éliminer la possibilité de modifier les options ne répond qu’aux exigences de base en matière d’opérabilité ; il ne répond pas aux attentes d’une expérience opérationnelle simplifiée. Vous devez encore comprendre le modèle d’objet. Ce qui est nécessaire, c'est d'abstraire le modèle en quelque chose de plus simple. Disons, réduisez un serveur virtuel à une adresse IP, un nom et une liste d’instances d’application.
La marchandisation nécessite la standardisation
Il s’agit d’une tâche importante car il n’existe pas de modèle commun sur lequel fonctionne l’infrastructure des services d’application. La manière dont les serveurs virtuels, le contrôle d'accès et les politiques de sécurité sont représentés varie d'un produit à l'autre, d'un service à l'autre.
Les opérations, qu'elles soient du côté du développement ou du côté informatique, doivent en effet comprendre une multitude de modèles afin de déployer et d'exploiter les quatorze services d'application en moyenne utilisés pour fournir et sécuriser les applications . Il existe de nombreuses variations, ce qui a conduit par le passé à la création d’une multitude de certificats nécessaires pour vérifier l’expertise requise pour gérer ces services.
L’autre changement opérationnel s’éloigne de cette approche. Il s’agit d’une attente de simplicité, de facilité d’utilisation et de communité entre les offres afin de réduire la dette technique engendrée par les modèles d’exploitation spécifiques à chaque appareil. Il s’agit d’une attente de normalisation ; pas sur les protocoles et le comportement du réseau, qui existe déjà dans l’espace de l’infrastructure réseau. Mais comment représentons-nous ces protocoles et ces comportements réseau.
Nous constatons ce phénomène dans les enquêtes sur la conteneurisation , dans lesquelles les compétences nécessaires sont citées comme un obstacle majeur à l’adoption par près d’un répondant sur quatre (24 %), tandis que 33 % ont déclaré qu’il s’agissait d’un obstacle modéré. L'infrastructure - dans laquelle les conteneurs et les systèmes d'orchestration de conteneurs sont certainement inclus compte tenu de leur prévalence dans les environnements de production actuels - est motivée par un manque de compétences et un désir de rapidité vers des opérations standardisées.
Ce désir et ce besoin se manifestent dans l’adoption organique des fichiers de ressources Kubernetes qui tentent de décrire lesdits services d’infrastructure. Ces ressources imposent à toutes les opérations l’utilisation d’un modèle de données (format) commun (marchandisé) pour décrire le déploiement et la configuration d’un service donné. Étant donné que les opérations informatiques sont le premier moteur de l'adoption des conteneurs (35 %) dans les organisations d'aujourd'hui (selon l'enquête 2019 de Diamanti sur l'adoption des conteneurs ) - près de deux fois plus influentes que les développeurs (16 %) et quatre fois plus que les équipes DevOps intégrées (9 %) - il est important de reconnaître ce changement et d'examiner attentivement la manière dont la nouvelle infrastructure s'intègre (ou ne s'intègre pas) dans un environnement opérationnel standardisé.
Avec ou sans efforts officiels (groupes de travail ou fondations), la marchandisation introduira une norme de facto dans les opérations. Et cette norme de facto sera celle qui mettra l’accent sur l’opérabilité plutôt que sur la configurabilité .