Le document traite des microservices, abordant leur architecture et principes de déploiement autonomes pour optimiser les systèmes d'information. Il met en avant l'importance d'une communication efficace entre services, l'utilisation d'APIs agnostiques, et les défis liés à la gestion des versions et à l'intégration. La nécessité d'une culture DevOps et d'outils adaptés, comme Docker, est également soulignée pour soutenir l'innovation et la flexibilité.

1. @gboissinot
101
10 Février 2015

2. MicroServices
Principes & Enjeux

3. Automatisation
(build, test, deploy)

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

5. UI 1
Cod
e
Export
Code
Promotion
Code
Application 1
UI 2
Code
Reporting
Code
Search Engine
Code
Application 2
BD
Store
Remote
Services
BD Search &
Reporting
Import
Code

7. UI 1
Code
Import /
Export/
Promotion
Service
UI 2
Code
Reporting
Service
Search Engine
Service
BD
Store
Remote
Services
Data
for Reporting
Data
For Search

8. 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é
Utilise un système d’inscription et de désinscription du
réseau de Microservices

9. « 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)
Responsive
Elastic Resilient
Message
-driven
Reactive Manifesto Pattern

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

12. Service 1
C++
Service 2
Python
Service 3
Java
On crée des équipes pluridisciplinaires co-localisés
orientées « Feature Métier »
Build & Run
Build & Run
Build & Run

15. New
Service
Les architectures Microservices accélèrent
l’innovation

16. Implication des Ops dans le métier
Adapté aux nouvelles organisations
Client / Fournisseur
(Cloud, Infrastructure 2.0)

18. Application de
la loi de Conway

19. MicroServices
« Collaboration »

20. IMPL
PUBLIC
API
Service
Une bonne API
• Agnostique à un
langage
• Porte la logique
d’intégration
Votre API est votre contrat en regroupant
l’ensemble des opérations exportables pour vos
consommateurs.
Elle doit évoluer indépendamment de votre code

21. ?
De nombreux
protocoles et API
d’intégration:
RMI
JAX-RPC
JAX-WS
JMS
SOAP/HTTP
REST/HTTP
AMQ
etc
Trouver la communication la
plus simple possible!

22. 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. T_CODE_PAYS

24. 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. Complex Integration 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

27. APIA
APIB
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. 1) Request / Response (synchrone ou asynchrone)
2) Event Based (asynchrone)
Service
1
Service
1
Service
2
Service
2
Event
subscribespublishes

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

30. 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. « Idenfiable Resources »
« Uniform interface »
« Stateless conversation »
« Resource representations »
« Hypermedia (HATEOS) »

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

33. HTTP
METHOD
Resource
names
+
Uniform
interfaces

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

36. On publie des événements
On souscrit à la réception d’événements
A chaque changement, un événement est
envoyé

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

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

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

41. A

42. Microservices
Comment découper?

43. Shared Library
Modules
Les architectures Microservices peuvent être combinées
avec d’autres techniques de décomposition.
Service Service Service
Library
ModuleAv1
ModuleAv2
ModuleB

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

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

46. « 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. Toujours penser au service de plus haut
niveau, puis affiner uniquement
si nécessaire ensuite

48. Packaging
Service
Metadata Repo Service
Import
Service
Export
Service
Promotion
Service
CompatibilityChecker
Service
Reporting
Service Aucune interactions
entre les services de
plus niveau
BOM
Service

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

50. On écrit des API qui répondent à des besoins réels et
pas à des besoins futurs non idientifié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. 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. New
Service
Glue
Code
Monolith

54. 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
Promotion
Code
Import
Code
Import
Schema
Promotion
Code
Promot
ion
Schema
Import
Service
Import
Schema
Promotion
Service
Promot
ion
Schema
Monolithic Service
1 2 3

55. MicroServices
« Les points d’attention »

56. 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. 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. <person>
<firstname>Gregory<firstname>
<lastname>Boissinot<lastname>
</person>
<person>
<firstname>Gregory<firstname>
<lastname>Boissinot<lastname>
<twitterid>gboissinot</twitterid>
</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

59. service
v1
Client 1 Client 2
service
v1
Client 1 Client 2
service
Client 1 Client 2
v2 v2
temps
Release 1 Release 2 Release 3

60. MicroServices
« Pré requis DevOps »

61. 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. 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. L’approche de la virtualisation est intéressante mais
elle a coût
Utilisation ou création d’images
On peut « povisionner » 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. 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 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 lightweight

66. Host
Container
Service
Container
Service
Container
Service
Container
Service
Les Containers sont rapides à provisionner

67. MicroServices
« Pourquoi Docker ? »

68. 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 registry d’images Docker

69. 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’s cluster, etc)

70. Des outils (CI)CD

72. Et la SOA?

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

74. Conclusion

75. Ne cédez pas à toutes les possibilités offertes
Surveiller, surveiller, … votre production!
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. Temps
# de services