Alors que les technologies Cloud Native arrivent à une certaine maturité, de nombreuses entreprises cherchent à moderniser leurs applications ‘maison’ et notamment les applications qu’elles considèrent comme différenciantes et génératrices de valeur pour l’entreprise. Dans ce contexte, l’utilisation des microservices et des conteneurs fait de plus en plus sens.

Les architectures modulaires reposant sur des microservices apportent plusieurs bénéfices et notamment :

  • L’application monolithique peut être transformée par étape en extrayant peu à peu des microservices.
  • Les microservices peuvent être mis à jour, étendus et déployés plus rapidement, indépendamment les uns des autres et sans mettre en péril l’ensemble de l’applicatif.

Ils sont le fer de lance du mouvement DevOps et, couplés aux conteneurs, sont particulièrement adaptés aux applications Cloud Native. C’est la raison pour laquelle on constate une vraie percée en entreprise.

Dans cet article, nous verrons :

  1. Qu’est-ce qu’une architecture microservices ?
  2. Défis techniques et nouvelles responsabilités
  3. Les microservices boostés par le DevOps
  4. La conteneurisation et l’architecture Microservices
  5. Modernisation : du legacy aux microservices

Conteneurs, DevOps, microservices sont interdépendants et reliés, ils permettent de développer plus rapidement et plus efficacement des services applicatifs.

Les microservices, c’est une méthode de design d’applications décomposées en différentes parties autonomes, qui peuvent être versionnées, déployées et gérées indépendamment les unes des autres

détaille Marc Gardette, directeur de la stratégie Cloud de Microsoft France.

Cela permet une grande agilité dans les développements. Ce design attractif est presque évident pour des applications Cloud natives

Qu’est-ce qu’une architecture microservices ?

Une architecture microservices a pour objet de diviser une application en fonctionnalités encapsulées au sein de services autonomes. Chacun de ces services est géré et évolue indépendamment des autres services.

Concrètement, avec cette architecture, il est possible pour les développeurs de faire évoluer les microservices dont ils ont la charge selon des cycles de vie différents. Un service peut évoluer rapidement d’une version 1 à une version 10 tandis qu’un autre service, plus stable, resterait dans une version 1.

L’architecture orientée services (SOA Service-Oriented Architecture) et l’architecture microservices sont apparentées. Cependant, l’indépendance de services et l’importance donnée aux APIs dans la seconde sont deux points essentiels qui les différencient.

Cette architecture logicielle permet de répondre aux différentes problématiques soulevées par les applications monolithiques.

Microservices : défis techniques et nouvelles responsabilités

Les défis des entreprises n’ont jamais été aussi nombreux qu’aujourd’hui. Entre l’intégration d’un service tiers en urgence ou une montée en charge à des niveaux improbables, les Microservices apparaissent comme la recette miracle pour :

  • gérer rapidement tout type d’événements
  • être plus libres et plus rapides dans l’introduction de nouvelles technologies.

Plus innovantes, les entreprises gagnent aussi en compétitivité.

Outre le besoin d’automatisation et d’outillage, les environnements Cloud Native présentent certains nouveaux défis techniques et notamment une certaine maturité dans la gestion de l’infrastructure.

Les solutions Cloud Native augmentent aussi le travail des développeurs qui, s’ils dépendent moins de l’IT, doivent en revanche davantage spécifier et gérer les besoins de leurs applications. Avec les conteneurs, la responsabilité du suivi des versions passe au DevOps et nécessite un contrôle adéquat.

Au fur et à mesure que vous évoluez vers une architecture Cloud Native, les développeurs applicatifs doivent se soucier de la qualité de service en termes de performance, d’évolutivité et de transparence de la localisation pas forcément en adéquation avec l’état d’esprit des développeurs.

La voie tracée vers le Cloud

Les atouts d’agilité et d’évolutivité ne sont pas les seuls à expliquer l’intérêt actuel pour les pratiques, architectures et technologies Cloud Native. Certaines de ces dernières sont aussi un chemin tout tracé pour déployer les applications directement ou ultérieurement dans le cloud – en général un PaaS – avec des possibilités que n’offre pas la simple migration d’une application existante dans un IaaS (Lift & Shift).

Ainsi, selon Gartner, les entreprises cherchent désormais à se défaire de leurs applications basées sur des VM hébergées dans le cloud (IaaS). Soit en les remplaçant par des alternatives SaaS, soit en les réécrivant en mode Cloud Native.

La principale raison de ce changement réside dans les coûts à long terme associés à des applications qui ne sont pas optimisées pour le cloud. Les autres bénéfices en matière de performance, de montée (ou descente) en charge et de disponibilité sont autant d’arguments supplémentaires pour une réécriture

explique le cabinet de conseil.

Par ailleurs, les applications Cloud Native, opérant avec des technologies PaaS, peuvent intégrer les multiples services – notamment serverless – disponibles sur ces plateformes. Un atout en matière d’innovation qui devrait booster les dépenses dans le cloud, prédit Forrester:

La plupart des applications d’entreprise seront améliorées grâce à l’incroyable éventail de technologies émergentes mises au point dans le nuage, depuis les nouvelles bases de données jusqu’aux dispositifs informatiques de pointe, en passant par l’Internet des objets, l’apprentissage automatique et l’intelligence artificielle

Les atouts business

Les applications Cloud Native vont probablement prospérer et modifier durablement la manière dont les entreprises développent et intègrent les applications au cœur de leur activité avec en ligne de mire de gagner en compétitivité. Les organisations les plus avancées en la matière qui mettent l’informatique au service du business, enregistrent des gains en matière d’agilité, d’expérience client et de coûts…

La complexité des architectures liées aux microservices est certes un frein, largement compensée par les problématiques de scalabilité, de robustesse et de souplesse dans la mise en place de nouvelles évolutions.

Les microservices boostés par le DevOps

À la base, il y a la volonté des équipes informatiques de travailler de façon plus efficace avec les équipes métiers, en proposant plus rapidement des logiciels capables d’évoluer à la demande. L’utilisation de méthodes de développement agiles et l’adoption des principes du mouvement DevOps ont nécessité l’apparition de nouvelles approches de collaboration avec un cycle de développement court.

Les microservices et les conteneurs apparaissent comme la réponse naturelle à cette tendance.

Deux mondes proches, mais pas forcément liés : toutes les applications en conteneur ne sont pas des microservices et tous les microservices ne sont pas déployés sous la forme de conteneurs.

Chez Microsoft, c’est Azure Service Fabric qui a d’abord été au cœur de cette révolution. Ce serveur d’applications dédié aux microservices se charge de mettre en oeuvre les solutions nécessaires à cette approche : gestion des états, des versions, des affinités, optimisation des performances et load balancing automatique sont assurés par Service Fabric.

Mais aux côtés de ces services dédiés aux applications à base de microservices, des solutions de plus bas niveau, comme les conteneurs Docker, montent en puissance. Les microservices existent depuis longtemps. Mais ce sont les conteneurs qui ont permis de concrétiser plus largement cette approche. De même, les conteneurs existent depuis longtemps, mais ont pris leur envol avec l’arrivée de Docker. Les conteneurs promettent de révolutionner l’IT, en passant les OS au second plan et en permettant une évolution forte des process.

En permettant d’assembler, de publier et de déployer plus rapidement, les conteneurs donnent tout son sens à la démarche DevOps et ont un effet démultiplicateur sur ses avantages.

Chez Microsoft, l’intégration de la technologie Kubernetes via Azure Kubernetes Service (AKS) apporte les services notamment d’orchestration, de déploiement et de montée en charge pour mettre en place une architecture extensible et flexible ( « clusters ») sur la base de ces conteneurs.

La conteneurisation et l’architecture Microservices

Les conteneurs sont un nouveau moyen de déployer des applications, qui rapproche davantage les professionnels IT et les développeurs informatiques des entreprises en phase avec la démarche DevOps.

Ils rendent les développeurs plus indépendants des systèmes informatiques et permettent de créer des scénarios avancés sans toucher au modèle de sécurité ni à l’infrastructure principale.

Autres points décisifs, les conteneurs :

  • sont réactifs car ils utilisent le système d’exploitation hôte et partagent les bibliothèques appropriées
  • ne gaspillent pas les ressources de l’hôte contrairement aux machines virtuelles
  • permettent l’isolation des bibliothèques et des fichiers binaires spécifiques à l’application qu’ils exécutent
  • sont gérés par un moteur de conteneurisation

La conteneurisation a toute sa place dans une architecture dans laquelle l’application est divisée en plusieurs services communiquant entre eux.

Plus légers que la virtualisation, les conteneurs sont idéaux pour accueillir des microservices (à raison d’un par conteneur), auxquels ils apportent un certain degré d’indépendance. Les conteneurs sont indéniablement un booster, pour les microservices, et donc pour le mouvement DevOps.

En effet, les conteneurs peuvent embarquer directement les runtimes et les frameworks dont le code aura besoin pour fonctionner. Toutes les dépendances nécessaires sont packagées dans le conteneur directement au côté de l’application.

Les conteneurs sont avant tout un format de packaging qui facilite la portabilité

explique Marc Gardette directeur de la stratégie Cloud de Microsoft France

Ils n’intéressent donc pas que les DevOps. Leur réplicabilité facilitée par la présence des Runtimes n’impose pas la nature du mode de développement

DevOps, microservices et conteneurs se marient très bien avec les infrastructures Iaas qui présentent le même degré d’agilité. Ce principe d’infrastructure composable via des pools de ressources (CPU, mémoire, disque, réseau, etc.) librement attribuables permet de créer des infrastructures adaptées aussi bien aux systèmes legacy qu’aux microservices.

Modernisation : d’une application monolithique à une architecture microservices

Pourquoi aller vers une application microservices ?

Passer à une architecture microservices permet de moderniser son application notamment s’il s’agit d’une architecture avec de fortes capacités d’évolution, d’adaptation et de maintenabilité.

Avec ce type d’architecture, on s’affranchit de problèmes que l’on peut connaitre sur les applications dites ‘legacy’ (héritées du passé) :

  • Des évolutions parfois longues et difficiles à mettre en œuvre : soit parce que l’application elle-même est assez opaque et les changements risqués ; soit parce que l’architecture a évolué au fil des modifications et est devenue trop complexe ; etc.
  • Une maintenance désormais trop chère suite à de nombreux changements

Les évolutions successives et parfois mal contrôlées des applications Legacy sont autant de points qui viennent complexifier le travail des développeurs. Surtout lorsque l’équipe technique s’agrandit et que tous ses membres sont amenés à travailler en parallèle sur un même projet.

Les demandes et points d’entrées se multiplient créant des problèmes de responsabilités, difficiles à déterminer voire inexistantes, et de cohérence, souvent non respectée. L’architecture microservices tente de résoudre ce problème en instaurant un seul point d’entrée : l’API.

Dans le cadre d’applications monolithiques, nous sommes parfois face à des bases de données tellement importantes que personne ne sait réellement ce qui s’y passe. Avec une base de données par microservices, nous sommes dans un environnement beaucoup plus contrôlé

commente Sébastien Gissinger, Consultant chez SoftFluent.

Personne ne doit attaquer la base de données directement, tout se fait par l’intermédiaire de l’API du microservice

Un microservice peut-il lui aussi devenir trop lourd ?

On peut avoir un microservice qui sert à la communication afin de gérer, par exemple, les envois de mails, de sms. Si demain ce service gère beaucoup plus de paramètres, plus de volume ou présente des écarts de charges trop importants par fonctionnalité (ex : 500 000 mails/jour vs 10 sms/jour), il est préférable de diviser le microservice en plusieurs microservices. Cela permettra de les faire évoluer de manière indépendante tout en évitant qu’une dépendance ne vienne en impacter une autre et, ainsi, de gérer chaque dépendance en fonction de ses besoins spécifiques, notamment en infrastructure

selon Wesley Van den Eede, Consultant en transformation.

Comment passer d’une application Legacy à une architecture microservices ?

Passer d’une application Legacy à une application microservices est un processus long. C’est pourquoi on recommande une approche incrémentale. Au fur et à mesure, l’application est décomposée en fonctionnalités qui sont isolées au sein de microservices. Lorsque l’application est assez bien découpée, elle peut cohabiter avec une architecture microservices, le temps de moderniser le reste de l’application. Ce genre de situation est plus gérable surtout s’il n’y a pas d’interaction entre les deux.

L’arrivée d’un “petit projet” est également une bonne occasion de se lancer. Cela permet non seulement de commencer dans un contexte moins complexe mais aussi de prouver que la modernisation est possible, fonctionne et est bénéfique.

L’équipe de développeurs doit également apprendre à penser différemment. La démarche change, le développeur n’appelle plus une fonction, mais un microservice avec plus de paramètres à prendre en compte. D’ailleurs, les équipes de développeurs peuvent être gérées différemment. Il n’est pas rare de trouver des équipes dédiées à un ou plusieurs microservices.

L’avantage de ce type d’organisation est de disposer d’équipes performantes contrôlant parfaitement le microservice. Cela évite notamment d’avoir trop de développeurs enchainant les requêtes sur une même base de données.

Étape importante lors de cette modernisation : il faut analyser l’application Legacy et comprendre comment la diviser et la restructurer en microservices pertinents. Cette réflexion, qui doit se faire en amont, est directement corrélée à l’application, son organisation, ses fonctionnalités et leur importance pour le métier.

Mise en place

La mise en place d’une architecture microservices peut être envisagée de deux manières :

  1. En utilisant les services REST. C’est la manière la plus usitée et simple et à mettre en place dans un premier temps. Cependant, cette approche présente des inconvénients. Les services REST sont majoritairement des appels synchrones et, pour certains, ne sont pas rejouables simplement en cas d’erreur (principalement les opérations PUT/POST). La scalabilité, dans ce cas, est fortement conditionnée à la mise en place d’un système de balancing permettant d’équilibrer la charge entre les différents services répliqués. On ajoute donc des points de contention au système avec pour conséquences, des pertes de performances.
  2. En utilisant un bus de messages. Son rôle étant de transmettre les messages, il doit être le plus simple possible aucune logique ne doit y être intégrée. Le système devient totalement asynchrone et les microservices n’ont aucun lien entre eux. Le système devient plus tolérant aux pannes, si un service tombe le bus conservera le message qui sera alors consommé à la remise en place du service. Dans le cas d’un bus, un système de monitoring doit être mis en place pour observer la consommation des messages et l’état des services en général, le système ne générant pas d’erreur en cas de service indisponible.