Comme certains l’on déjà pu annoncer, la révolution Docker est en ordre de marche. Je n’ai pas encore pris le temps de bien expliquer ce qu’était Docker. En revanche, voici quelques avantages et surtout les impacts que cet outil peut avoir sur l’architecture de vos solutions.

VMs légères ?

Docker n’est pas une solution de VMs mais de containers. Cependant, la comparaison est facile et tout le monde est tenté de la faire. Dans un souci de vulgarisation, on peut donc s’autoriser à dire que Docker permet de créer des VMs très légères :

  • en terme d’espace disque : l’image du container n’embarque pas tout l’OS et le découpage en couche des images permet de réduire d’espace occupé pour leur stockage
  • pour la rapidité de démarrage : un container démarre en quelques secondes (c’est l’applicatif qui prend le plus de temps à démarrer)
  • avec une performance accrue : il n’y a plus d’émulation d’OS, l’overhead est donc réduit et les performances disque et réseaux semblent au rendez-vous

Un déploiement universel ?

L’avantage principal des containers réside dans leur promesse : développez une fois, déployez n’importe où !
Effectivement, jusqu’à présent, nous devions packager nos applications à partir des sources et fournir un ensemble de fichiers de configuration et de scripts de déploiement pour des livraisons sur les environnements autre que le développement. Avec Docker, tout celà est terminé. Vous définissez une fois pour toute l’éco-système de votre application (OS, applications et configuration) pour générer une image auto-suffisante. Vous l’enregistrez sur un dépôt partagé. Ensuite, n’importe quel système ayant Docker d’installé et un accès au dépôt peut déployer l’application sans avoir à lancer l’installation ou la configuration de quoi que ce soit. Adieu les erreurs de déploiement !

On peut rapidement imaginer le workflow à mettre en place pour faire au minima du continuous delivery mais surtout du continuous deployment !

Une nouvelle architecture ?

Pas si sûr…

Les containers Docker ne permettent pas de persister un état. Il faut passer par des services externes (d’autres containers ou des volumes) très faciles à mettre en place avec le système de liens inter-containers.
Si l’on ajoute les contextes d’exécution légers (pour ne pas parler de VMs :-P) et le déploiement aisé, il en résulte qu’un container doit contenir une portion de code très petite et doit être concentré sur un rôle (du métier) bien particulier. Or quelle architecture propose de décomposer un service métier de haut niveau (l’application) en un assemblage de composants indépendants et organisés par silo (les containers) ? Oui, oui. On parle bien de SOA ici.

Par ailleurs, le système de mise à jour des images Docker, permet de mettre à jour sans risque un composant qui tourne dans un container indépendant sans impacter le reste du système.

Enfin, la capacité de Docker à isoler les composants, à les déployer n’importe où et à favoriser le packaging de composants réutilisables (via des containers multi-tenants) avec un périmètre très limité, tend à aller au délà de la SOA en implémentant des micro-services !

Ces ressentiments m’ont été confirmés à la lecture de Docker: VMs, code migration and SOA solved. J’espère que cet article vous laisse entrevoir un début des possibilités offertes par Docker.