Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

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

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 99 Publicité

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

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.

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.

Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (18)

Les utilisateurs ont également aimé (20)

Publicité

Similaire à ARCHITECTURE MICROSERVICE : TOUR D’HORIZON DU CONCEPT ET BONNES PRATIQUES (20)

Plus par SOAT (20)

Publicité

Plus récents (20)

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

Notes de l'éditeur

  • 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

×