La conteneurisation fait son chemin et tend à devenir un outil standardisé pour les entreprises en mal de transformation digitale. Pourtant, même si les containers constituent désormais une solution de référence pour distiller plus d’agilité dans les architectures applicatives, on peut néanmoins s’interroger légitimement quant au niveau de retour sur investissement. La valeur ajoutée que présente une architecture à base de containers reste le plus souvent soumise à la granularité du découpage qui peut être fait des divers services applicatifs. Dans le cadre idéal, on parle d’architectures « micro-service », venant ainsi s’opposer aux traditionnelles architectures dites « monolithiques ». S’agissant d’un patrimoine applicatif historique, la question principale reste donc liée au niveau de refactoring nécessaire pour conteneuriser efficacement l’existant. Il faudra également probablement différencier les avantages liés à la diminution de l’adhérence technique, notamment concernant les problématiques de réversibilité dans le Cloud, des avantages inhérents à la modernisation de l’architecture, pour évaluer pleinement tous les bénéfices des containers.

« S’il vous plaît … dessine-moi un mouton ! »

Dans le roman d’Antoine de Saint-Exupéry, le Petit Prince demande au pilote de lui dessiner un mouton. Par plusieurs fois le pilote s’exécute, mais jamais le mouton proposé ne convient au Petit Prince. Las et à bout de patience, le pilote finit par dessiner une boite, « le mouton que tu veux est dedans ». Le visage du Petit Prince s’illumine, « c’est tout à fait comme cela que je le voulais ! ».

Telle est la promesse des containers, comme révélée plus tard par le Renard dans le roman, « l’essentiel est invisible pour les yeux ». Un container contient une image exécutable d’un environnement complet incluant code, librairies, outils et configuration. Son immutabilité et son niveau d’isolation garantissent une exécution toujours prédictible, indépendamment de leur environnement. Le container est donc un outil particulièrement utile pour exposer des services sans se soucier de leur implémentation interne. C’est ce qui explique leur forte adoption dans le cadre d’architectures « micro-services » et le succès des services « clé-en-main » disponibles dans des référentiels comme Docker Hub.

Les promesses de la conteneurisation

Les containers ne doivent pas être simplement considérés comme une ultime évolution des technologies de virtualisation. Au contraire, ils sont de conception plus ancienne et offrent moins de fonctionnalités que les machines virtuelles. Leur ancêtre est la commande ‘chroot’  apparue au début des années 1980 sur les systèmes Unix. C’est probablement leur forte adoption dans des sociétés comme Google, Facebook et autres géants du web qui ont popularisé la technologie et laissé penser que les containers pourraient constituer une solution totalement générique pour déployer les applications.

Lorsqu’une application a été conçue pour une plateforme comme Docker Swarm ou Kubernetes, les composants applicatifs (ou services) deviennent mobiles et peuvent migrer dynamiquement d’un système à l’autre. De plus, l’élasticité globale de l’application est gérée de façon transparente en multipliant ou réduisant le nombre composants actifs selon le niveau de demande utilisateur, ce qui constitue une avancée majeure. Ainsi, les processus de déploiement et de maintenance des applications distribuées sous la forme de containers peuvent-ils être simplifiés et gérés de façon plus indépendante de l’infrastructure sous-jacente, fut-elle physique ou virtuelle.

Si l’on se plait à comparer les containers aux machines virtuelles, il faut essentiellement retenir que ceux-ci sont extrêmement légers puisqu’ils n’embarquent pas de système d’exploitation. Les taux de consolidation obtenus sont souvent supérieurs à 20 containers pour 1 serveur virtuel, mais ce n’est pas le seul avantage direct. Imaginons que la capacité d’un service applicatif frontal doive être adaptée dynamiquement en fonction de la demande des utilisateurs. Le provisionnement de containers additionnels ne nécessite qu’une simple ligne de commande et peut même être totalement automatisé. En revanche, le démarrage de machines virtuelles complémentaires nécessite des opérations plus complexes, chacune disposant de ressources propres, système d’exploitation, stockage, réseau, sans compter les problèmes de configuration puisqu’il ne s’agit pas de composants immutables. On comprend ainsi facilement pourquoi les containers ont été largement adoptés par les géants du web.

Les limites de la conteneurisation

S’il y a une chose à savoir à propos des containers, c’est qu’on ne peut pas mettre ses applications existantes en container et espérer tirer profit d’une architecture ainsi « modernisée ». Il n’est en effet pas possible de tout simplement conteneuriser ses applications historiques pour les rendre portables et élastiques. Même s’il reste techniquement envisageable de mettre un ERP dans un container, il ne faut pas compter simplifier l’exploitation, réduire les dépendances ou résoudre les problèmes de performance. En d’autres mots, si l’on considère les containers comme des machines virtuelles, il ne faut pas espérer en obtenir d’avantages particuliers.

En fait, si les architectures applicatives historiques ne sont pas profondément revues, l’impact de la conteneurisation sera au mieux négligeable, et au pire produira un résultat inférieur à la situation initiale. La conteneurisation reste donc indissociable de l’architecture applicative, les containers supportent l’application, mais ils structurent également son architecture et plus particulièrement la granularité des services. C’est souvent une mauvaise nouvelle lorsque l’on réalise que pour tirer pleinement parti des containers, il est nécessaire de passer par un refactoring extensif.

Néanmoins il reste utile de s’interroger sur l’adoption des containers puisqu’un nombre croissant de développement s’y appuient. Si l’on considère la globalité de son patrimoine applicatif, il convient de faire une analyse application par application et de créer une feuille de route en phase avec ses objectifs de transformation numérique. Pour chaque actif, il faut se demander si l’architecture de l’application peut être convertie en architecture à base de services, quel impact aurait le redéveloppement et quels bénéfices métiers pourrait-on en tirer, sachant que la dette technique ne se justifie que rarement à elle-même.

Un air de « déjà-vu »

Ceux d’entre nous ayant officié au moment du passage à l’an 2000 reconnaîtront probablement des préoccupations similaires à celles relatives lors l’adoption des technologies SOA. Dans les faits, la conteneurisation vient aliementer le même type de réflexions sur les architectures des applications. Les enjeux sont bien entendu différents. Il y a 20 ans, il s’agissait de gagner la bataille de l’interopérabilité, aujourd’hui il s’agit de gagner la bataille de l’agilité. Que l’on ne s’y trompe pas, les containers sont bien synonymes d’une refonte profonde des architectures applicatives et de l’avènement de nouveaux standards basés sur les « micro-services », alors surtout, évitons d’en faire un mouton à cinq pattes.