Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Migrer vers une architecture micro-services : p...

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. Conséquences - Plus (+) de : - Dépôts de code

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

    - Bouleversement de l’organisation - Impacts sur la performance
  3. Avantages / Inconvénients - Permet de préparer une architecture orientée

    service - Les avantages du monolithe avec les avantages du service - Risque de couplage
  4. 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
  5. -Point n°4- Il est possible de changer et de remettre

    en question la découpe des services
  6. 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
  7. 3 services I N O U T O U T

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

    I N O U T I N I N O U T 12 flux
  9. 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
  10. 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
  11. 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
  12. É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
  13. 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.
  14. 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)
  15. Exploitation - Hausse du nombre de services à déployer et

    à exploiter - Analyses plus complexes, car les traitements sont distribués
  16. 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.
  17. 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
  18. 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
  19. 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
  20. 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.
  21. 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
  22. 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
  23. 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.
  24. 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
  25. 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é
  26. 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
  27. 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
  28. 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