Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Ionut Mihalcea – Effective Labs – @imihalceaMeet-up .Net Toulouse
ARCHITECTURE
MICROSERVICES
Effective Labs
 Rendre la conception et le développement logiciel plus
qualitatif et inspirant.
 La mission est d’apport...
Pourquoi le sujet ?
 Un sujet qui fait le buzz depuis 2 - 3 ans
 Faire un point sur le sujet
 Vous raconter une expérie...
Existe t-il une définition pour les
Architectures Microservices ?
Réponse :
Non !
Définition par opposition !
 Monolithe  Microservices
Besoin : « Componentisation » des applications
 Composant :
 Changé indépendamment
 Mis à jour indépendamment
 Un prob...
Besoin : Scalabilité et maitrise des couts et délais
de la mise en production
 Monolythe
Besoin : Scalabilité et maitrise des couts et délais
de la mise en production
 Microservices
Besoin : Scalabilité des équipes
 1 Microservice = 1 équipe
 2 pizzas
 Autonome
 Avec son propre rythme de mise
en pro...
Une vue de haut niveau
https://martinfowler.com/articles/microservices.html
Principes de conception
Cohésion
 Fait une seule chose
 Un seul focus
Approche
 Découper un service : un
service a une ...
Du moins quelques unes…
Quels sont les difficultés ?
La taille compte
 Trop gros => architecture
à base de monolithes
 Trop micro => pas de
consistance trop complexe
 Piste...
Communication asynchrone
 Asynchrone
 C’est indispensable
 Peut résoudre en même temps un problème
de couplage
A
 Sync...
Découverte des services
 Contexte
 Plusieurs clients (site web,
applications mobiles)
 Plusieurs services
(catalogue, c...
Trace Distribuée
 Solution possible
 Log centralisé
 Générer et tracer un
CorrelationID (cId)
A B C
D E
 Un scenario u...
Changements culturels
 Petites équipes autonomes
 Décentralisation de la gouvernance
 Produits vs projets
Et ce n’est pas tout
 Transactions distribuées
 Operations de « undo » ?
 2 phase commit ?
 Sécurité
 centralisée au ...
Peler le monolithe…
Un scenario d’adoption heureux ?
Contexte
 Editeur de logiciels
 Produits (age 15 ans)
 ASP.NET WebForms, Framework 4
 Hébergement Cloud et On-Premise
...
Problème
 Monolithe
 Défauts de conception
 Problèmes de
performances
 Nb croissant d’incidents
client
 Perte de conn...
Architecture en place
Ged
Dématérialisation
de flux
Quel processus ?
1. Identification des domaines et
sous-domaine fonctionnels
2. Ecriture de tests fonctionnels
3. Automati...
Internet
UI
Service
Business
DAL
BD
Client
Internet
UI
Service
Business
DAL
BD
Client
Domaine 1
Domaine 2
Domaine 3
…
Internet
UI
Service
DAL
BD
Client
Domaine1Domaine2Domaine3
…
Service
Domaine 1
Internet
UI
Service
DAL
BD
Client
Domaine2Domaine3
…
Message
Broker
Domaine1
Log /Monitoring
Centralisé
...
Et avant …
 Formation technique
des développeurs
 Recrutement d’un chef
produit
 Culture DevOps
 Mise en place de
l’in...
Conclusion
Les microservices
 Composants
 Orienté Métier
 Produits pas Projets
 Services intelligents et
« plomberie » basique
 ...
Comparaison
 Simplicité
 Consistance
 Refactoring inter-
module
 Déploiement
 Disponibilité
 Frontières fortes
 Mul...
Les microservices
 C’est pas nouveau (peut-être un renouveau plus pragmatique de la SOA)
 Résout des problèmes mais ajou...
3 points importants
 Répondent à besoin de « Scalabilité »
 Approche intéressante dans la refonte d’un « monolithe »
 S...
Prochain SlideShare
Chargement dans…5
×

Architecture MicroServices - DotNetTlse

378 vues

Publié le

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

Publié dans : Ingénierie
  • Soyez le premier à commenter

Architecture MicroServices - DotNetTlse

  1. 1. Ionut Mihalcea – Effective Labs – @imihalceaMeet-up .Net Toulouse ARCHITECTURE MICROSERVICES
  2. 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. 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. 4. Existe t-il une définition pour les Architectures Microservices ? Réponse : Non !
  5. 5. Définition par opposition !  Monolithe  Microservices
  6. 6. Besoin : « Componentisation » des applications  Composant :  Changé indépendamment  Mis à jour indépendamment  Un problème déjà résolu :  Les librairies  IoC
  7. 7. Besoin : Scalabilité et maitrise des couts et délais de la mise en production  Monolythe
  8. 8. Besoin : Scalabilité et maitrise des couts et délais de la mise en production  Microservices
  9. 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. 10. Une vue de haut niveau https://martinfowler.com/articles/microservices.html
  11. 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. 12. Du moins quelques unes… Quels sont les difficultés ?
  13. 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. 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. 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. 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. 17. Changements culturels  Petites équipes autonomes  Décentralisation de la gouvernance  Produits vs projets
  18. 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. 19. Peler le monolithe… Un scenario d’adoption heureux ?
  20. 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. 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. 22. Architecture en place Ged Dématérialisation de flux
  23. 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. 24. Internet UI Service Business DAL BD Client
  25. 25. Internet UI Service Business DAL BD Client
  26. 26. Domaine 1 Domaine 2 Domaine 3 …
  27. 27. Internet UI Service DAL BD Client Domaine1Domaine2Domaine3 …
  28. 28. Service Domaine 1 Internet UI Service DAL BD Client Domaine2Domaine3 … Message Broker Domaine1 Log /Monitoring Centralisé DAL Domaine 1 BD
  29. 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. 30. Conclusion
  31. 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. 32. Comparaison  Simplicité  Consistance  Refactoring inter- module  Déploiement  Disponibilité  Frontières fortes  Multi-plateforme Monolithe Microservices
  33. 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. 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

×