Le document traite des microservices, soulignant leur capacité à découper un système d'information en services autonomes et indépendants, favorisant ainsi l'agilité et la rapidité des réactions face aux changements. Il aborde également les défis liés à la communication entre services, la nécessité d'une intégration fluide et le choix des architectures, tout en mettant en avant l'importance de la cohérence technique et de l'autonomie des équipes. La conclusion insiste sur la stratégie à long terme pour trouver le bon niveau de granularité et sur l'importance d'une bonne gouvernance des services.

1. @gboissinot
101
10
Février
2015

2. Principes
&
Enjeux

3. EMERGENCE DES MICROSERVICES
Automa'sa'on
(build,
test,
deploy)
Consolidation d’expériences

4. MICROSERVICES
Les Microservices favorisent le découpage de
son système d’information en de petites unités
métiers indépendantes et autonomes
Technique de décomposition
«
Fine-­‐grained
architecture
»

5. APPROCHE MONOLITHIQUE
UI
1
Code
Export
Code
PromoCon
Code
ApplicaCon
1
UI
2
Code
ReporCng
Code
Search
Engine
Code
ApplicaCon
2
BD
Store
Remote
Services
BD
Search
&
ReporCng
Import
Code

6. ON APPLIQUE LE CUBE DE SCALABILITÉ

7. ARCHITECTURE MICROSERVICES
UI
1
Code
Import
/
Export/
PromoCon
Service
UI
2
Code
ReporCng
Service
Search
Engine
Service
BD
Store
Remote
Services
Data
for
ReporCng
Data
For
Search
Première approche

8. LES MICROSERVICES
Pas de définition formelle mais un
ensemble de caractéristiques
Focalisé minutieusement sur une et une seule
responsabilité
Possédant un contexte d’exécution séparé
(propre machine, propre processus, propre container, etc)
Communique à travers une interface uniforme
Capable d’être déployé indépendamment et de manière
automatisée
Utilise un système d’inscription et de désinscription du
réseau de Microservices

9. ORIENTÉ « CAPACITÉ MÉTIER »
«
Gather
together
those
things
that
change
for
the
same
reason,
and
separate
those
things
that
change
for
different
reasons
»
Chaque service est
une application métier autonome
Extension du pattern Single Responsability
Pattern (SPR) au système d’information

10. La liberté des Microservices permet de réagir et de
prendre des décisions plus rapidement
à des changements inévitables
(fonctionnels, techniques, organisationnels, etc)
AU SERVICE
D’UNE ARCHITECTURE AGILE
Réduit le coût du changement
Responsive
Elas'c
Resilient
Message
-­‐driven
Reac've
Manifesto
Pa?ern

11. FLEXIBILITÉ TECHNOLOGIQUE
Service
1
«
Python
»
Document
Database
Service
2
Clojure
Graph
Database
Service
3
Java
SQL
Database
Attention: Trouver le bon compromis entre
l’autonomie des équipes (avec la flexibilité du
choix) et le besoin de standardisation
Absorption des nouveaux
besoins

12. FAVORISE LA MIGRATION VERS DES
ORGANISATIONS AGILES
Service
1
C++
Service
2
Python
Service
3
Java
On crée des équipes pluridisciplinaires co-
localisées orientées « Feature Métier »
Build
&
Run
Build
&
Run
Build
&
Run
Autonomie et performance des équipes

13. COMPOSITION

14. COMPOSITION

15. FLEXIBILITÉ DE
REMPLACEMENT
New
Service
Les architectures Microservices accélèrent
l’innovation
On diminue la résistance au « refactoring »

16. Implication des Ops dans le métier
Adapté aux nouvelles organisations
Client / Fournisseur
(Cloud, Infrastructure 2.0)
DES BÉNÉFICES OPÉRATIONNELS
Au service d’une infrastructure agile

17. LA SCALABILITÉ EN ACTION

18. Application de
la loi de Conway
DES BÉNÉFICES ORGANISATIONNELS

19. MicroServices
« Collaboration »

20. UNE INTERFACE DE COMMUNICATION
SOUS FORME DE CONTRAT D’API
IMPL
PUBLIC
API
Service
Une
bonne
API
• AgnosCque
à
un
langage
• Porte
la
logique
d’intégraCon
Votre API est votre contrat en regroupant
l’ensemble des opérations exportables pour vos
consommateurs.
Elle doit évoluer indépendamment de votre code
Un contrat dirigé par les attentes des
consommateurs

21. « ZONING DU SI»
?
De
nombreux
protocoles
et
API
d’intégraCon:
RMI
JAX-­‐RPC
JAX-­‐WS
JMS
SOAP/HTTP
REST/HTTP
AMQ
etc
Trouver
la
communicaCon
la
plus
simple
possible!

22. ON ÉVITE DE COLLABORER
PAR LA DONNÉE
Dans le cas d’une base de données mutualisée,
l’évolution des services suit l’évolution du
schéma de base, les services sont fortement
couplés.
Shared
Database

23. MAIS POUR LE PARTAGE DE
DONNÉES STATIQUES?
T_CODE_PAYS

24. DES SOLUTIONS À LA
GESTION DES DONNÉES
STATIQUES
Duplication de l’information (de la donnée)
dans chaque service
Gestion de la donnée à travers du code
ou du paramétrage (fichier de conf, etc)
Encapsulation dans un service dédié

25. ON ÉVITE DE COLLABORER À
TRAVERS UN BUS D’INTÉGRATION
Complex
IntegraCon
System
(Encapsulate
Logic)
Un bus d’intégration avec de la logique
(routage, transformation, etc) fournit de
l’intelligence dans la communication
ce qui introduit une forme de couplage

26. ANALOGIE « TINKER TOY »
Des « endpoints » intelligents et des
communications simples

27. COLLABORATION
DES SERVICES ENTRE EUX
Trouver un modèle de collaboration
standard et efficace
API
A
API
B
Protocole
A
Technologie
A
Format
de
données
A
Protocole
B
Technologie
B
Format
de
données
B
L’intégration doit être simple et favoriser
le faible couplage des services
Synchrone
ou
Asynchrone
Pas
d’intelligence

28. STYLES DE COLLABORATION
1) Request / Response (synchrone ou asynchrone)
2) Event Based (asynchrone)
Service
1
Service
1
Service
2
Service
2
Event
subscribes
publishes

29. LE REMOTING, STYLE INTRUSIF
Conçu pour cacher les appels distants
Diminue l’interdépendance des services en
raison du partage d’un contrat
Fragile car on doit livrer un nouveau contrat à
chaque changement
La fiabilité du réseau et le coût du marshalling
sont à prendre en compte
Une promesse de transparence
difficile à tenir

30. LE MESSAGING A LA
RESCOUSSE
On connaît les fonctionnalités mais on abstrait
la localisation des services
La sémantique des messages pilotent le
traitement des opérations
Des clients tolérants aux changements
Découplé temporellement & Physiquement

31. L’EXISTENCE DE REST
« Identifiable Resources »
« Uniform interface »
« Stateless conversation »
« Resource representations »
« Hypermedia (HATEOS) »
Un style d’architecture respectant
un ensemble de contraintes

32. « REST OVER HTTP »
Exploitation des méthodes HTTP
(GET, POST, PUT, DELETE, HEAD, PATCH, OPTIONS)
Facile à consommer avec tous les langages
Plusieurs solutions pour la gestion des
versions
Dans les communications modernes, REST/HTTP
tend à remplacer les autres technologies
d’intégration comme SOAP/HTTP
Une forme de Messaging

33. « UNIFORM INTERFACE »
REST OVER HTTP
Simplification d’accès
HTTP
METHOD
Resource
names
+
Uniform
interfaces

34. HATEOAS – HYPERMEDIA AS THE
ENGINE OF APPLICATION STATE
Les réponses REST contiennent
les liens dont on a besoin
Les clients interagissent par « hypermedia »
Pas de connaissance préétablie de comment
interagir avec le serveur
Le concept de HATEOS est unique. Cela permet au
serveur d’évoluer fonctionnellement de manière
indépendante des clients
Découple le client et le serveur

35. MODÈLE DE MATURITÉ DE
RICHARDSON
La maturité de la mise en œuvre de REST

36. « EVENT-BASED COMMUNICATION »
On publie des événements
On souscrit à la réception d’événements
A chaque changement, un événement est
envoyé
Utilisation d’un bus de messages

37. « EVENT-BASED ARCHITECTURE »
Les Microservices publient des événements
en cas de changement d’état
Les autres Microservices souscrivent aux
événements publiés
• Synchronisation de la donnée répliquée
• Maintient de la consistance entre plusieurs
systèmes
L’utilisation d’événements au niveau applicatif
permet de garder la synchronisation des données
répliquées et la consistance des données entre
plusieurs systèmes
La meilleure solution

38. MicroServices
« Chez les géants
du Web »

39. DES CARACTÉRISTIQUES
COMMUNES
Compréhension du bénéfice d’avoir des équipes
autonomes gérant tout le cycle de vie des produits
(conception, implémentation, déploiement)
Création d’outils pour faciliter l’indépendance et
l’autonomie des équipes
• Amazon Web Services
• Suite d’outils Netflix (Hystrix, Eureka, etc)
Utilisation massive du PaaS (Cloud)
A

40. NETFLIX HYSTRIX
Librairie contrôlant la collaboration entre les différents
services pour offrir une grande tolérance à la latence
et à l’échec
Isole l’accès et permet d’éviter « the failure cascade »
en offrant des solutions de repli (fallback)
Au service de la
résilience globale

41. NETFLIX HYSTRIX
A

42. Microservices
Comment découper?

43. LES AUTRES TECHNIQUES
DE DÉCOMPOSITION
Shared Library
Modules
Les architectures Microservices peuvent être
combinées avec d’autres techniques de
décomposition.
Service
Service
Service
Library
Module
A
v1
Module
A
v2
Module
B

44. SHARED LIBRARY
Uniquement les librairies dynamiques évitent
d’avoir à redéployer tous le processus en cas
de changement
Ne pas hésiter à dupliquer du code à travers
plusieurs services
Essayer de se limiter à l’usage de librairies
techniques
Le principe « DRY » ne doit être respecté qu’au sein
d’un service
Technique ou fonctionnel, favorise la
réutilisabilité

45. MODULES
Erlang propose en natif
sa notion de modules
Java avec OSGI n’a pas marché
en raison de sa mauvaise intégration au
langage
En dehors de Erlang, l’implémentation des modules
ne permet pas de bénéficier de tous les avantages
des Microservices
On favorise le partage de code

46. S’APPUYER SUR LES
BOUNDED CONTEXT
« A Bounded Context is a specific responsability
enforced by explicit boundaries »
On regroupe en bloc fonctionnel cohérent
Favorise le faible coupage et la forte cohésion
On évite d’avoir du code anémique
On garde la logique au sein du service

47. PENSER
« COARSER-GRAINED »
Toujours penser au service de plus haut
niveau, puis affiner uniquement
si nécessaire ensuite

48. « COARSER-GRAINED »
Packaging
Service
Metadata
Repo
Service
Import
Service
Export
Service
Promo'on
Service
Compa'bilityChecker
Service
Repor'ng
Service
Exemple
Aucune
interac'ons
entre
les
services
de
plus
niveau
BOM
Service

49. ON ÉCRIT D’ABORD DU CODE
Au début d’un projet, on ne connaît pas tout le scope
du projet (le domaine change au fur et à mesure)
On a tendance à créer un Microservices à chaque
nouveau besoin
Découper trop tôt en Microservices peut empêcher
d’avoir une cohérence globale
Il est plus facile de décomposer en Microservices
une base de code existante que de partir de Zéro
On « refactore » ensuite

50. ON NE CÉDER PAS À LA TENTATION
On écrit des API qui répondent à des besoins réels et
pas à des besoins futurs non identifiés
On écrit des API qui est plus propice à l’extension
qu’à la modification
On limite le nombre de Microservices et on n’hésite
pas à faire du code jetable
On prend le temps sur la conception de la
modélisation de la donnée échangée

51. Microservices
Si on part d’un existant?

52. ON TROUVE LES SEAMS
Un « seam » est un bloc de code
indépendant
Ne pas hésiter à s’aider du découpage
en package
Chaque « seam » va délimiter la frontière de son
service
Trouver le bon découpage nécessite de comprendre
le fonctionnel et le métier des différentes
applications / services par les utilisateurs

53. ON SE REND CONFORME AUX
ARCHITECTURES MICROSERVICES
New
Service
Glue
Code
Monolith

54. DÉCOUPER EN SERVICES DEPUIS
UN SEUL SCHÉMA DE BASE
On découpe toujours d’abord les données pour
éviter de collaborer par le système de persistance
Import
Code
Monolithic
Schema
Monolithic
Service
PromoCon
Code
Import
Code
Import
Schema
PromoCon
Code
Promo
Con
Schema
Import
Service
Import
Schema
PromoCon
Service
Promo
Con
Schema
Monolithic
Service
1
2
3

55. MicroServices
« Les points d’attention »

56. AJOUT DE COMPLEXITÉ
POUR LES DÉVELOPPEURS
Un nouveau langage
ou une nouvelle technologie
à chaque service
Communication inter-service
Des systèmes de compensation
avec des cas d’utilisation transverses
entre les services

57. L’ENJEU D’UNE
COMMUNICATION RÉSEAU
Overhead
Latence
Fiabilité
L’infrastructure d’une architecture Microservices
prend encore plus d’importance.
Les NoOps n’existent pas.
Au contraire, le rôle des opérationnels est renforcé

58. CAS D’UNE COMMUNICATION EXTERNE
<person>
<firstname>Gregory<firstname>
<lastname>Boissinot<lastname>
</person>
<person>
<firstname>Gregory<firstname>
<lastname>Boissinot<lastname>
<twi?erid>gboissinot</twi?erid>
</person>
Règles:
- Soyer conservateur dans la production de vos contrats
- Soyer flexible dans ce que vous accepter en lecture
- Utiliser une sémantique de version comme
MAJOR.MINOR.PATCH
V1.0.0
V1.1.0
« Tolerent Consumer & Conservative producer »

59. ON MIGRE RAPIDEMENT
service
v1
Client
1
Client
2
service
v1
Client
1
Client
2
service
Client
1
Client
2
v2
v2
temps
On conserve pas longtemps les anciennes
versions
Release
1
Release
2
Release
3

60. MicroServices
« Pré requis DevOps »

61. « SELF CONTAINED
DEPLOYED MICROSERVICES »
On prend en considération la mixité
technologique au niveau CI
On automatise la construction (CI) et le
déploiement (CD) de chaque service
On doit assurer une certaine cohérence dans
la livraison logicielle
On doit fournir un unique point d’administration

62. 1 SERVICE PAR « HOST »
L’isolation
Host
Service
Host
Service
Host
Service
Host
Service
Avec un service par host, on évite les effets de bord
en s’assurant que chaque service s’exécute en
isolation avec ses prérequis technologiques

63. LA VIRTUALISATION
Une solution pour éviter d’avoir
plusieurs machines physiques
L’approche de la virtualisation est intéressante mais
elle a coût
Utilisation ou création d’images
On peut « provisionner » l’image pour les
besoins (Chef, Puppet, Ansible)
On voudrait idéalement exécuter chaque service
dans une VM séparée (chaque service apporte son
environnement)

64. LA VIRTUALISATION
Les problèmes
L’approche de la virtualisation est intéressante mais
elle a coût
Processus de création
d’une image assez long
Les images sont souvent volumineuses
(ex: > 20Go)
Le démarrage d’une VM peut prendre
plusieurs minutes

65. LES CONTAINERS
Les hyperviseurs (comme KVM, Xen, etc) sont
basés sur l’émulation d’infrastructure. C’est
coûteux en terme de prérequis.
L’approche Container propose une approche légère.
A la rescousse

66. Host
UN SERVICE PAR CONTAINER
Solution idéale avec le bon degré d’isolation
Container
Service
Container
Service
Container
Service
Container
Service
Les Containers sont rapides à provisionner

67. MicroServices
« Pourquoi Docker ? »

68. PLATEFORME DOCKER
L’approche de la virtualisation est intéressante mais
elle a coût
Plateforme construite sur
des containers Unix LXC
On crée et on déploie des applications comme
des images dans le monde de la virtualisation
Facilite le provisioning de chaque service
S’appuie sur une registre d’images Docker
1 Micro Service : 1 système Unix

69. UN VASTE ÉCOSYSTÈME
Une intégration dans les principaux outils de
l’usine logicielle
(Jenkins, Artifactory Pro, DockerHub, etc)
CoreOs (un Linux avec des services Docker)
Gestion de plusieurs containers (kubernetes,
CoreOs cluster, etc)

70. Des outils (CI)CD

71. UN ÉCOSYSTÈME D’OUTILS
POUR FACILITER LA MISE EN
ŒUVRE TECHNIQUE

72. Et la SOA?

73. ET LA SOA?
L’enjeu initial du SOA
• Découper une application monolithique en
services (favorisant la réutilisabilité)
• Focalisé sur l’intégration en lieu et place du
couplage des composants
Ce qui a généralement manqué
• Abstrait jusqu’à la mise en production
• Difficile à changer (ESB pattern)
• Manque de consensus de faire du SOA
correctement
De bonnes idées mais un manque de maturité

74. Conclusion

75. MICROSERVICES
Ne cédez pas à toutes les possibilités offertes
Surveillez, surveillez, … votre production!
Synthèse
L’enjeu est toujours de trouver le bon niveau de
granularité
Déporte une certaine complexité au niveau de
l’intégration et donc du déploiement
Nécessite d’avoir des cas d’usage qui s’y prêtent et
d’avoir des équipes « produit » compétentes pour sa
mise en place

76. MICROSERVICES
Une stratégie à long terme
Temps
#
de
services