Migrer vers une architecture micro-services : points de contrôle pour une migration réussie

Migrer vers une architecture micro-services : points de contrôle pour une migration réussie

8665aad8f35b1710df79e9aef52d6daa?s=128

Alexandre Salomé

September 23, 2020
Tweet

Transcript

  1. Architecture micro-services Points de contrôle pour une adoption réussie Alexandre

    Salomé - 2020
  2. Introduction

  3. Objectif

  4. Pré-requis - Un métier complexe - Une équipe étendue -

    Avoir essayé sans micro-services
  5. Conséquences - Plus (+) de : - Dépôts de code

    - Code - Procédures - Demande beaucoup d’organisation - Apporte des nouveaux défis
  6. Risques - Coûts importants - Augmentation des coûts de développement

    - Bouleversement de l’organisation - Impacts sur la performance
  7. Bénéfices - Séparation par responsabilité - Des services indépendants

  8. -Point n°1- L’ architecture orientée service répond à un besoin

    de structuration de l’équipe
  9. Solution alternative

  10. Séparation logique Séparez votre code par modules logique (bundles).

  11. Séparation logique Séparez votre code par sous-dossiers

  12. Modèle d’interfaçage Format des données échangées avec les autres modules.

  13. Événements métier inter-services Côté Order : Côté Stock :

  14. Préparez vous pour l’asynchrone Symfony Messenger permet de rendre configurable

    le traitement asynchrone de ce traitement.
  15. Avantages / Inconvénients - Permet de préparer une architecture orientée

    service - Les avantages du monolithe avec les avantages du service - Risque de couplage
  16. -Point n°2- La qualité du code n’est pas l’élément décisif

  17. Préparation

  18. Après-vente Vente Avant-vente Order Customer Catalog Payment Transport Sourcing Accounting

    Stock Offers Return Exemple de découpe pour un OMS Cet exemple est fictif et ne saurait représenter un vrai travail d’étude fonctionnelle
  19. -Point n°3- La découpe en services est issue d’un réel

    travail d’étude fonctionnelle
  20. Comment découper, quelle granularité ? Payment Paypal Voucher micro-services lambdas

    services
  21. -Point n°4- Il est possible de changer et de remettre

    en question la découpe des services
  22. Migration progressive - L’existant comme un composant de l’architecture -

    Progressivement migrer Ancien système Migration progressive sur X mois/années Nouveau système
  23. La synchronisation vers l’existant - Votre pire cauchemar - Ralentit

    la performance
  24. Migration progressive d’un système Utilisateur Existant

  25. Migration progressive d’un système Utilisateur Existant Payment

  26. Migration progressive d’un système Utilisateur Existant Payment Stock

  27. Migration progressive d’un système Utilisateur Existant Payment Stock Catalog

  28. Migration progressive d’un système Utilisateur Payment Stock Catalog

  29. -Point n°5- L’existant est maintenu, au même titre que les

    services
  30. Le chemin de la migration

  31. Exemple de service I N O U T

  32. 2 services I N O U T O U T

    I N 2 flux
  33. 3 services I N O U T O U T

    I N O U T I N 6 flux
  34. 4 services I N O U T O U T

    I N O U T I N I N O U T 12 flux
  35. Documentation de l’architecture Contenu - Données portées par chaque composant

    - Modèles de données d’échange - APIs: format d’entrée et de sortie et traitements associés - Événements : émetteurs, récepteurs et traitements associés Objectifs - Partager l’organisation des des services
  36. Exemple de documentation Données : commandes APIs Événements émis -

    order:update Événements consommés - stock:reserved - payment:update Order Données : quantité de stock APIs Événements émis - stock:reserved Événements consommés - order:update Stock
  37. Exemple de documentation Données : produit et offres Événements émis

    - product:update - offer:update Catalog Données : paiements Événements émis - payment:update Événements consommés - order:update Payment
  38. Cartographier vos métiers, données, traitements, applications et vos échanges. -Point

    n°6-
  39. Échanges synchrones et asynchrones Rappels - Synchrone : un appel

    d’API tierce, on attend une réponse - Asynchrone : un envoi de message, on notifie sans attendre de réponse Solutions - Synchrone : Symfony HttpClient - Asynchrone : Symfony Messenger
  40. Symfony Messenger pour du publish/subscribe - Par défaut, Symfony Messenger

    n’a pas vocation à être utilisé entre plusieurs applications, ni à faire du publish/subscribe.
  41. Partage d’un modèle commun - Création d’une ou plusieurs librairie

    pour partager les ApiModel / Message / Clients. - Attention à bien garder la rétro-compatibilité : les services ne seront pas mises à jour en même temps (+ semantic versioning)
  42. Des échanges le plus simple possible

  43. Des échanges le plus simple possible

  44. Utilisez une couche de service transverse pour les échanges synchrones/asynchrones.

    -Point n°7-
  45. Exploitation - Hausse du nombre de services à déployer et

    à exploiter - Analyses plus complexes, car les traitements sont distribués
  46. Observabilité - Utiliser un identifiant de corrélation pour tous les

    échanges issus d’une requête en particulier. - Implicite dans tous les traitements, pour garder le code le plus simple possible. - API → Message → Message → API - Un outil d’analyse des journaux/métriques permettant la corrélation.
  47. Des outils d’exploitation à la hauteur des enjeux -Point n°8-

  48. Profilage distribué

  49. Interface utilisateur Deux solutions : - Un service à part

    - Intégré dans les services
  50. Couche intégration Besoin d’une couche d’intégration transverse pour : -

    Les traitements transverses (reporting, coordination) - Étendre des solutions existantes - Fournir des APIs simplifiées
  51. Les pièges

  52. Nommez littéralement vos services -Point n°9-

  53. Manque d’expertise La migration vers une architecture micro-services demande beaucoup

    de connaissance, que ça soit en architecture, en expertise, en système et en services. Un tel travail de migration demande un effort colossal et présente beaucoup de risques. Se faire accompagner par des experts permet de se rassurer sur la stratégie de migration et les outils retenus, la méthode et la démarche choisies. Risques : hausse du coût de production, remise en question perpétuelle
  54. Coordination des déploiements La majorité des fonctionnalités porte sur plusieurs

    services, et il arrive que deux composants comportent chacun une moitié de fonctionnalité. Partant de là, il y a 2 possibilités : - Déployer l’un, puis l’autre avant d’activer la fonctionnalité - Coordonner le déploiement des 2 applications (avec arrêt de service) Il est fortement recommandé d’utiliser la première possibilité, en prévoyant dès la conception le déploiement. Risques : erreurs et anomalies en production
  55. Transactions Il arrive parfois que certains traitements soient groupés dans

    une transaction. Par exemple : un paiement CB. On ne souhaite pas débiter si le stock ne peut pas être réservé, et inversement. - Dans un tel cas, il n’est pas possible de faire autrement qu’un de ces deux parti-pris : 1. Débit puis réservation : le risque est de débiter sans réserver 2. Réservation puis débit : le risque est de réserver sans débiter Pas de solution idéale.
  56. Perte de performance La migration progressive vient alourdir certains traitements,

    et la distribution en services également, sous certaines conditions. Cette dégradation de performance technique doit être assumée et maîtrisée pour minimiser voir réduire à zéro l’impact de la migration sur le service. Risques : dégrader la performance des systèmes et du métier
  57. Le retour du monolithe Il arrive, après quelques années de

    migration, que certaines personnes sortent un argument de taille : “Pourquoi on ne ferait pas une seule application pour XXX ?” Leur argument est de taille : ça serait plus simple. Risques : doute, incertitude, remise en question, sabotage Solution : redonner le sens et les raisons d’un tel choix
  58. Le manque d’agilité La migration progressive et un travail colossal,

    et personne ne sait, au départ, comment elle va se passer exactement. L’agilité (au sens du manifeste) apportera à l’organisation : - De la flexibilité dans la démarche pour supporter les changements, les remises en question - De la communication pour avoir de la part des équipes de réalisation le feedback nécessaire à la bonne prise de décision L’écoute et la prise en compte de chacun est indispensable.
  59. Introduisez progressivement le changement, validez chaque étape avant la suivante.

    -Point n°10-
  60. Conclusion

  61. Le rôle d’architecte - Identifier les travaux et les standards

    nécessaires à la réussite du projet - Assister les équipes dans la transformation - Éclairer les équipes dans les prises de décision - Alerter sur les opportunités techniques et fonctionnelles - Challenger les équipes de gouvernance - Co-construire le pilotage opérationnel du projet - Veiller à l’identification et à la maîtrise des risques
  62. Le rôle de lead developer - Assurer le respect des

    consignes d’architecture - Encourager les équipes à définir les solutions - Faire émerger le cadre des pratiques du projet - Documentation - Tests - Intégration - Performance - Sécurité
  63. En résumé 1. Trouvez les bonnes opportunités 2. Faites une

    architecture fonctionnelle, puis technique 3. Maintenez une cartographie de vos services et des vos échanges 4. Autorisez-vous à vous tromper, car vous allez vous tromper 5. Maîtrisez votre chaîne de production 6. Entourez-vous de personnes expérimentés 7. Assurez-vous que tout le monde comprenne et accepte la migration
  64. En conclusion - L’architecture orientée services apporte de la flexibilité

    - On peut remettre en question un périmètre sans impacter les autres - Chaque service est indépendant des autres - L’architecture orientée services apporte de la simplicité - L’architecture fonctionnelle donne le sens et les applications ont un périmètre délimité - Elle permet d’éviter le symptôme de l’application monolithe, complexe et critique - L’architecture orientée services nécessite de l’organisation - La migration progressive d’une application monolithique implique souvent toute l’entreprise, car tous les métiers sont généralement concernés. - L’architecture orientée services a un coût et des risques - Cela nécessite un pilotage performant et de qualité - Un accompagnement permet de s’assurer de la réussite d’une telle transformation
  65. None
  66. Et voilà ! Remerciements Symfony, pour avoir accepté ma conférence

    et pour l’organisation de l’événement. Vous, pour votre participation aujourd’hui. Contenu de la présentation - Icônes de Freepik de Flaticon - Code rendu avec carbon.now.sh