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

30.
Intégration

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.
Bonnes pratiques
Garder votre service le plus simple possible
pour les clients qui vont le consommer

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.
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.
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.
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.
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.
Richardson Maturiry Model
Level 0 : The Swamp of POX
Level 1 : Ressources
Level 2 : HTTP verbs
Level 3 : Hypermedia
GLORY OF REST

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

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

41.
Découper un monolithe

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

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.
Domain Driven Design
Utiliser les bounded context (Contexte
borné)
-> Regroupement en bloc fonctionnel

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.
Découper un monolithe
Penser à faire un découpage par itération
Eviter un découpage trop fin, trop orienté
sur la technique

47.
Déploiement

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.
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.
Continuous delivery
Compilé, testé, livré à l’environnement
suivant (test, qualification, Mise en
production…)
-> Créer des pipelines

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

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

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

54.
Monitoring

55.
Logs
User service
Index service
Product service
Logs
Logs
Logs

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

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

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.
Métriques
Utilisation d’outils :
o Dropwizard Metrics
pour la mesure
o Graphite pour la
visualisation

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

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

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.
Circuit breaker
Mettre en place le pattern Circuit Breaker
Outils comme Netflix Hystrix

64.
Loi de Conway

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.
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.
Avantages & inconvénients

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.
Inconvénients des microservices
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice

70.
Auxquels on ajoute les
communications
réseaux

71.
Microservice
Microservice
Microservice
Microservice
Microservice
Réseau
Réseau
Réseau
Réseau
Réseau

72.
Auxquels on ajoute les
loadbalancers

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.
Vous devez aussi avoir
des bases de données

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.
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.
Avec les microservices, vous devez :
Au minimum :
o Déploiement et provisioning rapide des
applications
o Effectuer un monitoring
o Culture devops

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.
Anti patterns

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

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

82.
Chez Google

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

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

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

86.
Chez Netflix

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

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

89.
Conseils

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

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

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

94.
Sources

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.
Sources
ohttp://www.typesafe.com/blog/microservices-101-
exploiting-realitys-constraints-with-technology
ohttp://martinfowler.com/bliki/CircuitBreaker.html