LIVRE BLANC

Bonnes pratiques
en matière de
microservices
Jeter les bases d'une innovation continue

1
Sommaire

Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Les microservices, pour quoi faire ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Avantages pour l'entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Les microservices, qu'est-ce que c'est ? 9

Modes d'utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
API-led Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Passerelle d'API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Le « micro » des microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Champ de responsabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Organisation et responsabilités de l'équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Portée des efforts .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Simplicité de déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Fondamentaux de la conception de microservices . . . . . . . . . . . . . 15

Orientation domaine métier de l'architecture

microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Microservices et monolithes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Modèles d'implémentation des microservices .. . . . . . . . . . . . . . . . . . . . . . 23

Command Query Responsibility Segregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Sourcing d'événements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Production continue d'applications composées . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Utilisation en libre-service des microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Microservices sur Anypoint Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Cycle de vie de bout en bout des microservices . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Conception et implémentation avec
Anypoint Design Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Production continue avec Anypoint Studio,
Maven et Docker .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Déploiement en tant que conteneur de microservices . . . . . . . . . . . . . 33
Déploiement sur CloudHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Microservices pilotés par les événements
avec Anypoint MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Gestion opérationnelle avec Anypoint Runtime Manager . . . . . . . . 37
Gestion des APIs avec la solution API d'Anypoint Platform . . . . . . 38
Publication et engagement avec Anypoint Exchange . . . . . . . . . . . . . . . . . 39
Analyse avec Anypoint Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Plateforme décentralisée pour les microservices . . . . . . . . . . . . . . . . . . . . . . . . 41
Plateforme unifiée pour les microservices .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Résumé .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

À propos de MuleSoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3
Synthèse

De nos jours, le monde des affaires est extrêmement

concurrentiel. Aucune entreprise, quels que soient sa taille
et son secteur, n'est à l'abri des perturbations. Il est plus
facile que jamais pour de nouveaux arrivants d'intégrer un
marché et de déstabiliser par la même occasion des secteurs
entiers. À moins d'être capable d'innover de manière agile et
au rythme de ses concurrents, une entreprise se laissera vite
distancer. Les grandes organisations dotées de processus et
de structures figés seront les plus durement touchées.

Les organisations qui ont réussi à jeter

les bases d'une innovation continue et
d'une approche flexible ont adopté des
architectures microservices pour répondre
rapidement aux exigences de leurs activités.

Toute organisation est capable d'exploiter les possibilités

offertes par la transformation digitale : il lui suffit pour cela de
gagner en agilité. L'entreprise plus agile emploie un système de
petites équipes hyper-focalisées qui innovent à grande vitesse
sur des unités de valeur commerciale bien définies, travaillant
de concert pour produire quelque chose de beaucoup plus
vaste. Nous appellerons cela une « entreprise composable ».
Pour devenir composable, une organisation doit changer la
façon dont son département IT soutient ses activités. Il s'agit
de créer de l'évolutivité grâce à des services réutilisables, et de
proposer l'utilisation en libre-service de ceux-ci.
La capacité de votre entreprise à changer rapidement, à
innover facilement et à égaler la concurrence dans tous les
domaines sur lesquels elle prend de l'avance est aujourd'hui
une nécessité stratégique. Elle vous permettra de prospérer

4
sur un marché en constante évolution et de créer de nouvelles
expériences clients dans de nouveaux contextes, en utilisant
de nouvelles technologies. Pour façonner des expériences
clients innovantes, votre entreprise a besoin que son équipe
IT lui fournisse des ressources digitales sous la forme de
fonctionnalités métiers clés capables de lui apporter une réelle
valeur dans des contextes multiples. C'est ainsi que l'IT peut
devenir l'allié des objectifs stratégiques de votre entreprise.
Les organisations qui ont réussi à jeter les bases d'une
innovation continue et d'une approche agile ont adopté des
architectures microservices pour répondre rapidement aux
innombrables exigences de leur activité.

5
Les microservices, pour quoi faire ?

Les microservices correspondent à l'évolution des principes

architecturaux préconisés qui façonnent la fourniture de
solutions aux entreprises sous la forme de services. Toutes
les entreprises, quel que soit leur secteur, doivent s'efforcer
de fournir l'expérience client idéale. En effet, les clients,
plus exigeants que jamais, n'hésiteront pas à délaisser une
entreprise trop lente pour répondre à leurs exigences. L'IT
doit fournir des solutions pouvant être adaptées pour offrir
au client une expérience holistique et uniforme sur tous les
canaux d'affaires.
Pour ce faire, l'architecture doit identifier et définir des
ressources digitales qui correspondent aux principales
fonctionnalités métiers. Ces ressources offrent le potentiel
de décomposer le couplage entre les canaux d'affaires et les
systèmes back-end de référence qui les approvisionnent. Un
microservice qui renferme une fonctionnalité métier clé et
adhère aux principes et objectifs de conception décrits ci-
dessous doit être considéré comme une véritable ressource
digitale. Il recèle de la valeur pour l'entreprise, car il peut
être adapté à une utilisation dans plusieurs contextes. Les
contextes d'utilisation du service sont les processus et les
transactions métiers, ainsi que les canaux au travers desquels
vos clients, collaborateurs ou partenaires interagissent
avec votre entreprise.

6
Avantages pour l'entreprise

Une architecture microservices s'adapte à l'activité de sorte

que ses évolutions puissent être gérées de manière agile. Les
transactions et les processus métiers sont automatisés grâce à
la composition de microservices. Lorsque des processus sont
modifiés ou que de nouveaux processus sont introduits, l'IT peut
réagir en créant de nouvelles compositions à partir des services.

La facilité et la rapidité avec lesquelles

votre entreprise peut changer
déterminera votre capacité à réagir
aux tendances de votre secteur et à
conserver un avantage concurrentiel.

La facilité et la rapidité avec lesquelles votre entreprise peut

changer déterminera votre capacité à réagir aux tendances de
votre secteur et à conserver un avantage concurrentiel. Avec
une logique de solution constituée de services composables,
l'IT peut progresser au rythme de l'activité et répondre
aux changements d'activité par la mise en œuvre de cette
logique de solution. L'innovation est le visage de cette agilité.
Elle peut prendre la forme de nouveaux canaux d'affaires
(comme Google, qui crée de nouvelles sources de revenus en
transformant ses APIs en produits), de nouvelles interactions
digitales avec les clients (comme Spotify, qui attire ses clients
via Uber), de tout nouveaux produits et services susceptibles
d'exiger des processus métiers entièrement nouveaux, ou de
la simple modification de processus métiers existants. Tout
cela constitue une véritable évolution. Les entreprises doivent
être en mesure de changer de cap en fonction des forces du
marché. Le département IT doit être capable de faciliter ces

7
évolutions en transformant ses ressources digitales existantes
en nouvelles capacités métiers.
Votre entreprise peut proposer une logique de solution de
manière décentralisée en standardisant des contrats de
microservices sous la forme d'APIs. Plusieurs équipes de
différents secteurs peuvent mettre en œuvre des services
avec leur propre choix de technologies, tout en restant en
adéquation avec les objectifs de l'entreprise. Cela illustre
l'évolution du rôle de l'IT, qui passe de fournisseur à partenaire,
pour permettre aux équipes des différents segments d'activité
d'adapter les fonctionnalités clés conçues par l'équipe centrale
à leurs besoins spécifiques.
Les microservices sont nativement capables de communiquer
entre eux grâce à l'adoption, à l'échelle du secteur, de normes
comme le HTTP et le JSON. En d'autres termes, ils sont
intrinsèquement interopérables. Ils facilitent ainsi l'échange
d'informations indépendamment de la façon dont ils ont été
mis en œuvre, car leur interface est définie selon des normes
qui existent déjà à l'échelle du secteur et qui sont également
définies par les équipes de votre organisation.
Votre entreprise peut sélectionner les meilleurs produits et
plateformes de fournisseurs grâce à l'interopérabilité offerte par
les interfaces standardisées. Pour la même raison, vos équipes
peuvent également choisir les meilleures technologies pour
implémenter les microservices avec une approche polyglotte
du développement.

8
Les microservices, qu'est-ce que c'est ?

Traditionnellement, les entreprises fournissent des

applications logicielles en silos. Celles-ci sont le résultat de
demandes isolées de départements individuels. Les logiciels
sont développés ou achetés conformément à ces cadres bien
délimités. Les processus métiers orientés client, eux, couvrent
généralement plusieurs départements. Le non-alignement
de ces deux réalités nécessite le double d'efforts et entraîne
la carence d'informations, ou la présence d'informations
imprécises, dans chaque solution. Or, ces informations
constituent un aspect central de l'intégration d'entreprise.
Le concept de service a évolué, car les organisations tentent
de considérer le processus métier comme le point focal des
exigences des solutions. La nécessité de modifier les processus
existants ou d'en inventer de nouveaux doit être satisfaite
par une réponse agile de la part de l'IT, qui doit s'adapter
au changement. Plutôt que de concevoir ou d'acheter des
« applications » au sens traditionnel du terme, une approche
orientée services définit la création de services comme le
pilier de la logique de solution, les services devenant des
éléments composables capables de répondre aux exigences
d'automatisation des processus métiers.

Modes d'utilisation
Le plus souvent, les microservices sont directement invoqués
par des appels d'API HTTP REST. Des normes comme le
RAML (Restful API Modelling Language) permettent de définir
formellement les APIs REST. Le RAML peut définir chaque
ressource et opération exposée par le microservice. C'est
une norme du secteur qui a gagné en popularité, car il s'agit
d'une approche simplifiée de la définition et de la publication
d'interfaces de microservices.

9
Lorsque les microservices contribuent à la réalisation d'une
transaction ou d'un processus métier complexe, une approche
axée sur les événements est également adoptée. L'idée est
que le microservice s'abonne aux événements de domaine
métier qui sont transmis à un agent, de messages. Les normes
comme JMS et AMQP dominent les principales technologies
des agents du secteur. L'utilisation d'un agent de messages
dans l'invocation du microservice renforce la fiabilité du
modèle d'utilisation. Même si le microservice s'est abonné à
une file d'attente, une rubrique ou un échange en arrêt de
fonctionnement au moment de la publication de l'événement,
le paradigme de messagerie garantit la réception du message
par le microservice une fois la connexion rétablie.
La composition des microservices est réalisée avec un
mélange d'appels directs via HTTP et d'appels indirects via
un agent de messages.

API-led Connectivity
Au regard de la conviction selon laquelle la conception d'une
capacité métier adaptable vaut beaucoup mieux que celle
d'une intégration tactique point à point, l'IT doit s'efforcer de
fournir des ressources accessibles via une invocation d'API et
un abonnement aux événements de domaine, et capables de
générer de la valeur pour l'entreprise dans divers contextes.

10
 Conception
d'app.

APIs d'expérience
(APIs conçues spécifiquement pour les applications)

Segment
Dév./IT

APIs de processus
(orchestration, APIs composables, microservices)

IT central
APIs système
(modernisation des systèmes legacy, connectivité aux applications SaaS, services Web & APIs RESTful)

Accessibilité et
propriété

Applications Systèmes Services Web FTP, fichiers Bases de Systèmes Applications

SaaS centraux données legacy

Figure 1: Classification des microservices

La ressource correspond essentiellement à une encapsulation

d'une fonctionnalité d'entité métier, comme un client, une
commande ou une facture. Ces APIs système ou microservices
système sont conformes au concept de service autonome
conçu avec un niveau d'abstraction suffisant pour masquer
les systèmes de référence sous-jacents. Aucune de ces
informations relatives au système n'est divulguée via l'API. La
responsabilité de l'API est distincte et indépendante de tout
processus métier particulier.
Les APIs système peuvent être modulés avec d'autres
APIs pour former des APIs de processus agrégées. La
composition des APIs système peut prendre la forme d'une
orchestration d'API explicite (appels directs) ou passer par
une chorégraphie API, plus fiable. Ces APIs sont alors pilotées
par des événements métiers pertinents dans le contexte de la
composition (exécution des commandes, par exemple).

Passerelle d'API
Les APIs système et de processus doivent être adaptées et
exposées en fonction des besoins de chaque canal d'affaires et
de chaque point de contact digital. L'adaptation est déterminée
par l'expérience digitale souhaitée : c'est ce que nous appelons
l' « API d'expérience ». Parfois, l'adaptation de l'API est motivée

11
par des raisons techniques : un mécanisme de sécurité
particulier peut être nécessaire sur un canal donné ; les types
de canaux peuvent varier énormément, tout comme le mobile,
le Web et les appareils ; la composition de plusieurs APIs
peut s'avérer nécessaire en fonction du modèle de services
back-end destinés à l'approche front-end. Dans d'autres
contextes, les divergences métiers doivent être satisfaites
avec des adaptations qui prennent en compte les exigences
particulières de différents groupes d'utilisateurs comme les
collaborateurs, les clients et les partenaires.
Dans tous ces cas de figure, l’approche de la passerelle d’API
est pertinente, car c’est ainsi que les compositions d’APIs et les
proxys sont déployés. La gestion des APIs facilite l'application
administrative d'une logique récurrente, comme la sécurité,
la limite de charge, l'audit et le filtrage des données vers les
APIs d'expérience sur la passerelle. L'utilisation de la gestion
des APIs pour appliquer des stratégies intégrant une logique
sur mesure accélère et facilite dans une certaine mesure
l'adaptation des APIs de système et de processus.

12
Le « micro » des microservices

Champ de responsabilité
Parmi les microservices, le plus évident des candidats est une
entité métier identifiable instantanément du point de vue d'un
processus ou d'une transaction métier. Un client constitue un
exemple d'une telle entité. Il s'agit d'une entité métier qui peut
être pertinente dans un certain nombre de contextes, tant au
niveau de la couche processus que de la couche expérience.
La responsabilité ne se limite pas à une simple transmission de
données. Un microservice ne doit pas être réduit à un simple
service CRUD. Chaque entité englobe toutes les responsabilités
associées au domaine métier pour lequel elle a été conçue.
Tout cela va de pair avec une limitation délibérée du champ de
responsabilité. « Discret » est l'interprétation la plus sensée du
préfixe « micro » au regard du champ de responsabilité. Cela
contribue à garantir que le microservice de niveau système
n'assume aucune responsabilité qui se rapporterait plus
adéquatement à un microservice de niveau processus métier.
Les microservices de niveau système sont indépendants de
tout processus métier particulier et peuvent donc être utilisés
dans plusieurs compositions.
Le champ d'un processus métier doit également être
appréhendé. Certains sous-domaines exécutent leurs
propres processus métiers locaux (l'expédition, par exemple).
Un microservice de niveau système peut être adapté à une
utilisation dans plusieurs processus au sein du domaine
d'expédition. Chaque fois que sa fonctionnalité est requise
en dehors du domaine, il peut être adapté à ce besoin avec
un microservice de niveau expérience. Il existe évidemment
des processus métiers, généralement orientés client,
qui traversent plusieurs domaines. La règle est alors de

13
composer plusieurs microservices adaptés à cette utilisation
dans les APIs d'expérience.

Organisation et responsabilités de l'équipe

Les équipes doivent être assez petites pour coopérer
localement et se concentrer entièrement sur un seul sous-
domaine de l'activité, mais aussi inclure des experts du
domaine afin que le langage de ce sous-domaine soit modélisé
dans la solution.
La propriété du microservice comprend tout, de la conception
au déploiement, en passant par la gestion. L'API est
appréhendée comme un produit métier, une ressource destinée
à l'entreprise. La gestion de l'instance en cours d'exécution n'est
pas transmise à d'autres équipes. La globalité du cycle de vie
appartient à l'équipe en charge de son développement.

Identification des microservices candidats

L'identification des microservices que vous devez concevoir et leur champ
de responsabilité peut nécessiter de réfléchir aux types d'informations
échangées dans les transactions qu'ils assurent. Dans un établissement
de santé, le patient, le rendez-vous et la demande en sont des exemples.
Un environnement e-commerce comporte la commande, l'article, la
remise ou le client. Une solution bancaire peut englober le transfert, le
compte et le bénéficiaire. La responsabilité doit être limitée et ciblée. Les
microservices de niveau système ne sont pas une abstraction touchant
tout un système back-end, mais seulement la partie du système ou des
systèmes responsables du stockage de l'entité métier.

Les transactions et les processus métiers sont souvent au centre

du travail de l'IT, car c'est le processus métier qui définit réellement
l'activité. Dans le secteur de l'e-commerce, il peut s'agir de l'exécution des
commandes. La visite d'un patient à l'hôpital pourrait être pilotée par le
microservice visite de l'administration.

Ce microservice est implémenté avec la composition des microservices

de la couche système. 14
Portée des efforts
Les microservices qui répondent aux besoins d'un sous-
domaine spécifique reconnaîtront que certains concepts
métiers sont perçus d'une manière spécifique à ce sous-
domaine. On ne tente pas de modeler une solution universelle,
à moins que l'entité soit naturellement commune à la totalité
de l'organisation.

Simplicité de déploiement
Les coûts, de la fourniture à la production, sont
significativement réduits par l'association de petites équipes
qui disposent d'une propriété complète, d'une responsabilité
distincte par rapport au microservice, et de l'infrastructure qui
facilite une production continue.

15
Fondamentaux de la conception
de microservices

Les fonctionnalités des microservices sont formellement

exprimées par des APIs orientées métiers. Elles encapsulent
une fonctionnalité métier clé et, à ce titre, constituent des
ressources pour l'entreprise. L'implémentation du service,
qui peut impliquer des intégrations avec des systèmes de
référence, est complètement masquée, l'interface étant
purement définie sous une perspective commerciale.
Le positionnement des services en tant que ressources
précieuses pour l'entreprise les rend implicitement adaptables à

Réutilisation
La réutilisation est et reste un principe de conception clé des
microservices. Néanmoins, le champ de réutilisation a été réduit
à des domaines d'activité spécifiques. Les efforts déployés pour
concevoir cette réutilisation, qui, dans les premiers temps du
SOA, incluaient des efforts inutiles visant à concevoir des modèles
canoniques à l'échelle de l'entreprise, étaient stériles car trop
ambitieux. Reste que le modèle canonique, dans son acception
limitée, peut présenter certains avantages. Tout comme la
réutilisation qu'il facilite, sa portée a été restreinte. Avec l'approche
de « réutilisation basée sur le mérite », un modèle émergent est
privilégié par rapport à une méthode prédéterminée. Les équipes
peuvent convenir de modèles de communication pour déterminer
comment adapter les microservices à une utilisation en dehors des
contextes dans lesquels ils ont été conçus. Un hub de collaboration
comme Anypoint Exchange encourage la réutilisation basée sur le
mérite par le biais de commentaires, d'évaluations, etc. Si une API de
microservices existante ne convient pas à votre domaine ou à votre
« groupe métier », peut-être est-il préférable de concevoir un autre
microservice adapté.
16
une utilisation dans des contextes multiples. Un même service
peut fournir ses fonctionnalités à plusieurs processus métiers
ou sur différents canaux d'affaires ou points de contact digitaux.
Les dépendances entre les services et leurs utilisateurs sont
minimisées par l'application du principe de couplage lâche.
En standardisant les contrats comme formulé par les APIs
orientées métiers, les consommateurs ne sont pas touchés
par les modifications apportées à l'implémentation du
service. Cela permet aux propriétaires de services de modifier
l'implémentation et de stopper ou modifier les systèmes de
référence, voire les compositions de services qui peuvent
sous-tendre l'interface, puis de les remplacer sans la moindre
incidence en aval.
L'autonomie est une mesure de contrôle présente sur
l'environnement d'exécution et le schéma de base de données
de l'implémentation du service. Elle améliore la performance
et la fiabilité du service et donne aux consommateurs plus de
garanties quant à la qualité du service qu'ils peuvent attendre.
Sans état et autonome, le service s'en trouvera également
globalement plus disponible et évolutif.
Chaque service est nécessairement tolérant aux pannes, de
façon à minimiser l'impact des défaillances du côté des services
avec lesquels il collabore sur son propre SLA. Les services,
du fait de leur indépendance, ont la possibilité de couper la
communication avec un service défaillant. Cette technique du
« disjoncteur » est inspirée du composant électrique éponyme
et empêche la propagation des pannes de service individuels à
travers le système distribué.
Tous ces principes de conception contribuent au principe de
composabilité qui permet au service d'apporter de la valeur à
l'entreprise dans différents contextes. Sa composition avec
d'autres services, qui vise à former un nouvel agrégat de
services, constitue effectivement la nouvelle approche du
développement d'applications.

17
L'objectif de la détectabilité est de communiquer à toutes les
parties concernées une compréhension claire de la finalité
métier et de l'interface technique du microservice. Ainsi, le
service doit être publié de sorte que les développeurs du
logiciel client disposent de tout ce dont ils ont besoin pour
l'utiliser facilement.

18
Orientation domaine métier de
l'architecture microservices

Il est important d'aborder la conception de service pour un

domaine spécifique et de ne pas insister pour le faire pour tous
les aspects de l'activité. L'échec des exercices de modélisation
canonique à l'échelle de l'entreprise de la dernière décennie en
témoigne. La réalité de l'entreprise est que les entités métiers
peuvent être perçues de manière très différente à travers les
différentes unités ou sous-domaines métiers.
Il ne faut pas tenter de concevoir des services à l'échelle de
l'entreprise lorsque chaque domaine a une perception très
différente du même concept. Exemple d'entité métier avec des
perceptions très différentes : le client dans les domaines du
service clients, des commandes, de la facturation
et de l'expédition.
Dans la Figure 2, vous remarquerez que chaque domaine
possède ses propres microservices qui intègrent des
capacités métiers clés pour ce domaine particulier. Cela
peut entraîner une duplication apparente des microservices,
comme c'est le cas pour l'API client.

19
 API Suivi de
Service clients Commandes

Expédition
APIs d'expérience
APIs
d'expérience API Expédition
API d'inscription en API Mon profil API Mes achats

API Exécution APIs

Expédition
API Inscription de commandes de processus
API Catalogue

API APIs
API API Client Recommandations API Client API Commandes
système
API Tokenization

Finances
APIs d'expérience

API Facturation
Agent de
messages

Systèmes de référence Systèmes de référence

Figure 2: Les microservices conçus pour des domaines métier particuliers

Comme les microservices communiquent entre eux, en

particulier ceux qui sont conçus pour différents domaines,
il peut être nécessaire de négocier un contrat adapté
aux besoins du logiciel consommateur. Cette adaptation
particulière se manifestera sous la forme d'une API
d'expérience spécifiquement personnalisée pour ce client. Elle
peut également prendre la forme d'un événement de domaine
publié dans une file d'attente.

20
Microservices et monolithes

Les microservices constituent une évolution fondamentale

dans la façon dont l'IT aborde le développement de logiciels.
Les processus de développement de logiciels traditionnels (en
cascade, agiles, etc.) incitent souvent des équipes relativement
grandes à travailler sur un artefact de déploiement unique et
monolithique. Les gestionnaires de projet, les développeurs et
le personnel opérationnel peuvent atteindre différents degrés
de succès avec ces modèles, en publiant des applications
candidates qui peuvent être validées par l'entreprise, en
particulier lorsqu'ils acquièrent de l'expérience à l'aide d'une
pile spécifique de logiciels et de mécanismes de déploiement.
Les approches traditionnelles comportent toutefois leur lot de
problèmes cachés :
›› Les applications monolithiques peuvent devenir
une « grande boule de boue », correspondant à une
situation dans laquelle aucun développeur individuel
(ni groupe de développeurs) ne comprend l'application
dans son intégralité. Ce problème est exacerbé lorsque
des développeurs senior se défont d'un projet et sont
remplacés par des développeurs junior ou offshore pour la
maintenance.
›› La réutilisation limitée est obtenue par le biais
d'applications monolithiques. Les applications
monolithiques, par définition, cachent leurs éléments
internes. Bien qu'une certaine réutilisation soit rendue
possible par des APIs à la « périphérie » du monolithe,
les chances de réutilisation des composants internes
demeurent limitées. Lorsque la réutilisation est obtenue,
c'est généralement à travers des bibliothèques partagées
qui favorisent le couplage étroit et sont limitées à la

21
 plateforme de développement utilisée pour la mise en
œuvre du monolithe.
›› Le scaling d'applications monolithiques peut être difficile.
Il est généralement impossible d'identifier et d'ajuster des
aspects spécifiques d'une fonctionnalité applicative pour
mieux isoler d'autres aspects, car toutes les fonctionnalités
sont regroupées dans un même artefact de déploiement.
Le scaling d'applications monolithiques ne se fait
généralement pas en « temps réel ».
›› On atteint rarement l'agilité opérationnelle en déployant de
manière répétée des artefacts d'application monolithiques.
Si l'automatisation opérationnelle peut atténuer la plupart
des lourdeurs manuelles du déploiement de ces applica-
tions, par exemple en automatisant le provisionnement des
machines virtuelles ou en configurant automatiquement les
périphériques réseau, il arrive toujours un moment où les
développeurs sont bloqués parce que l'équipe d'exploita-
tion attend que ces activités se produisent. Dans le pire des
cas, lorsque l'automatisation n'est pas en place, les dével-
oppeurs et les opérateurs subissent une énorme pression
chaque fois qu'un déploiement échoue ou qu'un problème
de production survient.
›› Par définition, les applications monolithiques sont
implémentées à l'aide d'une pile de développement unique
(par exemple, JEE ou .NET). En plus de limiter la réutilisation
pour les applications qui ne sont pas implémentées sur
cette pile, elles suppriment également la possibilité d'utiliser
« le bon outil pour le job ». Par exemple, l'implémentation
d'une petite portion d'une application JEE avec Golang
serait difficile dans une application monolithique.
Associée à des technologies de déploiement cloud, de gestion
des APIs et d'intégration, une architecture microservices
offre une approche alternative au développement de logiciels
évitant le développement d'applications monolithiques. Le
monolithe, pour sa part, est plutôt « décomposé » en un
22
ensemble de services indépendants développés, déployés et
entretenus séparément. Cette façon de procéder présente les
avantages suivants :
›› Des services de plus petite taille sont encouragés.
Idéalement, ils sont conçus par une poignée de
développeurs « que deux boîtes à pizza suffiraient à
nourrir », pour reprendre l'expression de Jeff Bezos. Cela
signifie qu'un petit groupe, voire un développeur unique,
peut comprendre l'intégralité d'un microservice unique.
›› Si les microservices exposent leurs interfaces avec un
protocole standard, comme une API RESTful ou un échange

Éviter les monolithes distribués

Le danger que les nouvelles tendances architecturales présentent,
c'est qu'elles sont perçues comme un remède miracle aux problèmes
de l'IT et qu'elles doivent être utilisées comme la « dernière meilleure
chose », sans discernement à l'égard des conditions préalables
concernant le modèle d'exploitation IT, l'infrastructure et les
compétences de développement.

Une stratégie de microservices doit adopter une approche

prudente et mesurée comme la suivante pour en tirer un maximum
d'avantages : à ce titre, nous recommandons fortement la conception
et la construction de microservices englobant des fonctionnalités
pour des domaines métiers spécifiques. Sans cela, le risque est
de finir par construire une suite de microservices monolithique,
c'est-à-dire un monolithe distribué présentant tous les défauts du
monolithe, un surplus de complexité en matière de distribution, et
une réduction du retour sur investissement global.

Nous préconisons également d'établir une discipline stricte de

production continue et de se doter des outils nécessaires pour
l'automatisation du pipeline de distribution. En l'absence d'une
coordination et d'une automatisation d'équipe de type DevOps, votre
adoption des microservices fera plus de mal que de bien.

23
 AMQP, ils peuvent être utilisés et réutilisés par d'autres
services et applications sans couplage direct via des liaisons
de langage ou des bibliothèques partagées. Les registres de
services peuvent faciliter la découverte de ces services par
d'autres groupes.
›› Les services existent en tant qu'artefacts de déploiement
autonomes et peuvent évoluer indépendamment des
autres services.
›› Le développement discret des services permet aux
développeurs d'utiliser le framework de développement
approprié pour la tâche en cours. Les services s'associant
à d'autres services dans une API composite, par exemple,
peuvent être plus rapides à implémenter avec MuleSoft
qu'avec .NET ou JEE.
L'inconvénient d'une telle souplesse est la complexité. La
gestion d'une multitude de services distribués à grande échelle
n'est pas chose facile :
›› Les équipes de projet doivent pouvoir découvrir facilement
le potentiel de réutilisation des services. Ces services
doivent s'accompagner d'une documentation, de consoles
de test, etc., afin qu'il soit beaucoup plus facile de recourir à
la réutilisation que de repartir de zéro.
›› les interdépendances entre les services doivent être
étroitement surveillées. Les temps d'arrêt des services,
les pannes de services, les mises à niveau de services, etc.
peuvent tous avoir des effets en cascade en aval et un tel
impact doit être analysé de manière proactive.
Le cycle de vie des services SDLC doit être hautement
automatisé. Cela requiert des technologies, comme des
technologies d'automatisation de déploiement et des
frameworks CI, mais surtout de la discipline de la part des
développeurs et des équipes opérationnelles.

24
Modèles d'implémentation
des microservices

Command Query Responsibility Segregation

La classification des microservices en types de système,
de processus et d'expérience peut encore être subdivisée
en fonction des exigences d'évolutivité. La plupart des
requêtes faites aux microservices concernent la récupération
d'informations à des fins de présentation. Un nombre de
requêtes moindre permet de gérer une fonction métier
fluctuante, comme un client qui modifie son profil personnel
ou qui soumet une commande. On distingue ces différents
types de demandes en tant que requêtes pour la récupération
d'informations et en tant que commandes pour la fonction
métier fluctuante.
Certaines exigences liées à un trafic élevé peuvent
nécessiter une séparation délibérée du déploiement afin
que la fonctionnalité métier en question soit divisée en deux
microservices : l'un dédié aux commandes et l'autre aux
requêtes, en conformité avec le modèle Command Query
Responsibility Segregation (CQRS) émergent.

Sourcing d'événements
Le principe d'autonomisation de la conception de
microservices exige que chaque microservice possède
son propre magasin de données. Le partage de bases de
données est évité. Cela devient problématique lorsque l'on
considère notre approche du point de vue de l'automatisation
d'une transaction métier. Nous avons recommandé des
microservices de type processus métier dont la responsabilité
est de composer des microservices de type système à
travers l'orchestration et la chorégraphie. Naturellement,
l'échange d'informations pour toute transaction métier est
25
relié, mais chaque microservice système joue son rôle dans la
collaboration, indépendamment du reste. L'état final de toute
la composition doit préserver la cohérence des données.
Le secteur s'éloigne des transactions distribuées pour
résoudre ce problème. Ainsi, on constate que le fait que
chaque microservice possède son propre magasin de données
pour, en fin de compte, présenter les mêmes informations
à un niveau supérieur, peut à tout moment entraîner une
incompatibilité. On observe surtout ce phénomène avec
une approche axée sur les événements de domaine dans
laquelle les microservices collaborant dans une chorégraphie
fonctionnent de manière asynchrone, mus par des événements
de domaine transmis à un agent de messages. Ici, la cohérence
finale est la clé. Lorsque chaque microservice a terminé son
travail, l'ensemble du système se trouve dans un état cohérent.
Cela donne lieu à un modèle émergent dans lequel les
changements d'état sont stockés en tant qu'événements
métiers journalisés. L'état actuel est connu non pas en
récupérant des données depuis un magasin, mais en
parcourant l'historique des événements métiers et en le
calculant à la volée.

Production continue d'applications composées

Le fait de donner aux équipes les moyens de sortir des logiciels
en continu fait partie des principes de développement agile.
La production continue de logiciels permet aux intervenants
commerciaux de vérifier, en temps réel, qu'une application
répond à l'objectif métier final. Du point de vue des
applications microservices composées, la production continue
est également synonyme d'intégration continue. Dans les
applications composées de nombreux services, il est essentiel
de s'assurer que la composition fonctionne réellement lors de
la conception du logiciel.

26
Des cycles courts de mise sur le marché, des retours rapides
sur les défauts de conception et des systèmes de déploiement
automatisés sont essentiels à la mise en œuvre d'une
production continue.

Utilisation en libre-service des microservices

Chaque département d'une entreprise a besoin de
technologies pour concevoir de nouvelles applications pour
sa fonction ou son client spécifique. L'IT doit abandonner sa
fonction traditionnelle de simple fournisseur de technologies
pour devenir une organisation adaptative, réactive et agile
capable de suivre le rythme de l'ère digitale et de saisir
les opportunités que recèle un environnement axé sur les
évolutions. Cette transformation ne peut avoir lieu que si l'IT
se transforme en catalyseur d'activité stratégique plutôt qu'en
fonction technologique centralisée.
Le rôle de catalyseur de l'IT lui impose de décentraliser et de
démocratiser le développement d'applications et l'accès aux
données des différents segments d'activité et partenaires
commerciaux fonctionnels. De cette façon, l'IT peut se
concentrer sur un partenariat avec l'entreprise, par exemple en
mettant à disposition un ensemble cohérent de ressources et
de technologies stratégiques.
Toutefois, une telle approche peut avoir un inconvénient, à
savoir la prolifération des services. La gestion de ces services à
grande échelle engendre un certain nombre de défis :
›› Identification et documentation des services
›› Tolérance aux pannes
›› Qualité de service
›› Sécurité
›› Traçabilité des requêtes
›› Triage des défaillances

27
Il est impératif que vous puissiez facilement gérer vos
microservices d'une manière simplifiant leur accès en libre-
service dans tous les segments d'activité de votre entreprise.
La gestion des APIs représente l'évolution de la gouvernance
des services qui vous permet de réaliser ce qui suit :
›› Publiez vos APIs afin que les développeurs de logiciels
qui les utilisent disposent de tout ce dont ils ont besoin
pour répondre à leurs besoins en libre-service et
comprennent clairement l'objectif, la portée et l'interface de
votre microservice.
›› Personnalisez vos APIs grâce à des stratégies de logique
injectables couvrant la sécurité, la qualité de service, l'audit,
le filtrage dynamique des données, etc.
›› Surveiller vos APIs de façon à pouvoir prendre des
décisions stratégiques en matière d'évolutivité en fonction
des niveaux de trafic et jauger l'impact de vos ressources.
›› Adaptez vos APIs aux besoins spécifiques des différents
segments d'activité afin que la gestion des APIs devienne un
exercice décentralisé ou fédéré opéré par une coopération
entre les segments d'activité et le département IT central.

28
Les microservices sur Anypoint Platform

Anypoint Design Center Anypoint Management Center

• Studio™ • Runtime Manager™

• API Designer™ • API Manager™
• Connector DevKit™ • Analytics™
• Access Management™
Anypoint Exchange
• Portail d'APIs

Mule runtime engine

Anypoint Connectors

Services • Haute disponibilité • Sécurité de • Cloud privé

d'exécution l'entreprise virtuel

Cloud hybride • CloudHub™

Anypoint Platform résout les problèmes de connectivité

les plus difficiles. Il s'agit d'une plateforme d'intégration
hybride, unifiée et hautement productive qui crée un réseau
d'applications, de données et d'appareils homogène avec
l'API-led Connectivity.
Contrairement à d'autres solutions, Anypoint Platform est
accessible en tant que solution cloud ou peut être déployé
localement, ce qui permet aux développeurs de connecter,
d'orchestrer et d'activer rapidement n'importe quelle
application interne ou externe. Anypoint Platform allège les
lourdeurs du code personnalisé et offre la rapidité et l'agilité
nécessaires pour débloquer le potentiel de cette ère connectée.

29
Cycle de vie de bout en bout des microservices
MuleSoft adopte une approche holistique des microservices.
Contrairement aux applications traditionnelles, le
développement de microservices idéal commence par une
approche top-down axée sur les APIs. Autrement dit, il existe
des étapes supplémentaires par rapport aux cycles de
développement de logiciels (SDLC) traditionnels.
Par exemple, l'aspect de la conception est généralement un
processus itératif qui comprend :
›› La modélisation de votre API à l'aide de spécifications
standard comme le RAML.
›› Il est généralement souhaitable de simuler vos
caractéristiques à l'aide d'un terminal d'API fictif vous
permettant de solliciter les retours des utilisateurs
de votre API.
›› Il convient également de valider le tout par rapport
à du code réel pour appréhender au mieux l'API et
fournir des retours.
›› Une fois la conception de l'API ratifiée, vous devez la
construire à l'aide de votre langage préféré, avec du code
qui inclut une logique métier et une connectivité aux
systèmes back-end appropriés.
›› Créez ensuite des scripts de test si vous suivez l'approche
recommandée de conception pilotée par les tests.
›› Une fois le microservice déployé, vous souhaitez
généralement publier la documentation de votre API à
l'aide d'un portail utile pour attirer et fidéliser les
utilisateurs de votre microservice.
›› Enfin, lors de la mise en œuvre, vous avez besoin de gérer
le runtime du microservice, ainsi que ses APIs (par exemple,
appliquer des stratégies de sécurité et de throttling) et
d'obtenir des données analytiques d'utilisation concernant

30
 votre microservice. Les analyses peuvent être utilisées à des
fins de gestion/suivi ou de mesure et de rétrofacturation.

API Notebook API Console

GEFTEEFDEB
EADC
BKAC
K
E

N O
TIT
Anypoint Exchange

DAA
LLI ID

MOSDÉL
VVAA
Mocking Service

IMUISA
LATTIO
Anypoint Analytics CO
ONE
IT NDC
EEPS
UTA

EN
ÉECR TIIG
ON
EXP N
O API Designer

MAEL
HÉ D
SC M O
Anypoint Exchange
SHN
LITIO
BLBICA

CRÉATION
Anypoint Studio
BUILD
PU
PU

API Portal
Anypoint Exchange
MA
GE

AG T
ST

ES
SN

TTE
TI

E
ON

API Manager D EP LOY

DÉPLOIEMENT MUnit

Figure 3: Cycle de vie de bout en bout des microservices

À présent, nous allons nous intéresser en détail à chaque

phase du cycle de vie idéal du microservice, et voir comment il
peut être exécuté avec AnyPoint Platform.

Conception et implémentation avec

Anypoint Design Center
La conception d'un microservice doit commencer par la
définition de son API. L'API peut être basée sur REST ou
pilotée par les événements, conformément aux deux modes
d'utilisation. API Designer vous permet de définir une API
REST à l'aide de RAML. RAML est une norme qui a rapidement
été adoptée en tant que langage léger idéal pour définir des
APIs. Lorsque vous définissez les ressources et opérations
de l'API dans RAML, API Designer génère automatiquement
une console qui centralise la documentation et la testabilité.

31
Cet outil génère en outre un service bouchon déployé sur
CloudHub, le tout automatiquement. Cela vous offre le luxe
de permettre à l'équipe responsable du développement
des logiciels consommateurs de créer le code par rapport
à l'implémentation factice, parallèlement à l'équipe qui doit
implémenter le véritable microservice. L'équipe responsable de
la conception du logiciel consommateur peut ainsi présenter
son travail avant même que le microservice ne soit développé.

32
À propos de MuleSoft, une société Salesforce

La mission de MuleSoft consiste à aider les organisations

à évoluer et à innover plus rapidement en facilitant la mise
en relation des applications, des données et des appareils à
travers le monde. Grâce à son approche de la connectivité
dirigée par les API, la solution AnyPoint Platform de MuleSoft™,
leader sur le marché, fournit à plus de 1 600 organisations
réparties dans environ 60 pays les outils leur permettant de
créer des réseaux d’applications. En déverrouillant l’accès
aux données à l’échelle de l’entreprise grâce aux réseaux
d’applications, les organisations peuvent facilement générer
de nouvelles sources de revenus, améliorer l’efficacité
opérationnelle et créer des expériences client différenciées.
Pour plus d’informations, rendez-vous sur mulesoft.com

MuleSoft est une marque déposée de MuleSoft LLC, une société Salesforce.
Toutes les autres marques sont celles de leurs propriétaires respectifs.

33