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

Introduction

Objectif

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

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

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

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

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

Solution alternative

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

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

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

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

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

Avantages / Inconvénients - Permet de préparer une architecture orientée service - Les avantages du monolithe avec les avantages du service - Risque de couplage

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

Préparation

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

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

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

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

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

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

Migration progressive d’un système Utilisateur Existant

Migration progressive d’un système Utilisateur Existant Payment

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

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

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

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

Le chemin de la migration

Exemple de service I N O U T

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

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

4 services I N O U T O U T I N O U T I N I N O U T 12 flux

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

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

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

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

É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

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.

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)

Des échanges le plus simple possible

Des échanges le plus simple possible

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

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

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.

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

Profilage distribué

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

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

Les pièges

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

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

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

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.

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

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

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.

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

Conclusion

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

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é

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

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

No content

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