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