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