Microservices
Présentation des concepts
Bertrand Lehurt
Octobre 2015
SOAT en quelques chiffres
L’expertise SOAT
/me
Bertrand Lehurt
Consultant Java
Formateur
Lodennan
Linkedin.com/in/bertrandlehurt
Sommaire
o Architecture monolithique
o Que sont les microservices?
o Intégration
o Découper une application
monolithique
Sommaire
o Déploiement
o Monitoring
o La mise à l’échelle (scaling)
o Loi de Conway
Ce qu’on ne verra pas
o Présentation de code
o Mise en place d’outils
o Déploiement de microservices
Architecture monolithique
Monolithes
Applications classiques que vous connaissez tous
DAO
Services
MVC
Tomcat
Monolithes
MonolitheRéseaux Réseaux
Load
balancer
Base de
données
Applications monolithiques
Avantages
o Simplicité de mise en place
o Une seule codebase
o Efficience à petite échelle
o La...
Base de données monolithiques
Avantages
o Simplicité de mise en place
o Requête et jointure facilitées
o Un seul schéma, u...
Applications monolithiques
Inconvénients
o Mauvaise application de la modularité
o Temps de build long
o Déploiement de to...
Base de données monolithiques
Inconvénients
o Couplage
o Mauvais scaling et redondance
o Difficulté à tuner correctement
o...
Evolution de notre industrie
o Domain-Driven Design
o Intégration continue
o Virtualisation à la demande
o Automatisation ...
Les microservices ont émergés grâce à tous
ces concepts et techniques
Microservices
Microservices
Pas de définition mais un ensemble de
caractéristiques
Caractéristiques
Petit et focalisé sur une et une seule
responsabilité
Single Responsability Principle
Robert C. Martin :
Gather together those things
that change for the same
reason, and separ...
Single Responsability Principle
Fait parti des 5 principes SOLID :
o S : Single responsibility principle
o O : Open/closed...
Caractéristiques
Application autonome
Organisé autour des capacités métier
Produit et non plus projet
Endpoints évolués et...
Caractéristiques
Gouvernance décentralisée
Management de donnée décentralisée
Automatisation de l’infrastructure
Design Fo...
Caractéristiques
Les microservices doivent pouvoir être :
o remplacés de manière indépendante
o mis à jour de manière indé...
Récapitulatif
Monolithe : organisation au niveau technique
• UI
• Serveur
• Base de données
Microservices : organisation a...
Le retour de la vengeance de SOA ?
SOA?
Contrairement à une solution basée sur un
ESB, les échanges se font :
o sur des canaux de communication pauvres
o san...
ESB
Service
Service
ServiceESB
Problème des ESB
Spaghetti box
Point de vue de Martin Fowler
SOA
Microservices
Intégration
Bonnes pratiques
Garder votre API « technology-agnostic »
Le marché évolue rapidement, les communications
entre vos servic...
Bonnes pratiques
Garder votre service le plus simple possible
pour les clients qui vont le consommer
Bonnes pratiques
Cacher les détails de l’implémentation
Vous ne devez pas créer de couplage entre vos
implémentations et l...
Communication : RPC
Remote Procedure Calls
N’est pas recommandé car abstrait l’appel distant
Attention à l’utilisation de ...
Communication : REST
o REST est un style d’architecture distribuée,
créé par Roy Felding en 2000
o Ce n’est pas un protoco...
Communication : REST
Avantages
o Beaucoup de plateformes et de langages
supportent HTTP
o Beaucoup de clients possibles (c...
Maturité des API
o Le modèle de maturité de Richardson permet
d’évaluer le niveau de maturité de votre API
o Il possède 4 ...
Richardson Maturiry Model
Level 0 : The Swamp of POX
Level 1 : Ressources
Level 2 : HTTP verbs
Level 3 : Hypermedia
GLORY ...
Communication : Asynchrone
Event-Based communication :
o Publication d’événement
o Abonnement à la réception d’événement
O...
Versionning
Utiliser SemVer (Semantic Version)
Numéro de version :
MAJEUR.MINEUR.CORRECTIF
Découper un monolithe
Monolith First
Source : http://martinfowler.com/bliki/MonolithFirst.html
Etape par étape
Définir les raisons qui vous poussent à
découper votre application
o une partie de votre appli va opérer d...
Domain Driven Design
Utiliser les bounded context (Contexte
borné)
-> Regroupement en bloc fonctionnel
Seams
Dans son livre, Michael Feathers
définit le concept de Seams :
Morceau de code pouvant être isolé et sur
lequel on p...
Découper un monolithe
Penser à faire un découpage par itération
Eviter un découpage trop fin, trop orienté
sur la technique
Déploiement
Continuous integration
Repository
User service
Build-0.1
Index service
Buid-0.1
Payment service
Build-0.1
Build de votre
a...
Continuous integration
User service
Repository
User service
Build-0.1
Index service
Buid-0.1
Payment service
Build-0.1
Use...
Continuous delivery
Compilé, testé, livré à l’environnement
suivant (test, qualification, Mise en
production…)
-> Créer de...
Continuous deployment
Compilé, testé et déployé en production
Immutable server
Lutter contre le Configuration Drift en
rendant vos serveurs et leurs configurations
immutables
Déploiement
o Machines physiques
o VM
o Conteneur Linux
o Docker
Monitoring
Logs
User service
Index service
Product service
Logs
Logs
Logs
Logs : parsing & indexation
User service
Index service
Product service
Logs
Logs
Logs
Logstash
Logstash
Logstash
Kibana
Correlation ID
Web Frontend
Registration
service
Email
service
Payment
service
User
service
Correlation ID : aef972
ID : a...
Correlation ID
2015-10-22 19:30:01 Web frontend INFO [aef872] Register
2015-10-22 19:30:02 Register service INFO [aef872] ...
Métriques
Utilisation d’outils :
o Dropwizard Metrics
pour la mesure
o Graphite pour la
visualisation
La mise à l’échelle (scaling)
Mise à l’échelle
Source : http://martinfowler.com/articles/microservices.html
Release it
Release it de Michael Nygard
Analyse post mortem de crash
de système d’information issu
de problème en cascade
Circuit breaker
Mettre en place le pattern Circuit Breaker
Outils comme Netflix Hystrix
Loi de Conway
Loi de Conway
Any organizations that design systems [...] will
inevitably produce a design whose structure is
a copy of th...
Manœuvre de Conway inversée
The 'Inverse Conway Maneuver'
recommends evolving your team and
organizational structure to pr...
Avantages & inconvénients
Bénéfices des microservices
Architecture adaptée aux besoins métier
Résilience
Scalabilité
Facilité de déploiement
Petites...
Inconvénients des microservices
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Auxquels on ajoute les
communications
réseaux
Microservice
Microservice
Microservice
Microservice
Microservice
Réseau
Réseau
Réseau
Réseau
Réseau
Auxquels on ajoute les
loadbalancers
Microservice
Microservice
Microservice
Réseau
Réseau
Réseau
Réseau
Réseau
Microservice
Microservice
Load
balancer Load
bal...
Vous devez aussi avoir
des bases de données
Microservice
Microservice
Microservice
Réseau
Réseau
Réseau
Réseau
Réseau
Microservice
Microservice
Load
balancer Load
bal...
Inconvénients
o On augmente ici le nombre d’éléments à
surveiller et optimiser
o Augmentation du trafic réseau
o Le coût d...
Avec les microservices, vous devez :
Au minimum :
o Déploiement et provisioning rapide des
applications
o Effectuer un mon...
Avec les microservices, vous devez :
o Log efficace des transactions métiers
o Continuous delivery
o Equipe centrée sur le...
Anti patterns
Le Mega service
o Trop de responsabilités différentes rend le
changement difficile
o Beaucoup trop de dépendances
Le partage de persistance
o Casse l’encapsulation
o Encourage les interface « backdoor »
o Couplage invisible
Chez Google
Communications standardisées
o Protocol réseau : GRPC
o Format de données
o Spécification des interfaces
Infrastructure standardisée
o Source control
o Management de la configuration
o Management des clusters
o Monitoring, aler...
Indépendances des services
Pas de standardisation au niveau des
services
o Langage de programmation
o Framework
o Persista...
Chez Netflix
Antifragile Organization
Antifragile de Nassim Nicholas Taleb
A l’image de ce que fait Netflix
Chaos Monkey
Netflix library
Netflix a publié plusieurs bibliothèques open
source dont :
o Eureka
o Hystrix
Conseils
Conseils
Les microservices apportent un ensemble
d’avantages :
o organisationnels
o techniques
o delivery
Conseils
Cependant, attention à la complexité et au
niveau de maturité de vos équipes
Conseils
Commencer par un ou deux microservices,
pour dimensionner le risque, gérer le
périmètre de travail, faire monter ...
Merci
Sources
Sources
ohttp://martinfowler.com/microservices
ohttp://martinfowler.com/articles/microservices.html
ohttps://www.nginx.com...
Sources
ohttp://www.typesafe.com/blog/microservices-101-
exploiting-realitys-constraints-with-technology
ohttp://martinfow...
ARCHITECTURE MICROSERVICE : TOUR D’HORIZON DU CONCEPT ET BONNES PRATIQUES
ARCHITECTURE MICROSERVICE : TOUR D’HORIZON DU CONCEPT ET BONNES PRATIQUES
ARCHITECTURE MICROSERVICE : TOUR D’HORIZON DU CONCEPT ET BONNES PRATIQUES
Prochain SlideShare
Chargement dans…5
×

ARCHITECTURE MICROSERVICE : TOUR D’HORIZON DU CONCEPT ET BONNES PRATIQUES

1 967 vues

Publié le

Les systèmes distribués ont largement évolués ces 10 dernières années, passant d’énormes applications monolithiques à de petits containers de services, apportant plus de souplesse et d’agilité au sein des systèmes d’information.

Le terme « Architecture microservice » a vu le jour pour décrire cette manière particulière de concevoir des applications logicielles.

Bien qu’il n’y ait pas de définition précise de ce style d’architecture, elles ont un certain nombre de caractéristiques communes basées autour de l’organisation de l’entreprise, du déploiement automatisé et de la décentralisation du contrôle du langage et des données.

Seulement, développer ces systèmes peut tourner au véritable casse-tête. Je vous propose donc un tour des concepts et différentes caractéristiques de ce type d’architecture, des bonnes et mauvaises pratiques, de la création jusqu’au déploiement des applications.

Publié dans : Technologie
1 commentaire
14 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
1 967
Sur SlideShare
0
Issues des intégrations
0
Intégrations
25
Actions
Partages
0
Téléchargements
0
Commentaires
1
J’aime
14
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Domain-Drive design d’Eric Evan a aidé à comprendre l’importance de la représentation du monde réel dans notre code
  • Rassemblez ces choses qui changent pour la même raison, et de séparer ces choses qui changent pour des raisons différentes.

    Ce qui veut dire qu’un système, une classe ou une fonction ne devrait pas avoir plus d’une seule raison pour changer
  • Hypermedia : les réponses REST contiennent des liens qui permettent de comprendre comment utiliser la ressource
  • Plus de transaction, on va s’orienter vers une approche event sourcing
  • Lorsque quelqu’un modifie le code ou la configuration en production sans changer le code dans votre système de versionning, c’est ce qu’on appelle « Configuration drift »
  • Pas de SSH sur chaque machine
  • Tout logiciel reflète l'organisation qui l'a créée
  • ARCHITECTURE MICROSERVICE : TOUR D’HORIZON DU CONCEPT ET BONNES PRATIQUES

    1. 1. Microservices Présentation des concepts Bertrand Lehurt Octobre 2015
    2. 2. SOAT en quelques chiffres
    3. 3. L’expertise SOAT
    4. 4. /me Bertrand Lehurt Consultant Java Formateur Lodennan Linkedin.com/in/bertrandlehurt
    5. 5. Sommaire o Architecture monolithique o Que sont les microservices? o Intégration o Découper une application monolithique
    6. 6. Sommaire o Déploiement o Monitoring o La mise à l’échelle (scaling) o Loi de Conway
    7. 7. Ce qu’on ne verra pas o Présentation de code o Mise en place d’outils o Déploiement de microservices
    8. 8. Architecture monolithique
    9. 9. Monolithes Applications classiques que vous connaissez tous DAO Services MVC Tomcat
    10. 10. Monolithes MonolitheRéseaux Réseaux Load balancer Base de données
    11. 11. Applications monolithiques Avantages o Simplicité de mise en place o Une seule codebase o Efficience à petite échelle o Latence applicative
    12. 12. Base de données monolithiques Avantages o Simplicité de mise en place o Requête et jointure facilitées o Un seul schéma, un seul déploiement o Efficience à petite échelle
    13. 13. Applications monolithiques Inconvénients o Mauvaise application de la modularité o Temps de build long o Déploiement de toute l’application (downtime, failure) o Mauvaise mise à l’échelle (vertical scaling)
    14. 14. Base de données monolithiques Inconvénients o Couplage o Mauvais scaling et redondance o Difficulté à tuner correctement o Management du schéma
    15. 15. Evolution de notre industrie o Domain-Driven Design o Intégration continue o Virtualisation à la demande o Automatisation des infrastructures o Equipes de développement autonomes o Mise à l’échelle des systèmes (scaling)
    16. 16. Les microservices ont émergés grâce à tous ces concepts et techniques
    17. 17. Microservices
    18. 18. Microservices Pas de définition mais un ensemble de caractéristiques
    19. 19. Caractéristiques Petit et focalisé sur une et une seule responsabilité
    20. 20. Single Responsability Principle Robert C. Martin : Gather together those things that change for the same reason, and separate those things that change for different reasons.
    21. 21. Single Responsability Principle Fait parti des 5 principes SOLID : o S : Single responsibility principle o O : Open/closed principle o L : Liskov substitution principle o I : Interface segregation principle o D : Dependency inversion principle
    22. 22. Caractéristiques Application autonome Organisé autour des capacités métier Produit et non plus projet Endpoints évolués et canaux de communication pauvres
    23. 23. Caractéristiques Gouvernance décentralisée Management de donnée décentralisée Automatisation de l’infrastructure Design For Failure
    24. 24. Caractéristiques Les microservices doivent pouvoir être : o remplacés de manière indépendante o mis à jour de manière indépendante
    25. 25. Récapitulatif Monolithe : organisation au niveau technique • UI • Serveur • Base de données Microservices : organisation au niveau métier • Livraison • Catalogue produits • Achat
    26. 26. Le retour de la vengeance de SOA ?
    27. 27. SOA? Contrairement à une solution basée sur un ESB, les échanges se font : o sur des canaux de communication pauvres o sans médiation o sans transformation
    28. 28. ESB Service Service ServiceESB Problème des ESB Spaghetti box
    29. 29. Point de vue de Martin Fowler SOA Microservices
    30. 30. Intégration
    31. 31. Bonnes pratiques Garder votre API « technology-agnostic » Le marché évolue rapidement, les communications entre vos services ne doivent pas être dictées par une stack technologique
    32. 32. Bonnes pratiques Garder votre service le plus simple possible pour les clients qui vont le consommer
    33. 33. Bonnes pratiques Cacher les détails de l’implémentation Vous ne devez pas créer de couplage entre vos implémentations et les clients de votre service
    34. 34. Communication : RPC Remote Procedure Calls N’est pas recommandé car abstrait l’appel distant Attention à l’utilisation de technologies comme Java RMI qui sont liées à la plateforme. Utiliser Thrift ou Protocol buffer qui possède un grand nombre de support pour les langages
    35. 35. Communication : REST o REST est un style d’architecture distribuée, créé par Roy Felding en 2000 o Ce n’est pas un protocole, un format ou un standard o REST prône une approche sans état (Stateless) o Basé sur les méthodes HTTP (GET, POST, DELETE, PUT)
    36. 36. Communication : REST Avantages o Beaucoup de plateformes et de langages supportent HTTP o Beaucoup de clients possibles (curl, navigateur, applications…) o Dispose des avantages d’HTTP (redirection, cache) o Supporte plusieurs formats : XML, JSON, Atom
    37. 37. Maturité des API o Le modèle de maturité de Richardson permet d’évaluer le niveau de maturité de votre API o Il possède 4 niveaux  Niveau 0 : Une seule URI (SOAP, XML, RPC)  Niveau 1 : Plusieurs URI, une seul verbe  Niveau 2 : Plusieurs URI, plusieurs verbes (CRUD)  Niveau 3 : Hypermedia
    38. 38. Richardson Maturiry Model Level 0 : The Swamp of POX Level 1 : Ressources Level 2 : HTTP verbs Level 3 : Hypermedia GLORY OF REST
    39. 39. Communication : Asynchrone Event-Based communication : o Publication d’événement o Abonnement à la réception d’événement Outil : RabbitMQ
    40. 40. Versionning Utiliser SemVer (Semantic Version) Numéro de version : MAJEUR.MINEUR.CORRECTIF
    41. 41. Découper un monolithe
    42. 42. Monolith First Source : http://martinfowler.com/bliki/MonolithFirst.html
    43. 43. Etape par étape Définir les raisons qui vous poussent à découper votre application o une partie de votre appli va opérer de gros changements o la structure de votre équipe (multi-office) o sécurité (protection de données sensibles) o technologie (paradigme lié à un langage)
    44. 44. Domain Driven Design Utiliser les bounded context (Contexte borné) -> Regroupement en bloc fonctionnel
    45. 45. Seams Dans son livre, Michael Feathers définit le concept de Seams : Morceau de code pouvant être isolé et sur lequel on peut travailler sans impact sur le reste de la codebase Le but est donc d’identifier les seams qui pourraient définir vos services
    46. 46. Découper un monolithe Penser à faire un découpage par itération Eviter un découpage trop fin, trop orienté sur la technique
    47. 47. Déploiement
    48. 48. Continuous integration Repository User service Build-0.1 Index service Buid-0.1 Payment service Build-0.1 Build de votre application monolithique Chaque changement dans le code entraine un build Serveur d’intégration continue Chacun des builds produisent 3 artifacts
    49. 49. Continuous integration User service Repository User service Build-0.1 Index service Buid-0.1 Payment service Build-0.1 User service build Serveur d’intégration continue Chacun des builds produisent 3 artifacts Payment service build Index service build Payment service Repository Index service Repository
    50. 50. Continuous delivery Compilé, testé, livré à l’environnement suivant (test, qualification, Mise en production…) -> Créer des pipelines
    51. 51. Continuous deployment Compilé, testé et déployé en production
    52. 52. Immutable server Lutter contre le Configuration Drift en rendant vos serveurs et leurs configurations immutables
    53. 53. Déploiement o Machines physiques o VM o Conteneur Linux o Docker
    54. 54. Monitoring
    55. 55. Logs User service Index service Product service Logs Logs Logs
    56. 56. Logs : parsing & indexation User service Index service Product service Logs Logs Logs Logstash Logstash Logstash Kibana
    57. 57. Correlation ID Web Frontend Registration service Email service Payment service User service Correlation ID : aef972 ID : aef972ID : aef972ID : aef972
    58. 58. Correlation ID 2015-10-22 19:30:01 Web frontend INFO [aef872] Register 2015-10-22 19:30:02 Register service INFO [aef872] RegisterUser 2015-10-22 19:30:03 User service INFO [aef872] GetTimeline 2015-10-22 19:30:04 Payment service INFO [aef872] ValidatePayment 2015-10-22 19:30:05 Email service INFO [aef872] SendEmail
    59. 59. Métriques Utilisation d’outils : o Dropwizard Metrics pour la mesure o Graphite pour la visualisation
    60. 60. La mise à l’échelle (scaling)
    61. 61. Mise à l’échelle Source : http://martinfowler.com/articles/microservices.html
    62. 62. Release it Release it de Michael Nygard Analyse post mortem de crash de système d’information issu de problème en cascade
    63. 63. Circuit breaker Mettre en place le pattern Circuit Breaker Outils comme Netflix Hystrix
    64. 64. Loi de Conway
    65. 65. Loi de Conway Any organizations that design systems [...] will inevitably produce a design whose structure is a copy of the organization ’s communication structure Melvin Conway – How Do Committes Invent (1968)
    66. 66. Manœuvre de Conway inversée The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture. Ideally your technology architecture will display isomorphism with your business architecture.
    67. 67. Avantages & inconvénients
    68. 68. Bénéfices des microservices Architecture adaptée aux besoins métier Résilience Scalabilité Facilité de déploiement Petites équipes concentrées sur leurs services Evolution car facilité de remplacement
    69. 69. Inconvénients des microservices Microservice Microservice Microservice Microservice Microservice Microservice
    70. 70. Auxquels on ajoute les communications réseaux
    71. 71. Microservice Microservice Microservice Microservice Microservice Réseau Réseau Réseau Réseau Réseau
    72. 72. Auxquels on ajoute les loadbalancers
    73. 73. Microservice Microservice Microservice Réseau Réseau Réseau Réseau Réseau Microservice Microservice Load balancer Load balancer Load balancerLoad balancer Load balancer Réseau RéseauRéseau
    74. 74. Vous devez aussi avoir des bases de données
    75. 75. Microservice Microservice Microservice Réseau Réseau Réseau Réseau Réseau Microservice Microservice Load balancer Load balancer Load balancerLoad balancer Load balancer Réseau RéseauRéseau Base de données Base de données
    76. 76. Inconvénients o On augmente ici le nombre d’éléments à surveiller et optimiser o Augmentation du trafic réseau o Le coût de la latence augmente o Coût sérialisation/désérialisation o Dans le cas où une requête n’est pas correctement tracée sur son parcours …
    77. 77. Avec les microservices, vous devez : Au minimum : o Déploiement et provisioning rapide des applications o Effectuer un monitoring o Culture devops
    78. 78. Avec les microservices, vous devez : o Log efficace des transactions métiers o Continuous delivery o Equipe centrée sur le produit o Développeurs multi environnement
    79. 79. Anti patterns
    80. 80. Le Mega service o Trop de responsabilités différentes rend le changement difficile o Beaucoup trop de dépendances
    81. 81. Le partage de persistance o Casse l’encapsulation o Encourage les interface « backdoor » o Couplage invisible
    82. 82. Chez Google
    83. 83. Communications standardisées o Protocol réseau : GRPC o Format de données o Spécification des interfaces
    84. 84. Infrastructure standardisée o Source control o Management de la configuration o Management des clusters o Monitoring, alertes, diagnostiques…
    85. 85. Indépendances des services Pas de standardisation au niveau des services o Langage de programmation o Framework o Persistance
    86. 86. Chez Netflix
    87. 87. Antifragile Organization Antifragile de Nassim Nicholas Taleb A l’image de ce que fait Netflix Chaos Monkey
    88. 88. Netflix library Netflix a publié plusieurs bibliothèques open source dont : o Eureka o Hystrix
    89. 89. Conseils
    90. 90. Conseils Les microservices apportent un ensemble d’avantages : o organisationnels o techniques o delivery
    91. 91. Conseils Cependant, attention à la complexité et au niveau de maturité de vos équipes
    92. 92. Conseils Commencer par un ou deux microservices, pour dimensionner le risque, gérer le périmètre de travail, faire monter en compétences vos équipes et ajuster le niveau de granularité par la suite
    93. 93. Merci
    94. 94. Sources
    95. 95. Sources ohttp://martinfowler.com/microservices ohttp://martinfowler.com/articles/microservices.html ohttps://www.nginx.com/blog/introduction-to-microservices ohttp://microservices.io oSéries d’articles de Thoughworks sur le sujet : http://www.thoughtworks.com/search?q=microservice&c=si tewide
    96. 96. Sources ohttp://www.typesafe.com/blog/microservices-101- exploiting-realitys-constraints-with-technology ohttp://martinfowler.com/bliki/CircuitBreaker.html

    ×