La hiérarchie des besoins d’automatisation de Maslow
S’il y a quelque chose de plus en vogue que les conteneurs en ce moment, c’est probablement quelque chose basé sur les conteneurs, comme le sans serveur. En plus d’être le produit « cool » du moment, c’est aussi le centre d’attention de l’importance de l’automatisation et de l’orchestration* pour les applications modernes.
Presque chaque jour apporte un nouveau composant aux architectures de conteneurs et, avec lui, le niveau d’automatisation approprié. Si quelque chose peut être automatisé dans un monde de conteneurs, cela le sera. Une pléthore d’API et une dépendance aux artefacts basés sur la configuration/les modèles entraînent l’évolution quasi continue de l’automatisation dans les environnements basés sur des conteneurs. Si l’économie des API est importante pour la transformation numérique des entreprises, alors l’autre économie des API est essentielle à la transformation numérique de l’informatique.
Les environnements de conteneurs ne font pas exception et, à mesure qu'ils continuent de se frayer un chemin dans les environnements de production, il devient de plus en plus important pour les services en amont (N-S) non seulement de pouvoir fournir les applications mises à l'échelle et servies à partir de ces environnements hautement volatils, mais également de s'intégrer à eux au niveau des couches d'automatisation et d'orchestration.
C’est parce que certaines couches de cette « pile » technologique sont plus volatiles que d’autres. La création et la destruction de conteneurs, par exemple, se produisent beaucoup plus régulièrement que la création et/ou la destruction de clusters entiers. En effet, le rapport sur l'adoption de Docker du siège social de Data Dog indique que « en mars 2017, environ 40 % des clients de Datadog exécutant Docker utilisaient également Kubernetes , Mesos, Amazon ECS , Google Container Engine ou un autre orchestrateur ». L’automatisation/l’orchestration est essentielle au succès du conteneur, en particulier à son cœur. Cela signifie qu'à mesure que nous avançons, il est impératif que certains besoins d'automatisation soient satisfaits aussi rapidement (et complètement) que possible, car ils constituent la base de tout le reste.
Ceci est également vrai pour les environnements cloud. Ce n’est pas seulement la volatilité qui motive le besoin d’automatisation et d’orchestration, après tout, c’est aussi l’agilité. Le modèle complexe de « libre-service » associé au cloud computing exige une automatisation pour prendre en charge la notion d’architectures élastiques à la demande du cloud computing au sein d’un modèle informatique utilitaire. Il existe un ensemble identifiable de besoins d’automatisation communs au cloud et aux conteneurs qui posent les bases de la compréhension de sa valeur pour l’entreprise.
Tout comme la hiérarchie des besoins de Maslow, la hiérarchie des besoins d’automatisation repose sur le principe selon lequel il existe des besoins « déficients » qui doivent être satisfaits afin de progresser vers des besoins d’ordre supérieur qui permettent la croissance.
Il faut satisfaire les besoins déficitaires de niveau inférieur avant de progresser vers les besoins de croissance de niveau supérieur. Lorsqu’un besoin déficitaire est satisfait, il disparaît et nos activités deviennent habituellement orientées vers la satisfaction de la prochaine série de besoins que nous n’avons pas encore satisfaits. Ceux-ci deviennent alors nos besoins saillants. Cependant, les besoins de croissance continuent de se faire sentir et peuvent même devenir plus forts une fois qu’ils ont été satisfaits. Une fois ces besoins de croissance raisonnablement satisfaits, on peut être en mesure d'atteindre le niveau le plus élevé appelé réalisation de soi. -- https://www.simplypsychology.org/maslow.html
À la base, cette hiérarchie particulière des besoins d’automatisation se concentre sur les besoins fondamentaux liés à la mise à l’échelle des applications et de leurs services composites. Comme l'explique l'ingénieur très talentueux de F5 qui a présenté ce concept pour la première fois : « L’automatisation à la base est la plus précieuse car elle se produit le plus souvent et est essentielle pour qu’une application reste en ligne. L'automatisation au sommet est la moins précieuse car elle se produit moins fréquemment (peut-être seulement « une fois ») et se produit au même moment où de nombreuses personnes effectuent déjà des tâches manuelles.
Il s’agit des besoins « de base » de l’automatisation de la création/destruction de conteneurs/machines virtuelles et d’applications, essentiels non seulement pour l’évolutivité mais aussi pour l’efficacité de l’évolutivité. Cette efficacité est importante pour limiter les coûts et alléger le fardeau des économies d’échelle traditionnellement imposé aux opérations manuelles (coûteuses). Étant donné le volume et la fréquence avec lesquels de tels événements se produisent aujourd’hui, l’automatisation est une exigence et non un atout. Il s’agit d’un besoin déficitaire , ce qui signifie que s’il n’est pas satisfait, il n’y a guère de raison de s’inquiéter d’une automatisation d’ordre supérieur, moins fréquente.
Cela est particulièrement vrai pour les conteneurs, et semble à nouveau validé par Data Dog lorsqu'il note que « les conteneurs ont une durée de vie moyenne de 2,5 jours, tandis que dans toutes les entreprises, les machines virtuelles traditionnelles et basées sur le cloud ont une durée de vie moyenne de 23 jours ». Il semble que cela soit dû à l’automatisation. « Dans les organisations exécutant Docker avec un orchestrateur, la durée de vie typique d'un conteneur est inférieure à un jour. Dans les organisations qui exécutent Docker sans orchestration, le conteneur moyen existe pendant 5,5 jours.
La capacité d'automatiser la création/destruction de conteneurs et par la suite d'applications est impérative pour atteindre la vitesse et l'agilité d'échelle nécessaires aux organisations pour récolter les avantages des conteneurs dans les environnements traditionnels et basés sur le cloud.
Les besoins d’automatisation d’ordre supérieur sont en grande partie des besoins de routage et relèvent de ce que l’on appelle des besoins de croissance. Les besoins de croissance sont recherchés une fois que les besoins de base (carences) ont été satisfaits. La création/destruction de clusters et les modifications de routage se produisent rarement et ne deviennent utiles qu'une fois l'application en place et capable d'évoluer. Cela devient impératif une fois que l'environnement migre du développement/test vers un environnement de production et qu'il est censé fournir de la valeur commerciale en proposant des applications. Après tout, rediriger vers une application qui ne peut pas répondre, c'est comme faire un câlin à un homme affamé. Cette sensation de chaleur et de confort ne répond pas au besoin fondamental de nourriture. Une enquête réalisée en 2016 par Mesosphere auprès de ses utilisateurs a révélé que 62 % d'entre eux utilisaient déjà des conteneurs dans des environnements de production. Une enquête Portworx réalisée en 2017 lors de la conférence DockerCon consacrée aux conteneurs a révélé que 67,2 % des personnes interrogées utilisaient des conteneurs en production. Ce qui signifie que les besoins de routage deviennent rapidement importants, au moins pour le sous-ensemble des organisations adoptant des conteneurs.
L’objectif ultime de l’auto-réalisation de l’entreprise – la croissance – ne peut être atteint tant que l’ensemble de la hiérarchie n’est pas rempli, c’est-à-dire tant que l’ensemble de la « pile » n’est pas automatisé et orchestré. Il devrait donc être évident que ceux qui vivent principalement sur le plan de données NS orchestreront de bas en haut, en permettant d'abord les besoins de mise à l'échelle de l'environnement et en remontant jusqu'aux besoins de routage, où la transition du trafic NS vers le trafic EW a lieu. Cela est également évident dans le développement continu de l’écosystème plus étroitement couplé autour des orchestrateurs de conteneurs eux-mêmes, tels que Kubernetes. L’un des développements les plus récents s’est concentré sur les besoins de « routage » avec l’inclusion de contrôleurs d’entrée qui acheminent au niveau de la couche 7 (URI / API) pour garantir que la transition NS vers les services EW se déroule de manière transparente. Ce composant doit également être intégré (automatisé) à terme pour satisfaire les besoins de routage et continuer à propulser les organisations vers le haut de la hiérarchie pour réaliser leur croissance.
La traduction de ces éléments en constructions spécifiques aux conteneurs nous permet de mapper les besoins d’automatisation de l’environnement des conteneurs aux services du réseau qui prennent en charge son besoin d’évolutivité pour réaliser la croissance. Les constructions de conteneurs et de services réseau/application nécessitent toutes deux une automatisation. Créer une centaine de conteneurs pour faire évoluer une application sans automatiser simultanément les services chargés de les gérer lors de la livraison génère des besoins insatisfaits. Ces constructions de réseau peuvent exister soit sous forme de constructions de conteneurs natives, soit sous forme de services d'application existants adaptés pour s'intégrer nativement dans l'environnement du conteneur. Les détails de mise en œuvre varient en fonction de l'architecture et des exigences opérationnelles, bien que l'existence des deux ensembles de constructions soit nécessaire pour satisfaire les besoins de base (échelle) et de croissance (routage) pour réussir.
Dans tous les cas, le succès des conteneurs et du cloud dépend fortement de leurs écosystèmes et cela signifie qu'il faut s'appuyer sur l'économie des autres API pour permettre l'automatisation et l'orchestration essentielles à la croissance de l'entreprise grâce à des initiatives de transformation numérique.
* Je trouve frustrant que les concepts d’ automatisation et d’orchestration semblent être confondus dans le monde des conteneurs, juxtaposant l’un à l’autre. Mais pour l'instant, ignorons cela et j'essaierai de garder le pédant à l'intérieur là où il appartient. Dans ma tête. Hurlement. Désespérément.