urbanisation-si.com

Intéressons-nous à quelques considérations techniques importantes, puis aux inconvénients de l’Architecture Micro-Services et enfin à son impact sur l’organisation.

Dans notre premier article L’Architecture Micro-Services expliquée à ma fille, nous avons résumé l’évolution de l’architecture logicielle, présenté les principes de ce style d’architecture et posé les questions du partitionnement d’une application monolithique et de la granularité des micro-services.

Considérations techniques

L’architecture idéale est sans doute celle qui dépend le moins de toutes considérations techniques, mais au moment où il faut la réaliser, il est nécessaire de disposer des outils adéquats. La panoplie des outils dont on dispose pour mettre en place les micro-services, selon l’architecture préalablement établie, est très large.

Pour être précis, il vaudrait mieux parler de composants logiciels qui proposent des micro-services. Les composants favorisent la réutilisation du code déjà développé et limitent automatiquement la redondance (du code, mais aussi des données), que l’on trouve bien souvent dans une architecture en silos. Attention toutefois à ce que cette lutte contre la redondance n’augmente pas le couplage entre les micro-services.

Ces composants sont encapsulés et accessibles uniquement via leurs API (Application Programming Interface), soit selon le style RESTful (REpresentational State Transfer), qui s’appuie sur le protocole synchrone HTTP, soit via un système de messagerie au protocole asynchrone (de type message broker). Ce principe de composants encapsulés et échangeant entre eux via leurs interfaces n’est pas sans rappeler le paradigme de la Programmation Orientée Objet (OOP).

Tandis que les micro-services peuvent échanger entre eux directement via leurs API, les Clients externes peuvent éventuellement accéder à toutes les API de façon unifiée, grâce à une passerelle (API Gateway). Le couplage entre les micro-services peut être réduit en utilisant le mécanisme d’Inversion des Dépendances : les micro-services doivent dépendre de leurs abstractions (couches de haut niveau), mais pas de leurs implémentations (couches de bas niveau).

Autre considération, les micro-services sont exécutés par des serveurs qui n’ont pas besoin de connaitre leurs contextes d’utilisation (stateless servers), ce qui permet de les distribuer et de les dupliquer plus facilement.

La dernière considération technique importante est la conteneurisation (containerization), qui facile grandement le déploiement des micro-services, avec une règle simple à appliquer : un seul micro-service, ou plutôt un seul composant logiciel donc, par conteneur.

Ces considérations techniques seront approfondies dans nos prochains articles.

Inconvénients de l’Architecture Micro-Services

Tandis que les principes de l’Architecture Micro-Services sont généralement partagés par tous, car ils constituent autant d’avantages, les inconvénients sont plus rarement évoqués. Ces inconvénients sont bien souvent les conséquences de ces principes et constituent parfois des contradictions. Il est toutefois possible d’atténuer ces inconvénients : c’est en fait là que réside le talent de l’architecte.

1- Terme « micro » très relatif : la difficulté est de bien définir la granularité des micro-services. Cette granularité est variable d’un micro-service à l’autre. Ce n’est pas une bonne idée d’essayer d’obtenir une granularité uniforme pour tous les micro-services.

2- Problème de mise à jour des bases de données cloisonnées (chaque micro-service ayant sa propre base et pouvant être instancié plusieurs fois par le mécanisme de mise à l’échelle). Le mécanisme usuel de transaction de type « commit » n’est plus suffisant ; un mécanisme plus complexe appelé « saga » est nécessaire.

3- Défi en matière de débogage, test, déploiement des applications constituées de micro-services. Chaque micro-service aura été testé individuellement au préalable, mais ensuite, il faudra bien les tester tous ensemble, de façon automatisée de préférence.

4- Changements compliqués à cause des éventuelles dépendances entre les micro-services. Les micro-services supportent toutefois le versioning et plusieurs versions d’un même micro-service peuvent coexister, permettant une migration progressive vers la dernière version.

5- Application globale moins performante (latence), car dépendante du réseau (éventuellement moins fiable). Un protocole de communication asynchrone sera souvent préféré à un protocole synchrone, afin d’éviter d’attendre trop longtemps une réponse « immédiate » à chaque requête. De plus, l’usage d’un mécanisme de lecture via une mémoire cache est recommandé, afin d’optimiser la performance.

6- Besoin d’authentification, voire de chiffrage, pour diminuer les failles de sécurité du réseau.

(Liste non exhaustive, sans doute)

Impact sur l’organisation

Ce serait très réducteur de résumer l’Architecture Micro-Services à son aspect purement technique, car elle a également un impact fort sur l’organisation de la direction informatique de l’entreprise et l’exploitation d’une infrastructure distribuée et automatisée va induire de nouvelles pratiques, et même un changement de culture.

Ainsi, la frontière entre le build et le run (selon ITIL) disparaît. Cette approche est alignée avec la tendance DevOps (Development & Operations) avec Intégration et Livraison Continues (CI/CD). A noter que l’imbrication de la conception avec le déploiement en production des micro-services nécessite un champ très large de compétences.

Exemple concret de l’impact sur l’organisation : La taille de l’équipe responsable d’un micro-service est plus ou moins proportionnelle à la taille de ce micro-service. Chaque équipe, malgré sa taille réduite, doit pouvoir travailler de manière autonome. Amazon conseille de limiter la taille de l’équipe à une douzaine de personnes (two-pizza team !).

Les responsabilités nouvelles sont distribuées par micro-service, et sont étendues d’un bout à l’autre du cycle de vie du micro-service, c.-à-d. depuis la conception jusqu’à la production et même le support. Aussi faut-il raisonner en termes de Produit (alors qu’il s’agit d’un Service…), comme dans une méthode Agile, et non en termes de Projet, avec une fin planifiée.

Thierry BIARD

“In theory, there is no difference between theory and practice, while in practice, there is.”
Benjamin Brewster