PZ_Microservices101_20150210

1 345 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 345
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  

×