Vous êtes sur la page 1sur 12

ARCHITECTURES MICRO-
SERVICES : OBJECTIFS,
BÉNÉFICES ET DÉFIS -
PARTIE 1

Après plusieurs années de développement logiciel et de maintenance,


certaines applications d’entreprise s’avèrent laborieuses et trop coûteuses
à faire évoluer. Ce type de dette technologique est un constat, une
dif culté majeure, que rencontrent à terme de nombreuses entreprises.

Cela conduit souvent à faire table rase des développements passés, et à


les reconstruire à partir de zéro. L’essor des architectures micro-services
 (micro-services architectures – MSA) répond à cette problématique, et 
propose des moyens de la résoudre.

Les architectures micro-services permettent de développer, de déployer et


de gérer opérationnellement des applications distribuées, constituées de
services aux fonctionnalités complémentaires, potentiellement
hétérogènes et interopérables.

Les micro-services favorisent drastiquement l’indépendance des cycles de


vie, qu’il s’agisse des cycles de conception, de développement, ou de
déploiement en production.
 

Elles se distinguent des architectures orientées services (SOA), répandues


depuis environ une décennie :

 

Elles émergent de la recherche d’une agilité pratique et d’une


ef cacité accrue par des précurseurs du Cloud Computing, tels que 
Net ix, Amazon, Gilt ou Airbnb.

Elles sont naturellement adaptées au Cloud, et se déploient


nativement sur les « Platforms as a Service » (PaaS). Il s’agit du type
de plateformes sur lesquelles elles se sont développées et déployées
historiquement, et elles en exploitent naturellement les béné ces.

Elles ne dépendent aucunement d’une solution d’éditeur logiciel, tel


que les Enterprise Service Bus (ESB), et minimisent les besoins
d’intégration logicielle (EAI), mettant en œuvre des solutions
décentralisées et alternatives aux fonctionnalités sophistiquées des
ESB (médiation, orchestration de services, etc…)

OBJECTIFS DES ARCHITECTURES MICRO-


 SERVICES 
« Qu’est-ce que l’architecture ? », Martin Fowler reprend à son compte la
question dans son article ’Who Needs an Architect?’ . Il y développe sa
propre dé nition :

À première vue, l’architecture d’une application se résume en la


décomposition de la totalité du système applicatif considéré en
éléments constitutifs plus simples, aux rôles, responsabilités et limites
bien identi és.

Mais, du point de vue pratique des personnes en charge d’une


application, l’architecture, c’est surtout, ce qu’il est dif cile de
changer. De ce point de vue, l’architecture doit faire l’objet de
décisions saines en amont d’un projet a n de minimiser les coûts
d’évolution.

En effet, les évolutions d’une application nécessitent un effort


d’adaptation, et le coût qu’elles induisent s’accroît au fur et à mesure 

que le système se complexi e. L’évolution d’un système a ainsi


naturellement tendance à ralentir au l du temps, et ce d’autant plus vite
que « ce qu’il est dif cile de changer » s’accumule.

En conclusion et un peu paradoxalement, une bonne architecture est


minimaliste, et permet de changer facilement n’importe lequel de ses
composants.

Les principaux buts des architectures micro-services sont :

de réduire les empêchements au changement,

de libérer les développeurs et les opérationnels des contraintes de la


complexité,

et nalement d’accroître la compétitivité de l’entreprise.

Quelles sont les caractéristiques des architectures micro-services ?

Les architectures micro-services ne font pas actuellement l’objet de standards, ou de dé nitions

 bien arrêtées. Cependant, des tendances se sont dégagées au l du temps, et leurs principales 
caractéristiques sont maintenant bien identi ées:

1 Cohésion interne d’un micro-service

Un micro-service est censé béné cier d’une forte cohésion interne: le périmètre fonctionnel des

fonctionnalités qu’il implémente doit être réduit, et essentiellement dédié à une fonctionnalité

élémentaire.

Le périmètre fonctionnel d’un micro-service peut être relié à la notion de contexte

délimité (ou bounded context) issue de l’approche de conception pilotée par le domaine –

 Domain Driven Design (ou DDD).

Dans l’acronyme SOLID désignant 5 principes de conception orientée objet le S fait référence au
Dans l acronyme SOLID, désignant 5 principes de conception orientée objet, le S fait référence au

principe de responsabilité unique (SRP), dé ni ainsi par Robert Martin: ‘Gather things that change

for the same reson, and separate things that change for different reasons’. Ce principe trouve tout

son sens dans un contexte de micro-services.

2 Découplage entre les micro-services

Dans une architecture micro-service, le logiciel est décomposé en un ensemble de services

hautement indépendants.

Chaque micro-service peut être:

déployé indépendamment

conçu et développé indépendamment


 
testé indépendamment

En conséquence, chaque micro-service peut évoluer de façon plus indépendante que dans une

approche « monolithique ».

Cela confère à ce style d’architecture une réactivité au changement considérablement accrue. Les

MSA permettent de répondre d’autant mieux aux objectifs de réactivité et d’adaptabilité des

approches Agiles.

3 Distribution des micro-services

A n d’atteindre ce niveau de découplage, chaque micro-service doit être un processus système

indépendant, isolé sur une machine distincte ou déployé dans un conteneur.

La communication entre les clients et les micro-services, ou entre les micro-services eux-mêmes, est

implémentée par des services web ou un protocole d’échanges de messages avec ou sans

 modèle d’acteurs.

QUELS SONT LES BÉNÉFICES CLÉS DES
ARCHITECTURES MICRO-SERVICES ? 

1- LA RÉDUCTION DU DÉLAI DE MISE EN MARCHÉ OU « TIME TO


MARKET »

L’indépendance fonctionnelle et technique des micro-services trouve son
pendant dans l’autonomie des équipes en charge.

La répartition des responsabilités dans l’organisation permet de travailler


en parallèle sur des briques logicielles dont le périmètre fonctionnel et la
complexité sont réduites, en comparaison d’une application
monolithique.

L’autonomie de l’équipe en charge du micro-service doit être la plus


complète possible et doit concerner toutes les phases du cycle de vie
(développement, tests, déploiement et exploitation).

Le délai de mise en marché d’évolutions fonctionnelles se voit réduit au


délai nécessaire à la mise en œuvre des évolutions du ou des micro-
services concernés.

2- L’AGILITÉ TECHNOLOGIQUE
 
Les micro-services étant indépendants et interopérables, ils ne sont pas
contraints à une uniformité technologique.

Les choix technologiques peuvent ainsi être adaptés aux besoins


spéci ques de chaque micro-service.

Il est ainsi possible d’utiliser un serveur de bases de données non-


relationnel plus performant en écriture et plus extensible pour un micro-
service de gestion d’historique.

Cette approche qui conduit à une forme persistance polyglotte est


d’autant plus pertinente que le modèle de donnée sur lequel le micro-
service opère est indépendant du reste de l’application.

La liberté et la exibilité technologiques obtenues permettent d’introduire


des innovations technologiques progressivement, en limitant le risque
 
encouru: le périmètre impacté est réduit à celui du micro-service
concerné.

3- L’EXTENSIBILITÉ

Dans une application, certaines fonctionnalités sont plus utilisées que


d’autres.

Le découpage en unités fonctionnelles indépendantes permet de


répliquer sélectivement le micro-service requis, plutôt que de mettre en
œuvre une redondance globale de l’application monolithique.

D’autre part les micro-services ne maintiennent en principe pas d’état de


D autre part, les micro services ne maintiennent en principe pas d état de
conversation entre 2 appels client. Cette nature « sans état » (ou
« stateless ») des micro-services facilite l’adaptation du système à la
montée en charge, les instances des micro-services en cluster étant
indépendantes entre elles. La répartition de charge est assurée au moyen

d’un routeur et d’un service de découverte, d’enregistrement et de


localisation des micro-services déployés. 
4- LA FACTORISATION ET LA RÉUTILISATION DES MICRO-SERVICES

La nature distribuée des architectures micro-services permet la


composition des fonctionnalités métiers et favorise la réutilisation.

Pour cela, il est nécessaire de concevoir la décomposition en micro-


services de façon à créer des modèles de données cohésifs :

un découpage trop large risque de produire des unités fonctionnelles


qui manquent de cohésion;

un découpage trop n risque de multiplier les appels entre micro-


services et de produire une communication réseau trop verbeuse.

Le point d’équilibre est atteint en réalisant un compromis entre des coûts


de communication maîtrisés et une cohésion interne forte du modèle de
données propre à chaque micro-service.
 
5- EVOLUTIVITÉ

La modernisation d’un micro-service est facilitée par l’étendue de son


périmètre fonctionnel et sa complexité relativement faible. Les
changements technologiques ne débordent pas du périmètre (que ce soit
une réécriture totale ou partielle), et les contraintes d’interopérabilité
concernent le respect du protocole de communication existant entre le
micro-service et ses clients.

Pour les mêmes raisons, la suppression d’un micro-service ou son


agrégation avec un autre micro-service sont également des opérations
l l à l l h
nettement plus simples à mener que pour une application monolithique.

De plus, les déploiements de micro-services en production sont gérés de


manière indépendante les uns des autres, ce qui réduit également le coût
de mise en production d’une évolution technologique et le risque
associé.

Ces éléments favorisent l’évolutivité d’une application constituée de


micro-services. 
6- RÉSILIENCE

La distribution des micro-services en processus systèmes techniquement


indépendants permet une meilleure continuité de service lorsqu’une
panne survient.

Il est pour cela nécessaire de mettre en place des technologies de


mitigation des pannes.

Et notamment :

Des technologies d’indexation et de découverte des services (service


discovery) tels qu’Eureka de Net ix;
Des technologies de répartition de charge (load balancing) entre
instances.

L’utilisation de patrons de conception tels que Circuit Breaker.


 
 

Retrouvez les dé s soulevés par les micro services dans une 2e partie.

Auteurs : Eric Manuguerra, Directeur Technique,  et Guillaume Yziquel,


Développeur Java/Angular JS, SQLI Suisse.

29 FÉVRIER 2016 1 COMMENTAIRE PAR SQLI


MOTS-CLÉS : ARCHITECTURE, CLOUD, MICRO SERVICES, SOA, SOLID

PARTAGER CET ARTICLE

        

VOUS AIMEREZ PEUT-ÊTRE AUSSI



Architectures micro-services : Série AWS - Les bonnes
objectifs, béné ces et dé s - pratiques pour débuter sur
Partie 2 AWS

Série AWS - Le serverless sur Réaliser une API management


la plateforme AWS : notre avec Tyk et docker
avis

Comment mettre en place IOT : connecter l'usine avec


Kubernetes ? Partage un Arduino - Partie 2
d’expérience de devs

1
RÉPONSE

Alexandre kouassi N'guessan


4 mai 2020 à 10 h 15 min
 
Magni que

Répondre

VOTRE COMMENTAIRE
Nom *

Adresse de messagerie *

Site web


Laisser un commentaire

INSCRIPTION DERNIERS RECHERCHES


NEWSLETTER ARTICLES POPULAIRES
Les PWA sont-elles Micro services
Adresse e-mail*
le fruit défendu deep learning
d'Apple ? angular
Valider
18 novembre 2020 - blockchain
7 h 30 min deep learning pas pas
COMMENTAIRES Créez une PWA xamarin
RÉCENTS avec Blazor en un agile
rien de temps ! agilité
Hugo dans Flutter : tout le
monde en parle, mais
4 novembre 2020 - ecmascript
pourquoi ? 8 h 00 min
micro service

 SAP Commerce 
Eugène dans Flutter : tout le
monde en parle, mais Cloud en n RECHERCHES
pourquoi ? disponible dans le RÉCENTES
Cloud
analytics
Sébastien Bernard dans Blazor 21 octobre 2020 - 8
WebAssembly : les différences blazor datagrid
h 00 min
avec Blazor Server en un coup blazor
d’œil Angular : de
micro service
l’avant-vente à la
Rémy dans Blazor ecmascript
maintenance
WebAssembly : les différences
14 octobre 2020 - 8
avec Blazor Server en un coup
h 30 min
d’œil
Nettoyage de
Sijelmassi Mehdi dans Angular
données : nos
: de l’avant-vente à la
bonnes pratiques
maintenance
p q
maintenance
pour les
développeurs
8 octobre 2020 - 7
h 30 min

GraphQL,
promesse magique

ou nuage de fumée
? (2/2)
2 octobre 2020 - 8

h 15 min

© Copyright 2012 - 2019 SQLI Plan du site Mentions légales     

 