$30 off During Our Annual Pro Sale. View Details »

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

Alexandre Salomé

September 23, 2020
Tweet

More Decks by Alexandre Salomé

Other Decks in Programming

Transcript

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

    View Slide

  2. Introduction

    View Slide

  3. Objectif

    View Slide

  4. Pré-requis
    - Un métier complexe
    - Une équipe étendue
    - Avoir essayé sans micro-services

    View Slide

  5. Conséquences
    - Plus (+) de :
    - Dépôts de code
    - Code
    - Procédures
    - Demande beaucoup d’organisation
    - Apporte des nouveaux défis

    View Slide

  6. Risques
    - Coûts importants
    - Augmentation des coûts de développement
    - Bouleversement de l’organisation
    - Impacts sur la performance

    View Slide

  7. Bénéfices
    - Séparation par responsabilité
    - Des services indépendants

    View Slide

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

    View Slide

  9. Solution alternative

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  16. -Point n°2-
    La qualité du code n’est pas l’élément décisif

    View Slide

  17. Préparation

    View Slide

  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

    View Slide

  19. -Point n°3-
    La découpe en services est issue
    d’un réel travail d’étude fonctionnelle

    View Slide

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

    View Slide

  21. -Point n°4-
    Il est possible de changer et de remettre en question
    la découpe des services

    View Slide

  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

    View Slide

  23. La synchronisation vers l’existant
    - Votre pire cauchemar
    - Ralentit la performance

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  30. Le chemin de la migration

    View Slide

  31. Exemple de service
    I
    N
    O
    U
    T

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  38. Cartographier vos métiers, données, traitements,
    applications et vos échanges.
    -Point n°6-

    View Slide

  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

    View Slide

  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.

    View Slide

  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)

    View Slide

  42. Des échanges le plus simple possible

    View Slide

  43. Des échanges le plus simple possible

    View Slide

  44. Utilisez une couche de service transverse pour les
    échanges synchrones/asynchrones.
    -Point n°7-

    View Slide

  45. Exploitation
    - Hausse du nombre de services à déployer et à exploiter
    - Analyses plus complexes, car les traitements sont distribués

    View Slide

  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.

    View Slide

  47. Des outils d’exploitation à la hauteur
    des enjeux
    -Point n°8-

    View Slide

  48. Profilage distribué

    View Slide

  49. Interface utilisateur
    Deux solutions :
    - Un service à part
    - Intégré dans les services

    View Slide

  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

    View Slide

  51. Les pièges

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  59. Introduisez progressivement le changement,
    validez chaque étape avant la suivante.
    -Point n°10-

    View Slide

  60. Conclusion

    View Slide

  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

    View Slide

  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é

    View Slide

  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

    View Slide

  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

    View Slide

  65. View Slide

  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

    View Slide