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.

1. Microservices
Présentation des concepts
Bertrand Lehurt
Octobre 2015

2. SOAT en quelques chiffres

3. L’expertise SOAT

4. /me
Bertrand Lehurt
Consultant Java
Formateur
Lodennan
Linkedin.com/in/bertrandlehurt

5. Sommaire
o Architecture monolithique
o Que sont les microservices?
o Intégration
o Découper une application
monolithique

6. Sommaire
o Déploiement
o Monitoring
o La mise à l’échelle (scaling)
o Loi de Conway

7. Ce qu’on ne verra pas
o Présentation de code
o Mise en place d’outils
o Déploiement de microservices

8. Architecture monolithique

9. Monolithes
Applications classiques que vous connaissez tous
DAO
Services
MVC
Tomcat

10. Monolithes
MonolitheRéseaux Réseaux
Load
balancer
Base de
données

11. Applications monolithiques
Avantages
o Simplicité de mise en place
o Une seule codebase
o Efficience à petite échelle
o Latence applicative

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. 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. Base de données monolithiques
Inconvénients
o Couplage
o Mauvais scaling et redondance
o Difficulté à tuner correctement
o Management du schéma

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. Les microservices ont émergés grâce à tous
ces concepts et techniques

17. Microservices

18. Microservices
Pas de définition mais un ensemble de
caractéristiques

19. Caractéristiques
Petit et focalisé sur une et une seule
responsabilité

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. 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. 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. Caractéristiques
Gouvernance décentralisée
Management de donnée décentralisée
Automatisation de l’infrastructure
Design For Failure

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. Récapitulatif
Monolithe : organisation au niveau technique
• UI
• Serveur
• Base de données
Microservices : organisation au niveau métier
• Livraison
• Catalogue produits
• Achat

26. Le retour de la vengeance de SOA ?

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. ESB
Service
Service
ServiceESB
Problème des ESB
Spaghetti box

29. Point de vue de Martin Fowler
SOA
Microservices

31. Intégration

32. 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

33. Bonnes pratiques
Garder votre service le plus simple possible
pour les clients qui vont le consommer

34. 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

35. 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

36. 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)

37. 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

38. 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

39. Richardson Maturiry Model
Level 0 : The Swamp of POX
Level 1 : Ressources
Level 2 : HTTP verbs
Level 3 : Hypermedia
GLORY OF REST

40. Communication : Asynchrone
Event-Based communication :
o Publication d’événement
o Abonnement à la réception d’événement
Outil : RabbitMQ

41. Versionning
Utiliser SemVer (Semantic Version)
Numéro de version :
MAJEUR.MINEUR.CORRECTIF

42. Découper un monolithe

43. Monolith First
Source : http://martinfowler.com/bliki/MonolithFirst.html

44. 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)

45. Domain Driven Design
Utiliser les bounded context (Contexte
borné)
-> Regroupement en bloc fonctionnel

46. 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

47. Découper un monolithe
Penser à faire un découpage par itération
Eviter un découpage trop fin, trop orienté
sur la technique

48. Déploiement

49. 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

50. 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

51. Continuous delivery
Compilé, testé, livré à l’environnement
suivant (test, qualification, Mise en
production…)
-> Créer des pipelines

52. Continuous deployment
Compilé, testé et déployé en production

53. Immutable server
Lutter contre le Configuration Drift en
rendant vos serveurs et leurs configurations
immutables

54. Déploiement
o Machines physiques
o VM
o Conteneur Linux
o Docker

55. Monitoring

56. Logs
User service
Index service
Product service
Logs
Logs
Logs

57. Logs : parsing & indexation
User service
Index service
Product service
Logs
Logs
Logs
Logstash
Logstash
Logstash
Kibana

58. Correlation ID
Web Frontend
Registration
service
Email
service
Payment
service
User
service
Correlation ID : aef972
ID : aef972ID : aef972ID : aef972

59. 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

60. Métriques
Utilisation d’outils :
o Dropwizard Metrics
pour la mesure
o Graphite pour la
visualisation

61. La mise à l’échelle (scaling)

62. Mise à l’échelle
Source : http://martinfowler.com/articles/microservices.html

63. Release it
Release it de Michael Nygard
Analyse post mortem de crash
de système d’information issu
de problème en cascade

64. Circuit breaker
Mettre en place le pattern Circuit Breaker
Outils comme Netflix Hystrix

65. Loi de Conway

66. 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)

67. 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.

68. Avantages & inconvénients

69. 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

70. Inconvénients des microservices
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice

71. Auxquels on ajoute les
communications
réseaux

72. Microservice
Microservice
Microservice
Microservice
Microservice
Réseau
Réseau
Réseau
Réseau
Réseau

73. Auxquels on ajoute les
loadbalancers

74. 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

75. Vous devez aussi avoir
des bases de données

76. 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

77. 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 …

78. Avec les microservices, vous devez :
Au minimum :
o Déploiement et provisioning rapide des
applications
o Effectuer un monitoring
o Culture devops

79. 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

80. Anti patterns

81. Le Mega service
o Trop de responsabilités différentes rend le
changement difficile
o Beaucoup trop de dépendances

82. Le partage de persistance
o Casse l’encapsulation
o Encourage les interface « backdoor »
o Couplage invisible

83. Chez Google

84. Communications standardisées
o Protocol réseau : GRPC
o Format de données
o Spécification des interfaces

85. Infrastructure standardisée
o Source control
o Management de la configuration
o Management des clusters
o Monitoring, alertes, diagnostiques…

86. Indépendances des services
Pas de standardisation au niveau des
services
o Langage de programmation
o Framework
o Persistance

87. Chez Netflix

88. Antifragile Organization
Antifragile de Nassim Nicholas Taleb
A l’image de ce que fait Netflix
Chaos Monkey

89. Netflix library
Netflix a publié plusieurs bibliothèques open
source dont :
o Eureka
o Hystrix

90. Conseils

91. Conseils
Les microservices apportent un ensemble
d’avantages :
o organisationnels
o techniques
o delivery

92. Conseils
Cependant, attention à la complexité et au
niveau de maturité de vos équipes

93. 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

94. Merci

96. Sources

97. 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

98. Sources
ohttp://www.typesafe.com/blog/microservices-101-
exploiting-realitys-constraints-with-technology
ohttp://martinfowler.com/bliki/CircuitBreaker.html