@gboissinot	
  
101	
  
10	
  Février	
  2015	
  
Principes
&
Enjeux
EMERGENCE DES MICROSERVICES
Automa'sa'on	
  
(build,	
  test,	
  deploy)	
  
Consolidation d’expériences
MICROSERVICES
Les Microservices favorisent le découpage de
son système d’information en de petites unités
métiers indépend...
APPROCHE MONOLITHIQUE
UI	
  1	
  
Code	
  
Export	
  
Code	
  
PromoCon	
  
Code	
  
ApplicaCon	
  1	
  
UI	
  2	
  
Code	...
ON APPLIQUE LE CUBE DE SCALABILITÉ
ARCHITECTURE MICROSERVICES
UI	
  1	
  
Code	
  
Import	
  /	
  
Export/	
  
PromoCon	
  
Service	
  
UI	
  2	
  
Code	
  
...
LES MICROSERVICES
Pas de définition formelle mais un
ensemble de caractéristiques
Focalisé minutieusement sur une et une s...
ORIENTÉ « CAPACITÉ MÉTIER »
«	
  Gather	
  together	
  those	
  things	
  that	
  
change	
  for	
  the	
  same	
  reason,...
La liberté des Microservices permet de réagir et de
prendre des décisions plus rapidement
à des changements inévitables
(f...
FLEXIBILITÉ TECHNOLOGIQUE
Service	
  1	
  
«	
  Python	
  »	
  
	
  
Document	
  
Database	
  
	
  
Service	
  2	
  
Cloju...
FAVORISE LA MIGRATION VERS DES
ORGANISATIONS AGILES
Service	
  1	
  
C++	
  
Service	
  2	
  
Python	
  
Service	
  3	
  
...
COMPOSITION
COMPOSITION
FLEXIBILITÉ DE
REMPLACEMENT
New	
  	
  
Service	
  
Les architectures Microservices accélèrent
l’innovation
On diminue la ...
Implication des Ops dans le métier
Adapté aux nouvelles organisations
Client / Fournisseur
(Cloud, Infrastructure 2.0)
DES...
LA SCALABILITÉ EN ACTION
Application de
la loi de Conway
DES BÉNÉFICES ORGANISATIONNELS
MicroServices
« Collaboration »
UNE INTERFACE DE COMMUNICATION
SOUS FORME DE CONTRAT D’API
IMPL	
   PUBLIC	
  
API	
  
Service	
  
Une	
  bonne	
  API	
  ...
« ZONING DU SI»
?	
  
De	
  nombreux	
  
protocoles	
  et	
  API	
  
d’intégraCon:	
  
RMI	
  
JAX-­‐RPC	
  
JAX-­‐WS	
  
...
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’évoluti...
MAIS POUR LE PARTAGE DE
DONNÉES STATIQUES?
	
  	
  
T_CODE_PAYS	
  
DES SOLUTIONS À LA
GESTION DES DONNÉES
STATIQUES
Duplication de l’information (de la donnée)
dans chaque service
Gestion d...
ON ÉVITE DE COLLABORER À
TRAVERS UN BUS D’INTÉGRATION
Complex	
  IntegraCon	
  System	
  
(Encapsulate	
  Logic)	
  
Un bu...
ANALOGIE « TINKER TOY »
Des « endpoints » intelligents et des
communications simples
COLLABORATION
DES SERVICES ENTRE EUX
Trouver un modèle de collaboration
standard et efficace
API	
  A	
  
API	
  B	
  
Pro...
STYLES DE COLLABORATION
1) Request / Response (synchrone ou asynchrone)
2) Event Based (asynchrone)
Service	
  	
  
1	
  
...
LE REMOTING, STYLE INTRUSIF
Conçu pour cacher les appels distants
Diminue l’interdépendance des services en
raison du part...
LE MESSAGING A LA
RESCOUSSE
On connaît les fonctionnalités mais on abstrait
la localisation des services
La sémantique des...
L’EXISTENCE DE REST
« Identifiable Resources »
« Uniform interface »
« Stateless conversation »
« Resource representations...
« REST OVER HTTP »
Exploitation des méthodes HTTP
(GET, POST, PUT, DELETE, HEAD, PATCH, OPTIONS)
Facile à consommer avec t...
« UNIFORM INTERFACE »
REST OVER HTTP
Simplification d’accès
HTTP	
  
METHOD	
  
Resource	
  
names	
  
+	
  
Uniform	
  
i...
HATEOAS – HYPERMEDIA AS THE
ENGINE OF APPLICATION STATE
Les réponses REST contiennent
les liens dont on a besoin
Les clien...
MODÈLE DE MATURITÉ DE
RICHARDSON
La maturité de la mise en œuvre de REST
« EVENT-BASED COMMUNICATION »
On publie des événements
On souscrit à la réception d’événements
A chaque changement, un évé...
« EVENT-BASED ARCHITECTURE »
Les Microservices publient des événements
en cas de changement d’état
Les autres Microservice...
MicroServices
« Chez les géants
du Web »
DES CARACTÉRISTIQUES
COMMUNES
Compréhension du bénéfice d’avoir des équipes
autonomes gérant tout le cycle de vie des prod...
NETFLIX HYSTRIX
Librairie contrôlant la collaboration entre les différents
services pour offrir une grande tolérance à la ...
NETFLIX HYSTRIX
A
Microservices
Comment découper?
LES AUTRES TECHNIQUES
DE DÉCOMPOSITION
Shared Library
Modules
Les architectures Microservices peuvent être
combinées avec ...
SHARED LIBRARY
Uniquement les librairies dynamiques évitent
d’avoir à redéployer tous le processus en cas
de changement
Ne...
MODULES
Erlang propose en natif
sa notion de modules
Java avec OSGI n’a pas marché
en raison de sa mauvaise intégration au...
S’APPUYER SUR LES
BOUNDED CONTEXT
« A Bounded Context is a specific responsability
enforced by explicit boundaries »
On re...
PENSER
« COARSER-GRAINED »
Toujours penser au service de plus haut
niveau, puis affiner uniquement
si nécessaire ensuite
« COARSER-GRAINED »
Packaging	
  
Service	
  
Metadata	
  Repo	
  Service	
  
Import	
  
Service	
  
Export	
  
Service	
 ...
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 à me...
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...
Microservices
Si on part d’un existant?
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 « ...
ON SE REND CONFORME AUX
ARCHITECTURES MICROSERVICES
New	
  
Service	
  
Glue	
  
Code	
  
Monolith	
  
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 l...
MicroServices
« Les points d’attention »
AJOUT DE COMPLEXITÉ
POUR LES DÉVELOPPEURS
Un nouveau langage
ou une nouvelle technologie
à chaque service
Communication in...
L’ENJEU D’UNE
COMMUNICATION RÉSEAU
Overhead
Latence
Fiabilité
L’infrastructure d’une architecture Microservices
prend enco...
CAS D’UNE COMMUNICATION EXTERNE
<person>	
  
	
  <firstname>Gregory<firstname>	
  
	
  <lastname>Boissinot<lastname>	
  
</p...
ON MIGRE RAPIDEMENT
service	
  
v1	
  
Client	
  1	
   Client	
  2	
  
service	
  
v1	
  
Client	
  1	
   Client	
  2	
  
...
MicroServices
« Pré requis DevOps »
« SELF CONTAINED
DEPLOYED MICROSERVICES »
On prend en considération la mixité
technologique au niveau CI	
  
On automatise...
1 SERVICE PAR « HOST »
L’isolation
Host	
  
Service	
  
Host	
  
Service	
  
Host	
  
Service	
  
Host	
  
Service	
  
Ave...
LA VIRTUALISATION
Une solution pour éviter d’avoir
plusieurs machines physiques
L’approche de la virtualisation est intére...
LA VIRTUALISATION
Les problèmes
L’approche de la virtualisation est intéressante mais
elle a coût
Processus de création
d’...
LES CONTAINERS
Les hyperviseurs (comme KVM, Xen, etc) sont
basés sur l’émulation d’infrastructure. C’est
coûteux en terme ...
Host	
  
UN SERVICE PAR CONTAINER
Solution idéale avec le bon degré d’isolation
Container	
  
Service	
  
Container	
  
Se...
MicroServices
« Pourquoi Docker ? »
PLATEFORME DOCKER
L’approche de la virtualisation est intéressante mais
elle a coût
Plateforme construite sur
des containe...
UN VASTE ÉCOSYSTÈME
Une intégration dans les principaux outils de
l’usine logicielle
(Jenkins, Artifactory Pro, DockerHub,...
Des outils (CI)CD
UN ÉCOSYSTÈME D’OUTILS
POUR FACILITER LA MISE EN
ŒUVRE TECHNIQUE
Et la SOA?
ET LA SOA?
L’enjeu initial du SOA
•  Découper une application monolithique en
services (favorisant la réutilisabilité)
•  ...
Conclusion
MICROSERVICES
Ne cédez pas à toutes les possibilités offertes
Surveillez, surveillez, … votre production!
Synthèse
L’enjeu...
MICROSERVICES
Une stratégie à long terme
Temps	
  
#	
  de	
  services	
  
Prochain SlideShare
Chargement dans…5
×

PZ_Microservices101_20150210

1 306 vues

Publié le

Microservices 101 Presentation

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

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

Aucune remarque pour cette diapositive

PZ_Microservices101_20150210

  1. 1. @gboissinot   101   10  Février  2015  
  2. 2. Principes & Enjeux
  3. 3. EMERGENCE DES MICROSERVICES Automa'sa'on   (build,  test,  deploy)   Consolidation d’expériences
  4. 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. 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. 6. ON APPLIQUE LE CUBE DE SCALABILITÉ
  7. 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. 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. 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. 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. 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. 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. 13. COMPOSITION
  14. 14. COMPOSITION
  15. 15. FLEXIBILITÉ DE REMPLACEMENT New     Service   Les architectures Microservices accélèrent l’innovation On diminue la résistance au « refactoring »
  16. 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. 17. LA SCALABILITÉ EN ACTION
  18. 18. Application de la loi de Conway DES BÉNÉFICES ORGANISATIONNELS
  19. 19. MicroServices « Collaboration »
  20. 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. 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. 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. 23. MAIS POUR LE PARTAGE DE DONNÉES STATIQUES?     T_CODE_PAYS  
  24. 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. 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. 26. ANALOGIE « TINKER TOY » Des « endpoints » intelligents et des communications simples
  27. 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. 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. 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. 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. 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. 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. 33. « UNIFORM INTERFACE » REST OVER HTTP Simplification d’accès HTTP   METHOD   Resource   names   +   Uniform   interfaces  
  34. 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. 35. MODÈLE DE MATURITÉ DE RICHARDSON La maturité de la mise en œuvre de REST
  36. 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. 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. 38. MicroServices « Chez les géants du Web »
  39. 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. 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. 41. NETFLIX HYSTRIX A
  42. 42. Microservices Comment découper?
  43. 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. 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. 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. 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. 47. PENSER « COARSER-GRAINED » Toujours penser au service de plus haut niveau, puis affiner uniquement si nécessaire ensuite
  48. 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. 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. 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. 51. Microservices Si on part d’un existant?
  52. 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. 53. ON SE REND CONFORME AUX ARCHITECTURES MICROSERVICES New   Service   Glue   Code   Monolith  
  54. 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. 55. MicroServices « Les points d’attention »
  56. 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. 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. 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. 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. 60. MicroServices « Pré requis DevOps »
  61. 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. 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. 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. 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. 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. 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. 67. MicroServices « Pourquoi Docker ? »
  68. 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. 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. 70. Des outils (CI)CD
  71. 71. UN ÉCOSYSTÈME D’OUTILS POUR FACILITER LA MISE EN ŒUVRE TECHNIQUE
  72. 72. Et la SOA?
  73. 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. 74. Conclusion
  75. 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. 76. MICROSERVICES Une stratégie à long terme Temps   #  de  services  

×