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 :
- Qu’est-ce qu’une architecture microservices ?
- Quels sont les avantages des microservices ?
- Défis techniques et nouvelles responsabilités
- Quelles différences entre les APIs et les microservices ?
- 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.
Quels sont les avantages des microservices ?
Le ‘Time to market’
C’est certainement l’avantage le plus précieux, celui qui permet d’être plus libre et plus rapide dans l’introduction de nouvelles technologies. Plus innovantes, les entreprises gagnent aussi en compétitivité
Les microservices peuvent être mis à jour, étendus et déployés indépendamment les uns des autres et par conséquent, beaucoup plus rapidement
L’indépendance fonctionnelle et technique des microservices permet l’autonomie de l’équipe en charge sur l’ensemble des phases du cycle de vie (développement, tests, déploiement, et exploitation), et favorise par conséquent l’agilité et la réactivité
En outre, il est possible pour les développeurs de faire évoluer les microservices dont ils ont la charge selon des cycles de vie différents et donc d’agir là où c’est important et notamment :
- Création de valeur
- Réactivité aux évolutions du marché
- Satisfaction des utilisateurs
L’agilité technologique
Le choix technologique dans une architecture Microservices est totalement ouvert. Il dépend majoritairement des besoins, de la taille des équipes et de leurs compétences et peut être adapté aux besoins spécifiques de chaque micro-service
En effet, les micro-services étant indépendants et interopérables, ils ne sont pas contraints à une uniformité technologique
Cette flexibilité technologique permet d’introduire des innovations technologiques progressivement, en limitant le risque encouru : le périmètre impacté est réduit à celui du micro-service concerné
Il est par exemple possible d’utiliser un serveur de bases de données non-relationnel plus performant en écriture et plus extensible en fonction d’un besoin particulier, comme les Time Series..
On pourra privilégier une technologie particulière dans chaque microservice pour répondre à un besoin, par exemple, développer des services de calcul scientifique en C, C++ ou en Python pour profiter d’un code efficace en exécution avec des capacités de distribution ou encore de bibliothèques spécifiques, alors qu’un autre service sera développé en C#.
Modernisation facilitée
Passer à une architecture microservices permet de moderniser son application notamment lors du basculement d’un mode OnPremise vers le Cloud ou encore dans le cadre de l’évolution du business model d’une application.
L’approche incrémentale permet de décomposer l’application 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.
Évolutivité
Dans une application, certaines fonctionnalités sont plus utilisées que d’autres.
À mesure que la demande de certains services augmente, il est possible d’étendre les déploiements sur plusieurs serveurs et infrastructures pour répondre spécifiquement aux besoins
Si un service pour une raison ou pour une autre, par exemple pour une question de coût, devait être revu, il serait plus simple de reprendre le développement d’un seul de ces services pour l’adapter à la nouvelle plateforme plutôt qu’adapter l’intégralité d’une application monolithique
En effet, le délai de mise en production des évolutions fonctionnelles est réduit au délai nécessaire à la mise en œuvre des évolutions du ou des micro-services concernés
Pour les mêmes raisons, la suppression d’un micro-service ou son agrégation avec un autre micro-service sont également des opérations nettement plus simples à mener que pour une application monolithique
De plus, les déploiements de micro-services en production sont gérés de manière indépendante les uns des autres, ce qui réduit également le coût de mise en production d’une évolution technologique et le risque associé.
Ces éléments favorisent l’évolutivité d’une application constituée de micro-services.
Fiabilité
Lorsqu’ils sont développés correctement, ces services indépendants n’ont aucun impact les uns sur les autres. Cela signifie que, lorsqu’un élément tombe en panne, l’ensemble de l’application ne cesse pas de fonctionner comme c’est le cas avec le modèle monolithique
La distribution des micro-services en processus systèmes techniquement indépendants permet donc une meilleure continuité de service.
Cette gestion des risques s’accompagne généralement d’un retour sur investissement optimisé
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 entre Dev et Ops et des cycles 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.
Quelles différences entre APIs et Microservices
API signifie Application Programming Interface. Comme son nom l’indique, c’est une interface qui permet d’interagir avec une application pour
- Accéder aux données de l’application au moyen de requêtes
- Utiliser les fonctionnalités d’une application
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
Le microservice est un style d’architecture et de conception de développement logiciel qui structure l’application entre de petits services Web.
Il est possible d’implémenter un microservice sans API
Bien sûr, si vous divisez une application en plusieurs parties, il faut qu’elles puissent communiquer efficacement les unes avec les autres.
L’API peut
- Permettre aux microservices de communiquer entre eux sachant qu’ils peuvent aussi communiquer au travers d’un bus applicatif ou de message queuing
- Etre le lien entre les microservices et le client mobile ou web,
On pourra aussi mettre en place une API Gateway, passerelle entre les API exposées par des microservices et le front consommant ces API. Nous consacrons ici un article plus complet sur le rôle et l’utilisation d’une Passerelle d’API dans le cadre d’une architecture 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.
Lire aussi | Tester ses microservices : tout un art !
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 :
- 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.
- 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.
Sur le même sujet | Domain-Driven Design : quel apport dans une architecture microservices ?
