Après plusieurs années de développement logiciel et de maintenance, certaines applications d’entreprise s’avèrent laborieuses et trop coûteuses à faire évoluer.
L’essor des architectures micro-services (micro-services architectures – MSA) propose un modèle pour la résolution de cette problématique.
Les principaux objectifs des architectures micro-services sont :
- de réduire les empêchements au changement,
- d’augmenter l’extensibilité en utilisant l’axe de décomposition fonctionnel,
- de libérer les équipes de la lourdeur des applications monolithiques,
- et finalement d’accroître la compétitivité de l’entreprise.
Les principales caractéristiques des micro-services sont :
- La cohésion interne.
- Le périmètre fonctionnel des fonctionnalités d’un micro-service est réduit, et dédié à une fonctionnalité élémentaire.
- Le découplage.
- Les micro-services sont d’autant plus indépendants qu’ils sont « découplés ».
- La distribution.
- Chaque micro-service est un processus système distant, déployé sur une machine distincte ou dans un conteneur.
Bénéfices clés des architectures micro-services
- Agilité technologique
- Etant indépendants, les micro-services ne sont pas contraints à une uniformité technologique. Les choix technologiques peuvent ainsi être adaptés aux besoins et caractéristiques des micro-services (voir persistance polyglotte).
- Cette flexibilité permet d’introduire des innovations technologiques progressivement, en limitant le risque encouru.
- Extensibilité
- Le découpage en unités fonctionnelles indépendantes permet de répliquer sélectivement les micro-services les plus utilisés, plutôt que de mettre en œuvre une redondance globale de l’application monolithique.
- Afin d’y parvenir, il faut potentiellement mettre en œuvre une architecture orientée événement afin de rendre les appels entre services non bloquants et augmenter la capacité du système.
- Evolutivité et réduction des délais de mise en marché
- Les évolutions d’un micro-service sont facilitées par l’étendue d’un périmètre fonctionnel limité et par le découplage que l’architecture distribuée impose.
- Résilience
- La distribution des micro-services en processus systèmes techniquement indépendants permet une meilleure continuité de service à condition de mettre en œuvre des techniques de mitigation des pannes (répartition de charge, registres de services dynamiques, circuit breaker …).
Défis soulevés par les micro-services
Les bénéfices sont multiples mais la distribution des micro-services induit une nouvelle forme de complexité qui nécessite
- Une approche d’analyse fonctionnelle et de conception en contexte distribué, mettant en évidence des unités fonctionnelles autonomes et cohésives ;
- La prise en compte des contraintes techniques d’intégration ;
- Une gestion opérationnelle automatisée, notamment en ce qui concerne le déploiement, les tests et le monitoring ;
- Une organisation humaine compatible (cf. loi de Conway: « organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations »).
Gestion des mises à jour de données distribuées
Dans une application micro-services, les données sont distribuées dans des magasins de données hétérogènes.
Cette situation impose des changements dans la gestion des transactions, les critères ACID ne pouvant plus être assurés dans tous les scénarios de mise à jour.
Plusieurs approches peuvent être considérées dont l’utilisation d’une architecture d’intégration « Event driven » s’appuyant sur l’utilisation de brokers de messages.
Gestion des compatibilités de versions
Les bonnes pratiques suivantes facilitent la gestion des compatibilités de versions :
- Eviter l’introduction de modifications ayant un impact sur les interfaces
- Utiliser la convention de version sémantique : MAJOR.MINOR.PATCH
- Utiliser le pattern de clients tolérants (tolerant readers)
- Mettre en pratique la loi de Postel, ou principe de robustesse côté serveur : « Be conservative in what you do, be liberal in what you accept from others. »
- Utiliser la technique du Consumer Driven Contract .
Tests des micro-services
Compte tenu du nombre de services déployés, il est difficile de recréer un environnement de production complet incluant le micro-service à tester, les micro-services liés ainsi que les n sources données correspondantes.
De plus, les micro-services sont fréquemment intégrés via des communications asynchrones plus complexes à tester que les interactions locales entre composants.
Gestion de la chaîne de production logicielle
La mise en œuvre d’une architecture micro-services nécessite la mise en œuvre d’une ligne de « Production Continue » ou « Continuous delivery » qui inclut notamment :
- La gestion de configuration
- La construction des livrables
- La virtualisation des environnements et des infrastructures
- L’automatisation des modifications de schéma
- L’automatisation des tests
- L’automatisation des déploiements
- Le suivi de l’ensemble de la chaîne
Les outils de virtualisation d’environnement (tels que Docker) sont essentiels dans cet écosystème car ils permettent d’isoler efficacement les micro-services, de fiabiliser la gestion de l’environnement d’exécution des applications et de faciliter les tests et le déploiement.
Monitoring des micro-services
Dans un contexte de micro-services, le monitoring est essentiel pour surveiller
- le bon fonctionnement de l’infrastructure et des appels entre micro-services ;
- le respect global de la qualité de service ;
- la répartition des micro-services dans l’infrastructure et les versions de services déployées.
Cas d’application de ce style d’architecture
La mise en œuvre d’une architecture micro-services est une source de complexité opérationnelle accrue qui peut se justifier par l’efficacité que l’approche induit sur la durée ou par exemple si :
- La taille de l’équipe qui réalise le système est trop importante pour collaborer efficacement sur un monolithe ;
- Les métiers concernés doivent impérativement évoluer indépendamment ;
- L’extensibilité du système est primordiale ;
- Le système monolithique équivalent devient trop complexe pour continuer à évoluer raisonnablement vite