Les microservices pour une architecture orientée web n°1

Définitions et caractéristiques

Cet article s’insère dans la série “microservices” écrite par François Berthault dans le cadre de la participation de Talan Labs à Devoxx 2017, du 5 au 7 avril prochains au Palais des Congrès de Paris.

La notion d’architecture en microservices est très récente, apparue depuis 3 à 4 ans. Précurseur et véritable gourou sur le sujet, Martin Fowler est la référence en matière de microservices. Il a notamment écrit de nombreux articles sur la componentization des applications logicielles.

Aujourd’hui, les microservices sont de plus en plus utilisés pour construire des applications d’entreprise ; certainement parce que les retours sont très positifs. Il existe pourtant peu d’informations sur le sujet.

Cette série d’articles a pour objectif d’**expliquer les microservices **et d’en comprendre les implications et les usages.

Qu’est-ce qu’une architecture en microservices ?

L’architecture en microservices est une approche servant à concevoir une application unique basé sur un ensemble de petits services indépendants. Chaque microservice s’exécute dans un processus qui lui est propre et communique via un protocole léger, le plus souvent à base de ressource HTTP (tel que REST -REpresentational State Transfer- par exemple).

Grâce à une gestion centralisée et minimaliste, chaque microservice peut être écrit dans un langage qui lui est propre. Pour chaque microservice, en fonction de l’objectif auquel il doit répondre, il est donc possible d’aller au plus simple et d’**utiliser les outils et langages les plus pertinents. **L’approche en microservices est donc totalement inverse de l’approche monolithique, certes plus homogène car composée d’une seule et même technologie, mais qui entraîne un certain nombre de problèmes, de réécriture notamment.

La componentization, une nécessité pour les microservices

Avec les microservices, chaque élément correspond à un service (componentization), ce qui les distingue de l’approche par librairies réutilisables, comme c’est encore majoritairement le cas dans l’industrie logicielle. L’objectif principal est de pouvoir déployer les microservices indépendamment (ce qui devrait réjouir vos OPS) et de respecter le principe de la responsabilité unique.

Quelques facteurs indispensables à la componentization :

• **cohérence et logique du système **: tout service doit correspondre à une fonctionnalité précise ;
• spécificité des fonctionnalités : chaque service ne fait qu’une chose et il la fait bien ;
• **autonomie des services **: chaque service dispose de son propre code, gère ses propres données et ne les partage pas (pas directement en tout cas) avec d’autres services ;
• **indépendance des microservices **: chaque microservice ne doit pas inclure de couplage fort avec un autre microservice.

Un modèle d’architecture plus solide

La gestion de la base de données dans une architecture monolithique et dans une architecture microservices © Martin Fowler

L’architecture microservices favorise la scalabité cubique : contrairement aux applications de type monolithique, ce design apporte de la robustesse à votre application. Le clonage de serveur n’est plus une fatalité. Ainsi, seuls les services ayant besoin d’être étendus sont dupliqués, comme expliqué ci-dessous.

Comparaison entre architecture monolithique et architecture microservices © Martin Fowler

Microservices et architecture orientée services (SOA) : même combat ?

On pourrait croire que le microservice est une sorte d’architecture orientée service (SOA) déguisée. Si, au premier abord, les deux approches peuvent sembler assez similaires, une différence majeure les distingue :

• le SOA ou service-oriented architecture est un modèle d’architecture qui définit des composants applicatifs produisant des services pour d’autres composants via un protocole de communication réseau ;
• l’architecture en microservices est, au contraire, liée à une application, qui se compose de petits processus indépendants qui communiquent entre eux en utilisant des API (Application Programming Interface), ce qui les rend indépendants des langages.

Vous avez aimé cet article ? Découvrez ou redécouvrez les autres épisodes de la série « Les microservices pour une architecture orientée web » :

Partie 2 Les microservices pour une architecture orientée web n°2 : Un changement de point de vue

Partie 3 Les microservices pour une architecture orientée web n°3 : Organisation des équipes pour un projet d’architecture en microservices