@gboissinot
101
10 Février 2015
MicroServices
Principes & Enjeux
Automatisation
(build, test, deploy)
Les Microservices favorisent le découpage de
son système d’information en de petites unités
métiers indépendantes et auton...
UI 1
Cod
e
Export
Code
Promotion
Code
Application 1
UI 2
Code
Reporting
Code
Search Engine
Code
Application 2
BD
Store
Rem...
UI 1
Code
Import /
Export/
Promotion
Service
UI 2
Code
Reporting
Service
Search Engine
Service
BD
Store
Remote
Services
Da...
Focalisé minutieusement sur une et une seule
responsabilité
Possédant un contexte d’exécution séparé
(propre machine, prop...
« Gather together those things that
change for the same reason, and
separate those things that change for
different reason...
La liberté des Microservices permet de réagir et de
prendre des décisions plus rapidement
à des changements inévitables
(f...
Service 1
« Python »
Document
Database
Service 2
Clojure
Graph
Database
Service 3
Java
SQL
Database
Attention: Trouver le ...
Service 1
C++
Service 2
Python
Service 3
Java
On crée des équipes pluridisciplinaires co-localisés
orientées « Feature Mét...
New
Service
Les architectures Microservices accélèrent
l’innovation
Implication des Ops dans le métier
Adapté aux nouvelles organisations
Client / Fournisseur
(Cloud, Infrastructure 2.0)
Application de
la loi de Conway
MicroServices
« Collaboration »
IMPL
PUBLIC
API
Service
Une bonne API
• Agnostique à un
langage
• Porte la logique
d’intégration
Votre API est votre contr...
?
De nombreux
protocoles et API
d’intégration:
RMI
JAX-RPC
JAX-WS
JMS
SOAP/HTTP
REST/HTTP
AMQ
etc
Trouver la communication...
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 so...
T_CODE_PAYS
Duplication de l’information (de la donnée)
dans chaque service
Gestion de la donnée à travers du code
ou du paramétrage (...
Complex Integration System
(Encapsulate Logic)
Un bus d’intégration avec de la logique
(routage, transformation, etc) four...
APIA
APIB
Protocole A
Technologie A
Format de données A
Protocole B
Technologie B
Format de données B
L’intégration doit ê...
1) Request / Response (synchrone ou asynchrone)
2) Event Based (asynchrone)
Service
1
Service
1
Service
2
Service
2
Event
...
Conçu pour cacher les appels distants
Diminue l’interdépendance des services en raison
du partage d’un contrat
Fragile car...
On connaît les fonctionnalités mais on abstrait
la localisation des services
La sémantique des messages pilotent le
traite...
« Idenfiable Resources »
« Uniform interface »
« Stateless conversation »
« Resource representations »
« Hypermedia (HATEO...
Exploitation des méthodes HTTP
(GET, POST, PUT, DELETE, HEAD, PATCH, OPTIONS)
Facile à consommer avec tous les langages
Pl...
HTTP
METHOD
Resource
names
+
Uniform
interfaces
Les réponses REST contiennent
les liens dont on a besoin
Les clients interagissent par « hypermedia »
Pas de connaissance ...
On publie des événements
On souscrit à la réception d’événements
A chaque changement, un événement est
envoyé
Les Microservices publient des événements
en cas de changement d’état
Les autres Microservices souscrivent aux
événements ...
MicroServices
« Chez les géants
du Web »
Compréhension du bénéfice d’avoir des équipes
autonomes gérant tout le cycle de vie des produits
(conception, implémentati...
Librairie contrôlant la collaboration entre les différents
services pour offrir une grande tolérance à la latence
et à l’é...
A
Microservices
Comment découper?
Shared Library
Modules
Les architectures Microservices peuvent être combinées
avec d’autres techniques de décomposition.
S...
Uniquement les librairies dynamiques évitent
d’avoir à redéployer tous le processus en cas
de changement
Ne pas hésiter à ...
Erlang propose en natif
sa notion de modules
Java avec OSGI n’a pas marché
en raison de sa mauvaise intégration au
langage...
« A Bounded Context is a specific responsability
enforced by explicit boundaries »
On regroupe en bloc fonctionnel cohéren...
Toujours penser au service de plus haut
niveau, puis affiner uniquement
si nécessaire ensuite
Packaging
Service
Metadata Repo Service
Import
Service
Export
Service
Promotion
Service
CompatibilityChecker
Service
Repor...
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é...
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 pl...
Microservices
Si on part d’un existant?
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 ...
New
Service
Glue
Code
Monolith
On découpe toujours d’abord les données pour
éviter de collaborer par le système de persistance
Import
Code
Monolithic
Sch...
MicroServices
« Les points d’attention »
Un nouveau langage
ou une nouvelle technologie
à chaque service
Communication inter-service
Des systèmes de compensation
a...
Overhead
Latence
Fiabilité
L’infrastructure d’une architecture Microservices prend
encore plus d’importance.
Les NoOps n’e...
<person>
<firstname>Gregory<firstname>
<lastname>Boissinot<lastname>
</person>
<person>
<firstname>Gregory<firstname>
<las...
service
v1
Client 1 Client 2
service
v1
Client 1 Client 2
service
Client 1 Client 2
v2 v2
temps
Release 1 Release 2 Releas...
MicroServices
« Pré requis DevOps »
On prend en considération la mixité
technologique au niveau CI
On automatise la construction (CI) et le
déploiement (CD) d...
Host
Service
Host
Service
Host
Service
Host
Service
Avec un service par host, on évite les effets de bord
en s’assurant qu...
L’approche de la virtualisation est intéressante mais
elle a coût
Utilisation ou création d’images
On peut « povisionner »...
L’approche de la virtualisation est intéressante mais
elle a coût
Processus de création
d’une image assez long
Les images ...
Les hyperviseurs (comme KVM, Xen, etc) sont basés sur
l’émulation d’infrastructure.
C’est coûteux en terme de prérequis.
L...
Host
Container
Service
Container
Service
Container
Service
Container
Service
Les Containers sont rapides à provisionner
MicroServices
« Pourquoi Docker ? »
L’approche de la virtualisation est intéressante mais
elle a coût
Plateforme construite sur
des containers Unix LXC
On cré...
Une intégration dans les principaux outils de
l’usine logicielle
(Jenkins, Artifactory Pro, DockerHub, etc)
CoreOs (un Lin...
Des outils (CI)CD
Et la SOA?
L’enjeu initial du SOA
• Découper une application monolithique en
services (favorisant la réutilisabilité)
• Focalisé sur ...
Conclusion
Ne cédez pas à toutes les possibilités offertes
Surveiller, surveiller, … votre production!
L’enjeu est toujours de trouve...
Temps
# de services
Conference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partie
Conference MicroServices101 - 1ere partie
Prochain SlideShare
Chargement dans…5
×

Conference MicroServices101 - 1ere partie

1 609 vues

Publié le

Le terme ‘Microservices’ fait le buzz depuis plusieurs mois déjà dans l’ingénierie logicielle. Durant cette soirée, Zenika vous propose de décrire en détail cette technique de décomposition de son système d’information.

La première partie de la soirée présente les enjeux des MicroServices et les différents cas d’utilisation.
La seconde partie aborde différents frameworks Java qui peuvent être utilisés pour la mise en place d’une architecture MicroServices.

Publié dans : Technologie
0 commentaire
11 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
1 609
Sur SlideShare
0
Issues des intégrations
0
Intégrations
41
Actions
Partages
0
Téléchargements
64
Commentaires
0
J’aime
11
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Conference MicroServices101 - 1ere partie

  1. 1. @gboissinot 101 10 Février 2015
  2. 2. MicroServices Principes & Enjeux
  3. 3. Automatisation (build, test, deploy)
  4. 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. 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
  6. 6. 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
  7. 7. 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
  8. 8. « 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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. New Service Les architectures Microservices accélèrent l’innovation
  13. 13. Implication des Ops dans le métier Adapté aux nouvelles organisations Client / Fournisseur (Cloud, Infrastructure 2.0)
  14. 14. Application de la loi de Conway
  15. 15. MicroServices « Collaboration »
  16. 16. 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
  17. 17. ? 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!
  18. 18. 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
  19. 19. T_CODE_PAYS
  20. 20. 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é
  21. 21. 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
  22. 22. 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
  23. 23. 1) Request / Response (synchrone ou asynchrone) 2) Event Based (asynchrone) Service 1 Service 1 Service 2 Service 2 Event subscribespublishes
  24. 24. 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
  25. 25. 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
  26. 26. « Idenfiable Resources » « Uniform interface » « Stateless conversation » « Resource representations » « Hypermedia (HATEOS) »
  27. 27. 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
  28. 28. HTTP METHOD Resource names + Uniform interfaces
  29. 29. 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
  30. 30. On publie des événements On souscrit à la réception d’événements A chaque changement, un événement est envoyé
  31. 31. 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
  32. 32. MicroServices « Chez les géants du Web »
  33. 33. 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
  34. 34. 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)
  35. 35. A
  36. 36. Microservices Comment découper?
  37. 37. Shared Library Modules Les architectures Microservices peuvent être combinées avec d’autres techniques de décomposition. Service Service Service Library ModuleAv1 ModuleAv2 ModuleB
  38. 38. 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
  39. 39. 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
  40. 40. « 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
  41. 41. Toujours penser au service de plus haut niveau, puis affiner uniquement si nécessaire ensuite
  42. 42. 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
  43. 43. 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
  44. 44. 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
  45. 45. Microservices Si on part d’un existant?
  46. 46. 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
  47. 47. New Service Glue Code Monolith
  48. 48. 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
  49. 49. MicroServices « Les points d’attention »
  50. 50. 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
  51. 51. 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é
  52. 52. <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
  53. 53. 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
  54. 54. MicroServices « Pré requis DevOps »
  55. 55. 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
  56. 56. 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
  57. 57. 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)
  58. 58. 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
  59. 59. 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
  60. 60. Host Container Service Container Service Container Service Container Service Les Containers sont rapides à provisionner
  61. 61. MicroServices « Pourquoi Docker ? »
  62. 62. 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
  63. 63. 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)
  64. 64. Des outils (CI)CD
  65. 65. Et la SOA?
  66. 66. 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
  67. 67. Conclusion
  68. 68. 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
  69. 69. Temps # de services

×