Des containers aux architectures microservices

L’architecture « microservices », voici un nouveau mot à la mode dans le monde fascinant de l’IT. Mais qu’est-ce qu’une architecture microservices ? L’objectif d’une telle architecture serait de   déployer rapidement des applications logicielles en local ou dans le Cloud en exploitant une suite de petits services et en limitant le périmètre de chaque service. « L’application va être découpée en une multitude de petits services simples à démarrer et à mettre à jour, et pour faire communiquer ces petits services, il suffit d’exploiter un simple bus de messaging (ndlr : ou via un protocole de type API Rest par exemple) », explique Laurent Seror, président directeur général d’Outscale (voir encadré). Pour Nicolas Roux, consultant et co-fondateur du cabinet Agaetis spécialisé dans la gestion de la donnée, les architectures microservices ont l’avantage de supporter plusieurs langages, chaque microservice peut ainsi être écrit dans un langage de programmation différent ou utiliser des bases de données spécifiques, et de préciser : « L’architecture microservices n’est pas un marché, c’est simplement une évolution d’un modèle d’architecture. Les entreprises clientes ne viennent pas chercher une architecture microservices en tant que telle, elles viennent nous chercher car leurs besoins d’applications ou de refonte de leurs sites web sont de plus en plus complexes avec des traitements importants et une prise en compte d’éléments multiples. »

En clair, le fonctionnement de cette approche microservices s’apparente clairement aux jeux de stratégie ou de simulation en temps réel qui font fureur sur les tablettes dont le but est de bâtir sa structure, la faire évoluer et la faire vivre via une multitude de composants qui communiquent les uns avec les autres.

Un fonctionnement en mode asynchrone pour les architectures microservices

En soi, cette approche n’est pas nouvelle, souvenons-nous des SOA (Service Oriented Architecture) il y a déjà une dizaine d’années, ces architectures orientées services dont le but était de créer des méthodologies pour concevoir et déployer des applications. A la différence que les architectures SOA gèrent des services de taille plus importante et qu’elles fonctionnent en synchrone contrairement aux architectures microservices qui se doivent de fonctionner en asynchrone pour une meilleure résistance, une meilleure tolérance de panne et une meilleure répartition de la charge (scalabilité). En effet, les applications en microservices étant fortement interconnectées, il n’est pas possible d’attendre la réponse d’un service en faisant un appel en mode synchrone au vu de la multitude de services, les services seront lents et par conséquent, l’application fonctionnera au ralenti.

Pour Laurent Seror, il est plus difficile de déployer des architectures microservices dans un SI existant. « Passer d’un mode synchrone à un mode asynchrone oblige les entreprises à tout refaire. Pour l’heure, les entreprises françaises ne sont pas prêtes mais certaines n’auront pas le choix pour faire face à une concurrence exacerbée. Il faut aller très vite avec beaucoup d’agilité. Cela dit, nous constatons un réel intérêt sur ce sujet et nous observons déjà certaines remontées de la part des grandes entreprises pour des nouveaux projets. » Pour Nicolas Roux, c’est effectivement plus simple de partir d’une feuille blanche. Par exemple, son entreprise Agaetis a créé en exploitant les microservices pour une société cliente un prototype de job board couplé aux réseaux sociaux. L’objectif était donc de trouver des liens entre la société émettrice de l’offre d’emploi et le demandeur. Grâce à la connexion aux réseaux sociaux et aux informations renseignées sur le CV, le système était capable pour chaque offre de mettre en avant des personnes ayant des liens avec le candidat et l’entreprise (ex: parcours scolaire commun, ancien collègue, ami Facebook, etc.). Plusieurs technologies ont été exploitées pour ce projet dont Elasticsearch pour la recherche des annonces, mongoDB pour le stockage des activités et profil des utilisateurs, postgreSQL pour la gestion des utilisateurs et Spring comme bus commun de communication.

Des frameworks prêts à l’emploi pour créer des architectures microservices

Aujourd’hui, ce sont surtout les sociétés du web qui utilisent ce type d’architecture microservices car elles ont besoin d’infrastructures agiles capables de s’adapter et de fournir rapidement du delivery pour faire face à un fort environnement concurrentiel. In fine, elles mettent indirectement leur expérience personnelle au profit de toutes les entreprises. Reste que l’architecture microservices est un marché naissant qui n’a pas encore vraiment dévoilé son leader capable de proposer un véritable PaaS dédié pour faciliter la création et le déploiement des microservices. Cela dit, des frameworks légers existent déjà sur le marché pour aider à la création et à la mise en place de ces architectures microservices comme Dropwizard, Sinatra (Ruby), Spring Boot (pour Java) ou Vert.X (multilangages dont Java, Javascript, Groovy et Ruby). « Il est important de disposer de frameworks légers pour faciliter le déploiement. A mon avis, je ne suis pas sûr qu’un leader se positionne sur ce marché car l’objectif n’est pas d’imposer ou de remplacer un langage de programmation par un autre », tient à préciser Nicolas Roux.

Une organisation agile de type DevOps

Dans une approche « architecture microservices », il est nécessaire d’avoir une organisation extrêmement agile de type Devops (compétences multiples de développeur et d’administrateur système et sécurité) qui permet certes d’améliorer le Time To Market, mais surtout de prendre en compte les aspects très nombreux liés à la sécurité. En effet, le développeur devra aussi assumer des responsabilités historiquement assurées par les opérationnels. De plus, la multiplication des petits services va accroître les possibilités d’attaques pour les hackers sans oublier la protection des données qui ne sera plus forcément centralisée.

TinaOS, l'outil d'orchestration cloud d'Outscale orienté full microservices en 2017

La démocratisation des architectures microservices semble aussi s’accélérer grâce à la technologie de conteneurisation open source Docker qui permet de créer et faire tourner des applications avec bien plus d'agilité. « La conteneurisation est un moyen de produire une architecture microservices, cette couche apporte une souplesse de production adaptable à la charge », constate Camille Cacheux de l’hébergeur Coreye qui devrait lancer un « Docker as a service » début 2016. Précisons également que Coreye fait partie du groupe Pictime spécialisé dans l’intégration logicielle pour le secteur du e-commerce et qui a déjà une certaine expérience dans la mise en production de Docker.

Un temps de démarrage ultra rapide

Pionnier dans les conteneurs avec Solaris Zones, Sun Microsystems a quelque part inventé cette approche reprise plus tard par LXC (Linux Containers). Là ou LXC réclame des compétences pointues dans la création de conteneur applicatif, Docker, souvent considéré comme une surcouche de LXC, a enrichi et simplifié le fonctionnement de la technologie de conteneurisation. Docker améliore ainsi la scabilité, la portabilité, la légèreté et la rapidité de mise en œuvre. De plus, contrairement à une machine virtuelle qui embarque un système d’exploitation pour fonctionner, un conteneur ne gère pas de système d’exploitation, il utilise les ressources de son système hôte. De ce fait, un conteneur est encore plus rapide à créer et à démarrer. En clair, une ligne de commande suffit à charger le conteneur et à l'exécuter. « Quand on lance Docker, on lance un process, c’est cette approche qui encourage les utilisateurs à faire du microservice, son temps de démarrage est rapide, c’est quelques millisecondes, et le deuxième avantage de Docker, c’est la simplicité pour créer un conteneur », souligne Olivier Albiez et Thomas Clavier, les deux dirigeants de la société Azaé, un petit cabinet de conseil spécialisé dans les méthodes agiles.

Docker se diffuse partout

Aujourd’hui, Docker a déjà séduit l’industrie IT sous différentes formes : IBM qui adopte Docker dans sa plateforme Bluemix, Amazon qui prend en charge des conteneurs Docker dans AWS, Microsoft dans son Cloud Azure et bientôt dans Windows Server 2016 ou encore Google qui gère les conteneurs Docker via sa plateforme d’orchestration Kubernetes.

En France, Docker se démocratise également. L’un des premiers services d’hébergement de conteneurs Docker a d’ailleurs été créé par le cabinet de conseil Azaé sous la marque Deliverous. Selon les dirigeants d’Azaé, Deliverous, la plateforme applicative sous Docker, permet aux entreprises, aux utilisateurs, aux développeurs de créer et d’exécuter rapidement un conteneur dans un environnement. Quant aux entreprises utilisatrices, elles sont selon nos interlocuteurs déjà très nombreuses à exploiter Docker pour des besoins multiples. Certaines pour faire interagir des applications multilangages et d’autres pour diminuer des coûts de mises à jour, de migrations ou de maintenance trop importants d’applications web (et dans une moindre mesure d’applications métiers lourdes) en les encapsulant dans Docker.

Si Docker est un pionnier qui s’est imposé de facto comme un standard, des solutions alternatives arrivent sur ce marché et se revendiquent plus sécurisées comme Rocket éditée par CoreOS, mais aussi de LXD (Linux Container Daemon) éditée par Canonical (Ubuntu), basée elle aussi sur la technologie de virtualisation LXC .

Tout vient à point à qui sait attendre 

Au-delà des conteneurs, l’enjeu se place surtout sur les outils de gestion des conteneurs comme Google Kubernetes mais aussi d’orchestration et d’automatisation qui permettent de gérer les ressources pour faciliter la mise en production au sein d’un cluster comme Mesos ou encore Marathon. Mais là encore, des doutes subsistent encore sur la maturité de ces outils, notamment dans un environnement Amazon EC2. « De mon point de vue, à l’heure où je vous parle, ces outils manquent de maturité pour une utilisation en production. Prenons l'exemple de Mesos/Marathon, très prometteur mais qui souffre de nombreux bugs perturbant notamment la gestion des conteneurs dockers. On voit dans la presse que certaines grandes compagnies utilisent ces outils en production, par exemple Apple pour Siri, mais utilisent-elles réellement les versions communautaires de ces solutions ? Par ailleurs, dans un environnement cloud comme sur Amazon/EC2, ces outils ne sont pas correctement outillés pour adapter dynamiquement leur capacité sous-jacente à la charge. L'augmentation de la capacité reste manuelle. Certains clients voient cela comme une régression : pourquoi aller dans le Cloud si au final on n'est plus en mesure d'aligner dynamiquement et automatiquement la dépense IT au besoin de capacité ? Cela dit, ces outils sont encore jeunes et très prometteurs, et je n'ai pas de doute sur le fait que tôt ou tard, ils répondront aux enjeux des productions informatiques », conclut Alexandre de Massougnes, fondateur de Scaleo Information Systems.

« Nous exploitons les conteneurs Docker pour nos applications web comme le font très bien les géants de l’Internet comme Google ou Netflix. Nos services web sont ainsi morcelés en groupement de conteneurs (volume de données, moteur web, moteur php, etc.). Nous utilisons les conteneurs en interne dans des machines virtuelles et en externe sur un serveur dédié sous linux », résume Jacques Kern, IT Systems Manager chez Visible Patient. Précisons que l’entreprise alsacienne innovante Visible Patient (soutenue par le Clusir Est pour France Entreprise Digital), créée en juillet 2013 et issue de l’équipe R&D de l’IRCAD (Institut de Recherche conte les Cancers de l’Appareil Digestif), a mis au point une application de modélisation 3D des organes d’un patient à opérer depuis des images provenant d’un scanner ou d’un appareil IRM. En quelque sorte, cette technologie va aider le chirurgien à mieux préparer son intervention en augmentant la précision et la sécurité de chaque procédure opératoire.

Visible Patient exploite donc des conteneurs Docker depuis un an en production. Pour Jacques Kern, contrairement aux technologies LXC, Docker a vraiment apporté de la simplicité dans la création et la gestion des conteneurs. Il résume d’ailleurs Docker à une trousse à outils pour créer facilement des conteneurs. « Pour maîtriser LXC, l’investissement en temps est très important, alors la technologie Docker est bien sûr facilement accessible aux développeurs mais aussi aux ingénieurs traditionnels. » Et d’ajouter : « Les gains sont immédiats et facilement identifiables sur la maintenance des systèmes d’exploitation si on compare Docker à l’utilisation d’une machine virtuelle. Car plus nous disposons de VM et plus nous avons d’OS à gérer. »

Aujourd’hui, Visible Patient exploite en interne deux VM qui font fonctionner une quarantaine de conteneurs. A titre de comparaison, il serait nécessaire, en temps normal, pour Visible Patient de disposer d’une quinzaine de VM couplée à autant d’OS. Résultat : une charge fortement diminuée. Quant aux éventuels problèmes de sécurité de Docker souvent soulevés, Jacques Kern indique que Docker est aussi bien sécurisé qu’une machine virtuelle. Enfin, le responsable des systèmes IT précise qu’il est préférable de travailler avec une organisation de type Devops (faire collaborer ensemble les administrateurs et les développeurs) pour ce type de projet afin d’éviter d’éventuels échecs.

Pour Visible Patient, Docker représente un palier pour évoluer vers une architecture en full microservices. En effet, si la première étape a été de conteneuriser les applications web monolithiques, la prochaine étape pour l’entreprise sera réellement de développer ces applicatifs en microservices.