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

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