Architectures micro-services : objectifs, bénéfices et défis - Partie 1

 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. Ce type de dette technologique est un constat, une difficulté majeure, que rencontrent à terme de nombreuses entreprises. Cela conduit souvent à faire table rase des développements passés, et à les reconstruire à partir de zéro.

L'essor des architectures micro-services (micro-services architectures - MSA) répond à cette problématique, et propose des moyens de la résoudre. Les architectures micro-services permettent de développer, de déployer et de gérer opérationnellement des applications distribuées, constituées de services aux fonctionnalités complémentaires, potentiellement hétérogènes et interopérables.

Les micro-services favorisent drastiquement l'indépendance des cycles de vie, qu'il s'agisse des cycles de conception, de développement, ou de déploiement en production. Elles se distinguent des architectures orientées services (SOA), répandues depuis environ une décennie :

• Elles émergent de la recherche d'une agilité pratique et d'une efficacité accrue par des précurseurs du Cloud Computing, tels que Netflix, Amazon, Gilt ou Airbnb.
• Elles sont naturellement adaptées au Cloud, et se déploient nativement sur les "Platforms as a Service" (PaaS). Il s'agit du type de plateformes sur lesquelles elles se sont développées et déployées historiquement, et elles en exploitent naturellement les bénéfices.
• Elles ne dépendent aucunement d'une solution d'éditeur logiciel, tel que les Enterprise Service Bus (ESB), et minimisent les besoins d'intégration logicielle (EAI), mettant en œuvre des solutions décentralisées et alternatives aux fonctionnalités sophistiquées des ESB (médiation, orchestration de services, etc...)

Objectifs des architectures micro-services

"Qu'est-ce que l'architecture ?", Martin Fowler reprend à son compte la question dans son article ’Who Needs an Architect?’ . Il y développe sa propre définition :

• À première vue, l'architecture d'une application se résume en la décomposition de la totalité du système applicatif considéré en éléments constitutifs plus simples, aux rôles, responsabilités et limites bien identifiés.
• Mais, du point de vue pratique des personnes en charge d'une application, l'architecture, c'est surtout, ce qu'il est difficile de changer. De ce point de vue, l'architecture doit faire l'objet de décisions saines en amont d'un projet afin de minimiser les coûts d'évolution.

En effet, les évolutions d'une application nécessitent un effort d’adaptation, et le coût qu’elles induisent s'accroît au fur et à mesure que le système se complexifie. L'évolution d'un système a ainsi naturellement tendance à ralentir au fil du temps, et ce d’autant plus vite que « ce qu'il est difficile de changer » s'accumule. En conclusion et un peu paradoxalement, une bonne architecture est minimaliste, et permet de changer facilement n’importe lequel de ses composants. Les principaux buts des architectures micro-services sont :

• de réduire les empêchements au changement,
• de libérer les développeurs et les opérationnels des contraintes de la complexité,
• et finalement d'accroître la compétitivité de l’entreprise.

Quelles sont les caractéristiques des architectures micro-services ? Les architectures micro-services ne font pas actuellement l'objet de standards, ou de définitions bien arrêtées. Cependant, des tendances se sont dégagées au fil du temps, et leurs principales caractéristiques sont maintenant bien identifiées:

1 Cohésion interne d'un micro-service

Un micro-service est censé bénéficier d'une forte cohésion interne: le périmètre fonctionnel des fonctionnalités qu'il implémente doit être réduit, et essentiellement dédié à une fonctionnalité élémentaire. Le périmètre fonctionnel d’un micro-service peut être relié à la notion de contexte délimité (ou bounded context) issue de l'approche de conception pilotée par le domaine - Domain Driven Design (ou DDD). Dans l'acronyme SOLID, désignant 5 principes de conception orientée objet, le S fait référence au principe de responsabilité unique (SRP), défini ainsi par Robert Martin: 'Gather things that change for the same reson, and separate things that change for different reasons'. Ce principe trouve tout son sens dans un contexte de micro-services.

2 Découplage entre les micro-services

Dans une architecture micro-service, le logiciel est décomposé en un ensemble de services hautement indépendants. Chaque micro-service peut être:

• déployé indépendamment
• conçu et développé indépendamment
• testé indépendamment

En conséquence, chaque micro-service peut évoluer de façon plus indépendante que dans une approche « monolithique ». Cela confère à ce style d'architecture une réactivité au changement considérablement accrue. Les MSA permettent de répondre d’autant mieux aux objectifs de réactivité et d'adaptabilité des approches Agiles.

3 Distribution des micro-services

Afin d'atteindre ce niveau de découplage, chaque micro-service doit être un processus système indépendant, isolé sur une machine distincte ou déployé dans un conteneur. La communication entre les clients et les micro-services, ou entre les micro-services eux-mêmes, est implémentée par des services web ou un protocole d’échanges de messages avec ou sans modèle d'acteurs.

 

Quels sont les bénéfices clés des architectures micro-services ?

1- La réduction du délai de mise en marché ou « time to market »

L’indépendance fonctionnelle et technique des micro-services trouve son pendant dans l’autonomie des équipes en charge. La répartition des responsabilités dans l'organisation permet de travailler en parallèle sur des briques logicielles dont le périmètre fonctionnel et la complexité sont réduites, en comparaison d’une application monolithique. L’autonomie de l’équipe en charge du micro-service doit être la plus complète possible et doit concerner toutes les phases du cycle de vie (développement, tests, déploiement et exploitation). Le délai de mise en marché d’évolutions fonctionnelles se voit réduit au délai nécessaire à la mise en œuvre des évolutions du ou des micro-services concernés.

 

2- L’agilité technologique

Les micro-services étant indépendants et interopérables, ils ne sont pas contraints à une uniformité technologique. Les choix technologiques peuvent ainsi être adaptés aux besoins spécifiques de chaque micro-service. Il est ainsi possible d’utiliser un serveur de bases de données non-relationnel plus performant en écriture et plus extensible pour un micro-service de gestion d’historique.

Cette approche qui conduit à une forme persistance polyglotte est d'autant plus pertinente que le modèle de donnée sur lequel le micro-service opère est indépendant du reste de l’application. La liberté et la flexibilité technologiques obtenues permettent d'introduire des innovations technologiques progressivement, en limitant le risque encouru: le périmètre impacté est réduit à celui du micro-service concerné.

3- L’extensibilité

Dans une application, certaines fonctionnalités sont plus utilisées que d'autres. Le découpage en unités fonctionnelles indépendantes permet de répliquer sélectivement le micro-service requis, plutôt que de mettre en œuvre une redondance globale de l’application monolithique. D’autre part, les micro-services ne maintiennent en principe pas d’état de conversation entre 2 appels client.

Cette nature « sans état » (ou « stateless ») des micro-services facilite l’adaptation du système à la montée en charge, les instances des micro-services en cluster étant indépendantes entre elles. La répartition de charge est assurée au moyen d’un routeur et d’un service de découverte, d’enregistrement et de localisation des micro-services déployés.

4- La factorisation et la réutilisation des micro-services

La nature distribuée des architectures micro-services permet la composition des fonctionnalités métiers et favorise la réutilisation. Pour cela, il est nécessaire de concevoir la décomposition en micro-services de façon à créer des modèles de données cohésifs :

• un découpage trop large risque de produire des unités fonctionnelles qui manquent de cohésion;
• un découpage trop fin risque de multiplier les appels entre micro-services et de produire une communication réseau trop verbeuse.

Le point d'équilibre est atteint en réalisant un compromis entre des coûts de communication maîtrisés et une cohésion interne forte du modèle de données propre à chaque micro-service.

5- Evolutivité

La modernisation d’un micro-service est facilitée par l’étendue de son périmètre fonctionnel et sa complexité relativement faible. Les changements technologiques ne débordent pas du périmètre (que ce soit une réécriture totale ou partielle), et les contraintes d'interopérabilité concernent le respect du protocole de communication existant entre le micro-service et ses clients.

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.

6- Résilience

La distribution des micro-services en processus systèmes techniquement indépendants permet une meilleure continuité de service lorsqu'une panne survient. Il est pour cela nécessaire de mettre en place des technologies de mitigation des pannes. Et notamment :

• Des technologies d'indexation et de découverte des services (service discovery) tels qu'Eureka de Netflix;
• Des technologies de répartition de charge (load balancing) entre instances.
• L'utilisation de patrons de conception tels que Circuit Breaker.