Le blog

Dans cette série d'articles, je vais vous présenter l'architecture micro-services, qui tente de répondre à la problématique "comment accélérer le développement et mieux accompagner le changement?". Celle-ci séduit forcément par ses arguments mais soulève en même temps de nouveaux défis majeurs.

Pour faciliter la lecture, le terme micro-services désignera l'architecture. Par contre, le terme microservice en un seul mot désignera un service bien défini.

L'idée de base de l'architecture micro-services est simple : Comment construire des application d'entreprise sous forme de plusieurs petites archives ou petits composants (microservices).

Chaque archive fournit un service (ou une fonctionnalité) bien délimité et de manière autonome, de sorte que sa mise à jour n'impacte pas le reste des services.

On peut encore imaginer que par moment (pic), un microservice particulier soit dupliqué (plusieurs instances ou cluster) afin d'offrir un meilleur temps de réponse.

Inconvénients d'une application traditionnelle

Le défaut actuel d'une application web traditionnelle est qu'elle est monolithique, ou en d'autres termes ne définit pas les frontières des services qu'elle offre.

D'autre part, adapter ou faire évoluer un composant d'une application traditionnelle exige de redéployer tout l'archive war (ou même arrêter le serveur d'application!).

Dans ces conditions, on relève que le coût de la recette d'une application monolithique qui doit suivre un changement rapide, est manifestement important.

L'inconvénient d'une application monolithique devient forcément l'avantage de la solution à base de micro-services.

Avantages des micor-services

L'un des avantages majeurs de l'architecture micro-services est que la mise à jour d'un composant (microservice) est simple et sans impact car il est autonome du reste.

L'autre avantage est qu'elle s'adapte bien à la culture DevOps.

Et enfin, elle apporte également une indication à ce fameux problème:

• Peut-on réaliser en accéléré un projet qui exige qu'une ressource travaille pendant x mois pour le terminer en mettant x ressources durant un mois ?

Les défis soulevés

Passer d'une architecture monolithique à l'architecture micro-services soulève quelques défis:

• Comment identifier l'application d'entreprise qui s'adapte à cette architecture?
• Comment définir les frontières d'un microservice?
• Comment faire (auto) découvrir ces microservices?
• Comment permettre au client de découvrir ces microservices sans rien connaitre de leur contexte (couplage faible)?
• Comment faire communiquer deux microservices déployés dans des serveurs distincts sans écrire du code supplémentaire et sans l'overhead du http/Rest?
• Quels frameworks matures doit-on utiliser ?
• Comment faire pour que l'application web qui consomme divers microservices puisse paraître comme une application uniforme et homogène?

Beaucoup de questions...

Eh oui, le design pattern micro-services règle un souci récurrent de DevOps, qui consiste à chaque patch ou évolution de redéployer l'application entière mais il apporte aussi son lot de défis.

Démo pratique

La démo à venir vous donnera quelques éléments de réponse.

Cette démo utilise spring-boot et spring-data-rest qui fournissent une façon simple d'écrire des microservices.

Ces deux frameworks couplés facilitent grandement la réalisation de microservices RestFul.

• La première partie de la démo permet de mettre en place un registre qui facilite la publication et la découverte des microservices.
• La seconde partie permet, pas à pas, de rajouter deux microservices.
• La dernière partie permet de faire communiquer ces deux microservices.

Certaines solutions seront introduites afin de faciliter les manières de les faire communiquer ou de les auto-exposer.

Nous mettons la main dans le code dans la suite.

A très vite,