La hiérarchie des besoins en automatisation de Maslow

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

S’il y a bien une technologie plus en vogue que les conteneurs à l’heure actuelle, c’est probablement une technologie qui repose sur eux, comme le serverless. En plus d’être la technologie « tendance » du moment, elle met également en lumière toute l’importance de l’automatisation et de l’orchestration* pour les applications modernes.

Presque chaque jour voit apparaître un nouveau composant dans les architectures de conteneurs et, avec lui, le niveau d’automatisation approprié. Dans l’univers des conteneurs, tout ce qui peut être automatisé le sera. Une multitude d’API et le recours à des artefacts basés sur des configurations ou des modèles favorisent l’évolution quasi continue de l’automatisation au sein des 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 se généralisent dans les environnements de production, il devient de plus en plus important que les services en amont (N-S) soient non seulement capables de fournir les applications mises à l’échelle et diffusées depuis ces environnements extrêmement volatils, mais aussi de s’y intégrer au niveau des couches d’automatisation et d’orchestration.

Cela s’explique par le fait 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 bien plus régulièrement que la création et/ou la destruction de clusters entiers. En effet, le rapport Docker Adoption de Data Dog HQ indique qu’« en mars 2017, environ 40 % des clients de Datadog utilisant Docker utilisaient également Kubernetes, Mesos, Amazon ECS, Google Container Engine ou un autre orchestrateur ». L’automatisation et l’orchestration sont essentielles à la réussite des conteneurs, en particulier au niveau de leur cœur. Cela signifie qu’à mesure que nous avançons, il est impératif de répondre aussi rapidement (et complètement) que possible à certains besoins d’automatisation, car ils constituent le socle de tout le reste.

Cela vaut également pour les environnements cloud. Après tout, le besoin d’automatisation et d’orchestration n’est pas seulement motivé par la volatilité, mais aussi par l’agilité. Le modèle complexe de « libre-service » associé au cloud computing exige une automatisation capable de prendre en charge ses architectures élastiques et à la demande, dans le cadre d’un modèle informatique de type service public. Il existe un ensemble identifiable de besoins en automatisation communs au cloud et aux conteneurs, qui permettent de mieux comprendre la valeur qu’elle apporte à l’entreprise.

À l’instar de la pyramide des besoins de Maslow, la hiérarchie des besoins en automatisation repose sur le principe qu’il existe des besoins « déficitaires » qui doivent être satisfaits avant de pouvoir progresser vers des besoins d’ordre supérieur favorisant la croissance.

Il faut satisfaire les besoins déficitaires de niveau inférieur avant de pouvoir répondre aux besoins de croissance de niveau supérieur. Lorsqu’un besoin déficitaire est satisfait, il disparaît, et nos activités s’orientent alors naturellement vers la satisfaction des besoins suivants qui ne le sont pas encore. Ceux-ci deviennent alors nos besoins prioritaires. Cependant, les besoins de croissance continuent de se faire sentir et peuvent même se renforcer une fois qu’ils ont été éveillés. Lorsque ces besoins de croissance ont été raisonnablement satisfaits, il devient possible d’atteindre le niveau le plus élevé, appelé accomplissement de soi. -- https://www.simplypsychology.org/maslow.html

Fondamentalement, cette hiérarchie particulière des besoins en automatisation se concentre sur les besoins essentiels liés à la mise à l’échelle des applications et des services qui les composent. Comme l’explique le très talentueux ingénieur de F5 qui a présenté ce concept pour la première fois : « L’automatisation située à la base est la plus précieuse, car c’est celle qui intervient le plus souvent et elle est essentielle pour qu’une application reste en ligne. L’automatisation située au sommet est la moins précieuse, car elle intervient moins fréquemment (peut-être même une seule “fois”) et se produit à un moment où de nombreuses personnes effectuent déjà des tâches manuellement. »

Il s’agit des besoins « fondamentaux » : l’automatisation de la création et de la suppression des conteneurs, des machines virtuelles et des applications est essentielle non seulement pour passer à l’échelle, mais aussi pour garantir l’efficacité de cette mise à l’échelle. Cette efficacité est importante pour maîtriser les coûts et alléger la charge que la mise à l’échelle fait traditionnellement peser sur des opérations manuelles (coûteuses). Compte tenu du volume et de la fréquence auxquels de tels événements se produisent aujourd’hui, l’automatisation est une nécessité, et non un simple atout. Il s’agit d’un besoin fondamental, ce qui signifie que s’il n’est pas satisfait, il est peu pertinent de se préoccuper d’automatisations de niveau supérieur et moins fréquentes.

Cela est particulièrement vrai pour les conteneurs, et semble une nouvelle fois confirmé par Data Dog, qui indique que « les conteneurs ont une durée de vie moyenne de 2,5 jours, tandis que, toutes entreprises confondues, les machines virtuelles traditionnelles et basées dans le cloud ont une durée de vie moyenne de 23 jours ». L’automatisation semble avoir une incidence sur ce phénomène. « Dans les entreprises qui exécutent Docker avec un orchestrateur, la durée de vie habituelle d’un conteneur est inférieure à une journée. Dans les entreprises qui exécutent Docker sans orchestration, la durée de vie moyenne d’un conteneur est de 5,5 jours. »

La capacité à automatiser la création et la destruction des conteneurs, puis des applications, est indispensable pour atteindre la rapidité et l’agilité nécessaires au passage à l’échelle, afin que les organisations puissent tirer parti des avantages des conteneurs, aussi bien dans les environnements traditionnels que dans le cloud.

Les besoins d’automatisation de niveau supérieur sont essentiellement des besoins de routage et relèvent de ce que l’on appelle les besoins de croissance. Les besoins de croissance se manifestent une fois que les besoins fondamentaux (liés aux carences) ont été satisfaits. La création et la suppression de clusters, ainsi que les modifications de routage, sont peu fréquentes et ne deviennent utiles qu’une fois l’application en place et capable de monter en charge. Cela devient impératif lorsque l’environnement passe du développement/test à la production et qu’il doit générer de la valeur pour l’entreprise en mettant des applications à disposition. Après tout, acheminer du trafic vers une application qui ne peut pas répondre revient à prendre dans ses bras un homme affamé. Cette sensation chaleureuse et réconfortante ne répond pas au besoin fondamental de nourriture. Une enquête mené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 menée en 2017 par Portworx lors de DockerCon, une conférence consacrée aux conteneurs a révélé que 67,2 % des personnes interrogées utilisaient des conteneurs en production. Cela signifie que les besoins de routage gagnent rapidement en importance, du moins pour les organisations qui adoptent les conteneurs.

L’objectif ultime de l’accomplissement de l’entreprise — la croissance — ne peut être atteint tant que l’ensemble de la hiérarchie n’est pas satisfait, autrement dit tant que l’intégralité de la « pile » n’est pas automatisée et orchestrée. Il va donc de soi que ceux qui évoluent principalement sur le plan de données N-S procéderont à une orchestration ascendante, en répondant d’abord aux besoins de mise à l’échelle de l’environnement, puis aux besoins de routage, là où s’effectue la transition du trafic N-S vers le trafic E-W. Cela se manifeste également dans le développement continu d’un écosystème plus étroitement intégré autour des orchestrateurs de conteneurs eux-mêmes, tels que Kubernetes. L’une des évolutions les plus récentes s’est concentrée sur les besoins de « routage » avec l’intégration de contrôleurs d’entrée qui assurent le routage au niveau de la couche 7 (URI/API), afin que la transition des services N-S vers les services E-W s’effectue de manière fluide. Ce composant devra lui aussi, à terme, être intégré (automatisé) afin de répondre aux besoins de routage et de continuer à faire progresser les entreprises dans la hiérarchie pour leur permettre d’atteindre la croissance.

La transposition de ce modèle en composants propres aux conteneurs nous permet de faire correspondre les besoins d’automatisation de l’environnement de conteneurs aux services réseau qui répondent à ses besoins de mise à l’échelle afin de favoriser la croissance. Les composants liés aux conteneurs comme ceux liés aux services réseau et applicatifs doivent être automatisés. Créer une centaine de conteneurs pour mettre une application à l’échelle sans automatiser simultanément les services chargés de les gérer lors de leur mise à disposition ne permet pas de répondre à l’ensemble des besoins. Ces composants réseau peuvent prendre la forme de composants natifs de l’environnement de conteneurs ou de services applicatifs existants adaptés pour s’y intégrer nativement. Les modalités de mise en œuvre varieront selon l’architecture et les exigences opérationnelles, mais ces deux ensembles de composants sont indispensables pour répondre aux besoins fondamentaux de mise à l’échelle et aux besoins de croissance liés au routage, et ainsi assurer la réussite.

Dans tous les cas, le succès des conteneurs et du cloud dépend fortement de leurs écosystèmes, et donc de l’autre économie des API, qui permet l’automatisation et l’orchestration indispensables à la croissance des entreprises dans le cadre de leurs initiatives de transformation numérique.

* Je trouve frustrant que les concepts d’automatisation et d’orchestration semblent être confondus dans l’univers des conteneurs, l’un étant employé à la place de l’autre. Mais pour l’instant, faisons abstraction de cela, et je vais essayer de garder le pédant qui sommeille en moi là où il doit rester. Dans ma tête. Hurlant. Désespérément.

À 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