Concevoir une architecture de microservices en 3 étapes

 

Concevoir une architecture de microservices n’est pas simple, même les praticiens expérimentés font face à d’importants défis dans un tel projet.  Lorsqu’on s’y prend mal, il y a des risques qu’on se retrouve avec un monolithe distribué. Plusieurs organisations qui pensaient faire de l’architecture des microservices se sont retrouvées avec ce type de monolithe qui apporte encore plus de problèmes qu'un monolithe classique.

Définir une architecture de microservices est plus un art qu'une science, mais il existe un certain nombre de stratégies qui peuvent aider.  Dans cet article, je revisite une démarche de conception d’une architecture de microservices en trois étapes. Dans la première étape, on identifie les opérations systèmes, dans la seconde on identifie les services, et dans la troisième, on détermine les API des services.

Monolithe Distribué: l'impasse

Un monolithe qui est distribué ! Ça sonne un peu comme une contradiction. En effet, on a défini un monolithe comme un système empaqueté dans une seule unité applicative. Ainsi défini, un monolithe ne saurait être distribué. Pourtant, il existe bien des applications en apparence distribuée, mais dont le fonctionnement au quotidien s’apparente beaucoup à celui d’un monolithe.  On suspecte d’ailleurs beaucoup d’organisation d’avoir ce type de monolithe plutôt particulier dans leur écosystème. En fait, plusieurs personnes qui prétendent avoir une architecture en microservices ont plutôt ce nouveau type de monolithe que Sam Newman qualifie de monolithe distribué dans son livre intitulé « Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith ».

Introduction aux Microservices: partie 2

On a vu, dans la première partie de cette introduction aux microservices, qu’il n’existe pas de définition formelle du style architectural des microservices. Toutefois, plusieurs auteurs et praticiens s’accordent sur un ensemble de caractéristiques communes aux architectures qui répondent à l’étiquette des microservices. Comme pour toute définition qui décrit des caractéristiques communes, les architectures de microservices n'ont pas toutes ces caractéristiques, mais on peut s’attendre à ce que la plupart présentent plusieurs de ces caractéristiques.

Dans cet article, je présente neuf caractéristiques communes aux architectures de microservices.

Introduction aux Microservices: partie 1

L’émergence des architectures microservices est la réponse de l’industrie aux problèmes rencontrés avec les monolithes et avec les implémentations de SOA avec L’ESB. Le terme “microservice” est apparu dans le vocabulaire du monde des applications d’entreprise il y a déjà quelques années, mais on l’entend de plus en plus ces derniers temps. Ce modèle d’architecture logicielle devient toujours plus attrayant et nombreux sont les nouveaux projets qui l’adoptent. Les résultats sont jusqu'à présent positifs à tel point que ce style est en train de devenir le choix par défaut pour la création des logiciels d'entreprise. Cependant, il n’existe pas beaucoup d'informations qui décrivent ce modèle d’architecture, et comment le mettre en œuvre, en particulier pour le public francophone.

Dans cet article, je présente les concepts fondamentaux des microservices: la théorie derrière les microservices, la définition des concepts, les caractéristiques et la structure d'un microservice.

Mise en oeuvre de SOA avec l'ESB: les limites

Dans les premiers styles de mise en œuvre des architectures orientées services (SOA), les services qui composent l’application sont organisés autour d’un bus de services d’entreprise (ESB) qui agit comme socle d’intégration entre eux pour satisfaire les exigences de réutilisation et de modularité. Si ce modèle a permis d’ouvrir les fonctions et les processus de l’entreprise aux partenaires externes, il ne parvient pas à dépasser totalement ses précurseurs monolithiques.  D'un côté, SOA permet de développer, tester et paramétrer les services simultanément, sans devoir subir des cycles de développement monolithiques. De l'autre côté, l’ESB est à son tour atteint du syndrome des monolithes. Les constructeurs y ajoutent de plus en plus de fonctionnalités, en particulier différentes logiques de transformation des formats des données et d’orchestration des services. Il devient ainsi un goulet d’étranglement et un potentiel point de défaillance sur le plan architectural et organisationnel.  Dans cet article, je présente l'architecture orientée service (SOA), suivie d'un exemple d'une implémentation SOA basée sur un bus de services d'entreprise et les problèmes qui en ont découlé.

Architecture Monolithique: forces et faiblesses

Dans le domaine de l’ingénierie logicielle, une architecture est dite monolithique lorsqu'elle centralise tous les traitements du logiciel au sein d’une même unité applicative. Une telle architecture possède un avantage dans le cas du développement d’applications simples, mais le prix à payer est lourd sur le moyen et long termes. Les évolutions logicielles sont de plus en plus difficiles à déployer au fur et à mesure que les besoins évoluent. L'implémentation d'un changement, même le plus simple, est susceptible de se transformer en un projet complexe, car les composants de l'application sont devenus fortement interdépendants et la modularité s'est dégradée. Par ailleurs, les nouveaux besoins ne peuvent pas être satisfaits par ces architectures fortement centralisées. La recherche des solutions à ces limitations est à l’origine de l’émergence des architectures basées sur les services en général, et des microservices en particulier. Dans cet article, je présente le concept des architectures monolithes, un exemple d'application construite suivant cette approche, ainsi que ses avantages et ses limites.