More Related Content Similar to CWIN17 Morocco / Microservices architecture ghofrane benaziz (20) CWIN17 Morocco / Microservices architecture ghofrane benaziz2. 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
3. 3Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les architectures monolithiques et leurs
problèmes
4. 4Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
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..
5. 5Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les architectures monolithiques et leurs problèmes
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
6. 6Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les architectures monolithiques et leurs problèmes
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)
7. 7Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les architectures monolithiques et leurs problèmes
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.
8. 8Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Présentation de l’architecture
Microservices
9. 9Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
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.
10. 10Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les principes des microservices
11. 11Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
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 :
12. 12Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les principes des microservices
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 :
13. 13Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les principes des microservices
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
14. 14Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les principes des microservices
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
15. 15Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les principes des microservices
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
16. 16Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les principes des microservices
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.
17. 17Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les principes des microservices
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é
18. 18Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les principes des microservices
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
19. 19Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Force Capacité Surveillane
Les principes des microservices
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
20. 20Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
La mise en œuvre : Quels Outils ?
21. 21Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
La mise en œuvre : Comment coder?
Plateformes logicielles
Environnement de développement
22. 22Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
La mise en œuvre : Comment isoler?
Isoler un microservice
Utilisation de techniques de virtualisation : Trois grandes techniques s’affrontent :
23. 23Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
La mise en œuvre : Comment isoler?
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
24. 24Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
La mise en œuvre : Comment isoler?
Isoler un microservice :
Les outils pour isoler les microservices :
Comparatif sur les performances
25. 25Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
La mise en œuvre : Quelle organisation ?
26. 26Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
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.
27. 27Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
Les limites
28. 28Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
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 :
29. 29Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
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
31. 31Copyright © Capgemini 2017. All Rights Reserved.
Microservices : Nouvelle architecture logicielle
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
33. 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
Editor's Notes Scaler : Un service peu sollicité peut rester sur une instance unique tandis qu’un service devant supporter une charge importante peut multiplier ses instances d’exécutions de manière transparente.
Pas de bus d’intégration (ESB) car il y a de la logique et donc cela froce le couplage
Utilisation d’un bus d’événements pour le faible couplage
Utilisation d’un LoadBalancer pour équilibrer la charge
Pas de bus d’intégration (ESB) car il y a de la logique et donc cela froce le couplage
Utilisation d’un bus d’événements pour le faible couplage
Utilisation d’un LoadBalancer pour équilibrer la charge
- Une fois le message envoyé, le service n’attend pas de réponse immédiate.
- Si un service tombe, tous les messages qui lui sont destinés sont gardés dans le bus. Il pourra reprendre le travail une fois redémarré, sans perte.
- N’importe qui peut lire dans le bus, qu’il y ait une ou dix instances du même service ne change rien pour le bus et cela répartit la charge entre chaque instance
décrit les conteneurs comme des environnements d'exécution légers avec la plupart des composants de base d'une machine virtuelle et les services isolés d'un système d'exploitation, conçus pour rendre le packaging facile et l'exécution des services en douceur.
D’autres raisons pour lesquelles, selon Erhan, les conteneurs et Docker valent la peine d'être considérés :
Avec un conteneur portable entre différentes plates-formes, la portabilité des applications peut être réalisée en plaçant l’application ainsi que toutes ses dépendances dans ce conteneur.
Les conteneurs comprennent tout simplement l'application et ses dépendances qui avec la nature légère des conteneurs rend efficace l'utilisation des ressources.
Les conteneurs peuvent fournir des environnements utilisateurs avec un contrôle strict des besoins en ressources sans recours à la virtualisation.
La technologie de conteneurs est une nouvelle technologie émergente avec Docker comme un leader et de nombreuses grandes entreprises ont déjà signé des accords de partenariat avec Docker.
Cette technique consiste à isoler l’utilisation des ressources de type processeur, mémoire et disque par application sur une même machine.
Le déploiement est uniformisé et simplifié : il s’agit de déployer un conteneur par microservice
Les tests d’intégration deviennent plus faciles
Cette technique consiste à isoler l’utilisation des ressources de type processeur, mémoire et disque par application sur une même machine.
Le déploiement est uniformisé et simplifié : il s’agit de déployer un conteneur par microservice
Les tests d’intégration deviennent plus faciles
Regrouper plusieurs “petits” services en un seul "macroservice" afin de faciliter la communication entre celui-ci et le reste du SI.
Il est important de trouver un juste milieux entre des services imposants et des services trop petits
Même si les microservices permettent l’utilisation de différents langages et différents types de bases de données: Si on en utilise trop, cette profusion rendra le passage d’un service à un autre compliqué.