CWIN17 Morocco / Microservices architecture ghofrane benaziz

Microservices :
Nouvelle architecture logicielle
CWIN 2017
Présenté par : Ghofrane BENAZIZ

2Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Sommaire
Les architectures monolithiques et leurs problèmes
Présentation de l’architecture Microservices
Les principes du Microservices
La mise en œuvre
Quels outils?
Quelle organisation ?
Les limites des Microservices
Conclusion

Les architectures monolithiques et leurs
problèmes

L’architecture monolithique est l’une des plus répandues dans les projets informatiques.
Projet de petite taille : Architecture très simple, testabilité, maintenabilité et déploiement faciles..

Au cours de l’évolution :
Maintenabilité du code Dépendance aux technologies
Pas de frontières fortes entre les modules
Relations de dépendance plus complexes
Code de moins en mois lisible et testable
Application dépendante à certaines technologies
Technologies obligatoirement compatibles entre elles
Framework utilisé devient obsolète
La productivité et la qualité
baissent
Migration vers un nouveau peut
nécessiter la réécriture complète
de l’application
• Java : Evolutions futures
limitées aux technologies
compatibles avec la JVM
• C# : Limitations aux
technologies Microsoft

Déploiement en continu : Application monolithique simple à déployer : toute l’application est destinée à s’exécuter sur un même
serveur.
Limitation : Déployer toute l’application, quelles que soient les modifications réellement effectuées, pose divers problèmes :
Le temps de déploiement s’allonge,
Le déploiement continu devient plus complexe
Les risques associés augmentent à chaque déploiement : perte de productivité
Développement Tests et intégration Recette Mise en production
Intégration continue
(développement)
Déploiement continue
(infrastructures)

Scalabilité: Lorsque la charge d’une application augmente, la scalabilité de l’application devient un point critique :
Les différents composants de l’application n’ont pas les mêmes besoins en ressource (processeur, mémoire, E/S,...)
Scaler une application monolithique peut entraîner une augmentation de la consommation des ressources
conséquentes de manière inutile.

Présentation de l’architecture
Microservices

Présentation de l’architecture microservices
Isoler chaque fonctionnalité
dans un composant qui lui est
propre. => Service
Les différents services
communiquent au travers du
réseau plutôt que par des
appels de fonctions dans un
processus.
Chaque unité indépendante a
un cycle de vie et une
responsabilité propre.
Répond à des problèmes
récurrents que posent les
architectures monolithiques.

Les principes des microservices

L’application devient un SI, dont
le microservice constitue l'unité
élémentaire.
Permettre aux services de
scaler facilement et
distinctement.
Il devient aussi possible d’allouer les ressources
souhaitées à chaque type de service
Chaque service peut ainsi utiliser les
technologies les plus adaptées à son
besoin
Elles ont chacune leur propre base
de code de données
Ces unités sont strictement
indépendantes les unes des
autres.
Une nouvelle échelle :

La présence d’une
anomalie sur une
fonctionnalité ne
bloque pas
l’évolution ou le
déploiement d’une
autre
l’évolution en
question ne
porte que sur le
code d’un
service en
particulier.
Mise à jour et
redéploiement
uniquement du service
impacté car il s’exécute
dans un processus
isolé.
Les autres services
ne seront pas
impactés.
Evolutivité
Lorsqu’une fonctionnalité précise du SI doit être modifiée :

Pour que le système fonctionne correctement, il est donc nécessaire que les microservices communiquent entre eux.
Les deux modes de communication les plus courants sont celles de type :
une architecture microservices va tendre vers une architecture réactive, à base d’évènements
déclenchés et écoutés par les services.
Communication

Microservices en REST
Un des moyens les plus simples de faire communiquer ces services entre eux est de le faire à travers le protocole HTTP via une API REST :
Chaque partie métier
de notre application
représente un
service indépendant
exposant sa propre
interface.
Les autres services
du système
communiqueront
avec lui.
Gateway
Inventory
Manager
Service
Back in
Stock
Notifier
Service
Email
Service
Subscriber
manager
Service
REST Request
REST Response

Microservices en REST
Ce type d’architecture permet de mettre en place simplement des microservices grâce à un système de communication
couramment utilisé.
Néanmoins ce système révèle plusieurs problèmes :
Les appels REST sont
synchrones, si un service
ralentit, l’ensemble du système
s’en trouve impacté
La multiplication des services
peut entraîner un effet
« spaghetti » entre les liens de
communication
Concevoir une architecture reposant sur
des messages asynchrones
Un service consomme un autre en
communicant une adresse de callback
Cette adresse de callback sera appelée
lorsque le traitement sera terminéSolution

Microservices à travers un BUS
La communication par bus de messages est fortement poussée dans les architectures microservices. Elle apporte une réelle souplesse.
Chaque service envoie des messages sur
le bus qui seront consommés ensuite par
d’autres services
Chaque service ne connait que le bus de
messages comme intermédiaire.
Les liens directs entre services sont
coupés.
Tout ce qui se passe dans le système est asynchrone.

Microservices à travers un BUS
Le bus d’événements est basé sur le protocole AMQP (Advanced Message Queing Protocol)
Solutions de bus d’événements basés sur AMQP :
Pivotal Apach Apache JBoss
RabbitMQ : le plus utilisé et documenté

Cet asynchronisme présente plusieurs avantages
Le système devient résistant à la lenteur
Le système devient tolérant à la panne
Le système devient facilement scalable.
Trois instances du
même microservice
Utiliser le loadbalancer
pour équilibrer la charge

Force Capacité Surveillane
Tolérance et monitoring
Surveillance
d’indicateurs métiers :
transactions validées,
en erreur, quantité de
commandes, ...
Une des
grandes forces
des
architectures
microservices :
sa robustesse
et sa tolérance
aux pannes
Le service est
alors capable de
fonctionner à la
fois en mode
nominal et en
mode dégradé.
Malgré cette
tolérance, le
système doit
être surveillé
en permanence

La mise en œuvre : Quels Outils ?

La mise en œuvre : Comment coder?
Plateformes logicielles
Environnement de développement

La mise en œuvre : Comment isoler?
Isoler un microservice
Utilisation de techniques de virtualisation : Trois grandes techniques s’affrontent :

Isoler un microservice :
Les outils pour isoler les microservices:
Construire des
machines
virtuelles
• Hyperviseurs : Vmware vSphere, Microsoft
HyperV, KVM, Oracle VirualBox, Vmware
Player,..
Construire des
conteneurs
• Conteneurs : Docker, CoreOS Rocket, LXC,… Docker : Le plus tendance
Plus simple à mettre en œuvre
Dispose d’un dépôt central fournissant
des images prêtes à l’emploi
Logiciel Libre

Isoler un microservice :
Les outils pour isoler les microservices :
Comparatif sur les performances

La mise en œuvre : Quelle organisation ?

Organisation d’équipe
Une architecture microservices induit
des micro-équipes, en interaction
constante.
Chaque microservice a sa propre équipe
de développement
L’équipe de développement orientée
fonctionnalité est réduite et
pluridisciplinaire
Il est important de garder un contrôle et
une vision d’ensemble, grâce, par
exemple, à une cartographie de son SI.

Les limites

Taille des services
Il est important de trouver un juste milieux entre des services imposants et des services trop petits
Ceci va regrouper la complexité des services en
un seul qui va devenir plus difficilement
maintenable.
La communication de ces nombreux services
sera plus complexe
Regrouper plusieurs “petits” services en un seul « macroservice »
Tenter le « nanoservice » en transformant chaque méthode d’une application
monolithique en microservice
Taille des services : En
terme de code,
de nombre de fonctions, …
Le plus grand principe des microservices concerne la taille de ces services.
Pièges à éviter :

Profusion des technologies
Veiller à ne pas
multiplier les langages
inutilement
Eviter de multiplier le nombre
de bases différentes
Garder un type de base relationnelle et un
type de base NoSQL peut être un bon
compromis

Conclusion

Conclusion
Les architectures orientées services ont piloté la mise en place des SI de ces 10 dernières années.
Solution proposée
par les
microservices :
• Diminuer
l’échelle de
l’architecture
Isolation nécessaire
des fonctionnalités
à différents niveaux
• Code
• Données
• Déploiement
Nécessité d’un certain
investissement
• Technologique
• Méthodologique
(DevOps,
Craftmanship,..°
• Organisationnel
(Agilité, Feature
team)
Les microservices
ne constituent pas
une recette
universelle :
• Exp :Système
peu complexe
dont le rythme
d’évolution est
faible
Les microservices
ne garantissent
pas une
simplification du
système global
mais permettent la
simplification de
son évolution

MERCI

www.capgemini.com
The information contained in this presentation is proprietary.
© 2017 Capgemini. All rights reserved. Rightshore® is a trademark belonging to Capgemini.
A propos de Capgemini
Avec plus de 190 000 collaborateurs, Capgemini est présent dans
plus de 40 pays et célèbre son cinquantième anniversaire en
2017. Le Groupe est l'un des leaders mondiaux du conseil, des
services informatiques et de l'infogérance et a réalisé en 2016 un
chiffre d'affaires de 12,5 milliards d'euros. Avec ses clients,
Capgemini conçoit et met en œuvre les solutions business,
technologiques et digitales qui correspondent à leurs besoins et
leur apportent innovation et compétitivité. Profondément
multiculturel, Capgemini revendique un style de travail qui lui est
propre, la « Collaborative Business ExperienceTM », et s’appuie
sur un mode de production mondialisé, le « Rightshore® ».
Plus d’informations sur : www.capgemini.com
Rightshore® est une marque du groupe Capgemini

CWIN17 Morocco / Microservices architecture ghofrane benaziz

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à CWIN17 Morocco / Microservices architecture ghofrane benaziz

Similaire à CWIN17 Morocco / Microservices architecture ghofrane benaziz (20)

Plus de Capgemini

Plus de Capgemini (20)

CWIN17 Morocco / Microservices architecture ghofrane benaziz

Notes de l'éditeur