Les slides de la session du mois d'Avril 2017 du Meetup DotNetTlse

1. Ionut Mihalcea – Effective Labs – @imihalceaMeet-up .Net Toulouse
ARCHITECTURE
MICROSERVICES

2. Effective Labs
 Rendre la conception et le développement logiciel plus
qualitatif et inspirant.
 La mission est d’apporter des solutions et d'assurer la
montée en compétences des personnes en travaillant sur 3
thèmes :
 Conception produit
 Culture Lean & Agile
 Software Craftsmanship

3. Pourquoi le sujet ?
 Un sujet qui fait le buzz depuis 2 - 3 ans
 Faire un point sur le sujet
 Vous raconter une expérience en cours
 Mais aussi parce que :
 On commence à parler plus d’outils que des principes
(je trouve ça dangereux)
 Une tendance, chez certains, à penser que ça va résoudre
tous leurs problèmes (je ne suis pas si sur)

4. Existe t-il une définition pour les
Architectures Microservices ?
Réponse :
Non !

5. Définition par opposition !
 Monolithe  Microservices

6. Besoin : « Componentisation » des applications
 Composant :
 Changé indépendamment
 Mis à jour indépendamment
 Un problème déjà résolu :
 Les librairies
 IoC

7. Besoin : Scalabilité et maitrise des couts et délais
de la mise en production
 Monolythe

8. Besoin : Scalabilité et maitrise des couts et délais
de la mise en production
 Microservices

9. Besoin : Scalabilité des équipes
 1 Microservice = 1 équipe
 2 pizzas
 Autonome
 Avec son propre rythme de mise
en production
https://youtu.be/4GK1NDTWbkY
 Monolithe vs Microservices

10. Une vue de haut niveau
https://martinfowler.com/articles/microservices.html

11. Principes de conception
Cohésion
 Fait une seule chose
 Un seul focus
Approche
 Découper un service : un
service a une seule raison
de changer
Résilience
 Comportement par défaut
 Fonctionnalité dégradée
Approche
 Prévoir les cas d’erreurs
 MTTR vs MTBF
Autonomie
 Pouvoir les remplacer et
déployer indépendamment
Approche
 Faible couplage
 Versioning
 1 service = 1 équipe
Orienté métier
 Une fonction ou domaine
métier
Approche
 Identifier les domaines
 Découper puis grouper les
fonctionnalités
Observable
 Etat du système
 Log et monitoring
Approche
 Outils monitoring et log
centralisés
 Comprendre l’ensemble
Automatisation
 Tests
 Déploiements
 Containers
Approche
 Intégration continue
 Déploiement continuu

12. Du moins quelques unes…
Quels sont les difficultés ?

13. La taille compte
 Trop gros => architecture
à base de monolithes
 Trop micro => pas de
consistance trop complexe
 Pistes
 Découpage des domaines business
en fonctions ou groupes de fonction
 2 pizzas teams

14. Communication asynchrone
 Asynchrone
 C’est indispensable
 Peut résoudre en même temps un problème
de couplage
A
 Synchrone
 Ce scenario n’est pas toujours possible
B
m A
m B
A B
Message
Broker

15. Découverte des services
 Contexte
 Plusieurs clients (site web,
applications mobiles)
 Plusieurs services
(catalogue, commande,
payement…)
 Le problème
 Comment les clients
accèdent aux services
individuels?
 Solution possible
https://microservices.io

16. Trace Distribuée
 Solution possible
 Log centralisé
 Générer et tracer un
CorrelationID (cId)
A B C
D E
 Un scenario utilisateur implique
plusieurs services
 Comment l’identifier en cas de
problème ?
m + cId
m + cId
m + cId

17. Changements culturels
 Petites équipes autonomes
 Décentralisation de la gouvernance
 Produits vs projets

18. Et ce n’est pas tout
 Transactions distribuées
 Operations de « undo » ?
 2 phase commit ?
 Sécurité
 centralisée au niveau API Getway, ou pour chaque service ?
 Reporting
 Passer par une base de Reporting systématiquement ?
 Conception fonctionnelle
 Prévoir les fonctionnalités dégradées, gestion des cas d’erreur
 …

19. Peler le monolithe…
Un scenario d’adoption heureux ?

20. Contexte
 Editeur de logiciels
 Produits (age 15 ans)
 ASP.NET WebForms, Framework 4
 Hébergement Cloud et On-Premise
 Clients : Grands comptes et administration
 Utilisateurs : 450 000, 17 pays
 Equipe : 9 devs, 3 fonctionnels, 3 Ops
 Organisation : Scrum

21. Problème
 Monolithe
 Défauts de conception
 Problèmes de
performances
 Nb croissant d’incidents
client
 Perte de connaissance
fonctionnelle
 Volonté
 Refondre le produit de
manière incrémentale
 Répondre aux
problèmes du moment
 Qualité
 Performance

22. Architecture en place
Ged
Dématérialisation
de flux

23. Quel processus ?
1. Identification des domaines et
sous-domaine fonctionnels
2. Ecriture de tests fonctionnels
3. Automatisation des tests
fonctionnels
4. Refonte totale ou refactoring
dans un librairie séparée
4. Mise en place du
microservice
5. Prod. 2 sem. sur 500
utilisateurs
6. Prod. 4 sem. sur 10000
utilisateurs
7. Prod. pour tous les
utilisateurs

24. Internet
UI
Service
Business
DAL
BD
Client

25. Internet
UI
Service
Business
DAL
BD
Client

26. Domaine 1
Domaine 2
Domaine 3
…

27. Internet
UI
Service
DAL
BD
Client
Domaine1Domaine2Domaine3
…

28. Service
Domaine 1
Internet
UI
Service
DAL
BD
Client
Domaine2Domaine3
…
Message
Broker
Domaine1
Log /Monitoring
Centralisé
DAL
Domaine
1
BD

29. Et avant …
 Formation technique
des développeurs
 Recrutement d’un chef
produit
 Culture DevOps
 Mise en place de
l’infrastructure
 Fonctionnement en
double des systèmes
 Automatisation

30. Conclusion

31. Les microservices
 Composants
 Orienté Métier
 Produits pas Projets
 Services intelligents et
« plomberie » basique
 Conçus en prenant en
compte l’échec :
résilience
 Conception évolutive
 Décentralisation de la
gouvernance
 Décentralisation des
données
 Automatisation

32. Comparaison
 Simplicité
 Consistance
 Refactoring inter-
module
 Déploiement
 Disponibilité
 Frontières fortes
 Multi-plateforme
Monolithe Microservices

33. Les microservices
 C’est pas nouveau (peut-être un renouveau plus pragmatique de la SOA)
 Résout des problèmes mais ajoute aussi de la complexité
 Au-delà de la technique nécessitent beaucoup plus de réflexion sur le plan
fonctionnel
 Réflexion sur l’organisation : petites équipes autonomes
 Formation technique et culture DevOps

34. 3 points importants
 Répondent à besoin de « Scalabilité »
 Approche intéressante dans la refonte d’un « monolithe »
 Si on démarre un nouveau produit
 Démarrer avec « monolithe » que nous maintenons modulaire
 Passer aux microservices quand le monolithe devient un problème