Micro-services : tour d'horizon.

1. Micro-services

2. Applications monolithiques
Toutes les fonctionnalités dans un seul process….
Le scalling se fait en répliquant l’application complète
Sur plusieurs serveurs.

3. Griefs contre les applications monolithiques
Maitrise
fonctionnelle
Onboarding
des
ressources
Perte de
connaissance
métier
Difficulté à
Refactorer
Evolutivité
Migration
Couts de
recette
exponentiels
Baisse de
qualité
Moins en
moins de V.A
métier
Incapacité générale à répondre rapidement
et de façon pertinente aux besoins
Frein à l’innovation !!!

4. Applications monolithiques
Toutes les fonctionnalités dans un seul process….
Chaque fonctionnalité de l’application se traduit par
un service
Les services sont répliqués sur différents serveurs
En fonction des besoins.

5. Une définition des micro-services
Qu’est-ce qu’un microservice?

6. Les caractéristiques des micro-services
« Componentization» (Autonome / isolé)
Organisé autour de « business capabilities »
Elastique, Résiliant et « Responsive »
Orienté message et « Smart end points »
Configurable et automatisé
Gouvernance décentralisée et monitoring
intelligent

7. Organisé autour de business capabilities
UI specialist
Middleware
dba
Front

8. Organisé autour de business capabilities

9. Un principe de base fort
« You build it,
you deploy it,
you run it »

10. Data Management décentralisé
Front Front

11. Quelle est la taille d’un micro-service ?
« Quelle est la bonne
granularité ? »
2 équipes, 10 micro-services
10 équipes, 10 micro-services
10 équipes, 100 micro-services
2 équipes, 100 micro-services

12. Quelques idées reçues
1. Mon application est sur Docker donc elle est micro-service.
2. Les architectures micro-services vont résoudre tous mes problèmes.
3. Les applications monolithiques sont « has been ».
4. Les micro-services remplacent la SOA.

13. Une filiation avec la SOA ?
Qu’est-ce que
SOA ?
Capacité d’une application à exposer ses
fonctionnalités sous forme de services (web),
découvrables et consommables ?
Bus de service (ESB) centralisé dans lequel
beaucoup (trop) de règles métiers ont été codées
et qui est une étape indispensable à la
consommation/ exposition d’un service ?
Micro-services
»

14. Concrètement
A quoi cela ressemble ?

15. Architecture en couches

16. Architecture d’un micro-service

17. API
 Qui dit micro-service, dit API !
 2 API :
 API public pour communiquer avec le « monde extérieur »
 API privée dite admin pour administrer, paramétrer le service
 Deux techniques pour requêter un service :
 GetProfilesById
 GET http://myapi.looksfamiliar.com/profiles/user/id/99999
 GetProfilesByLocation
 GET http://myapi.looksfamiliar.com/profiles?location=Massachusetts

18. Un exemple ?
• Connaissez-vous une plateforme écrite sous forme de microservices ?

19. Comment y aller ?

20. Approche bottom-up
La principale
erreur est de
commencer
avec les micro-
services

21. Démarche de transition Top - Down
Source : Xebia NL

22. Démarche itérative
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande

23. Démarche itérative
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande

24. Les challenges
Tout n’est pas si simple….

25. Montée de version / Upgrade
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande
V1
V1
V1

26. Montée de version / Upgrade
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande
V1
V1
V2
Deploy V2

27. Montée de version / Upgrade
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande
V2
V1
V2
Deploy V2
Upgrade V2

28. Montée de version / Upgrade
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande
V2
V2
V2
Deploy V2

29. Solution : Gatekeper
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande
/Products
/Products/Id
/Bulk_add

30. Déploiements
Service A
Service B
Service C – v1
v1
v1

31. Déploiements
Service A
Service B
Service C – v2
v1
v1
Deploy V2

32. Solution : Semantic Versioning
Service A
Service B
Service C – v1.2
v1
v1
Deploy V1.2
Pas de rupture côté interface

33. Solution : Semantic Versioning
Service A
Service B
Service C – v1.2
v1
v1
Deploy V2
Service C – v2

34. Solution : Semantic Versioning
Service A
Service B
Service C – v1.2
v1
v2
Deploy V2
Service C – v2

35. Solution : Semantic Versioning
Service A
Service B
Service C – v1.2
v2
v2
Deploy V2
Service C – v2

36. Montée en charge

37. Montée en charge
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande

38. Solution : amortissement via queues

39. Solution : Queue / Asynchronisme
Site eCommerce
Catalogue
Tunnel Commande
Client
Commande
Worker

40. Configuration Management

41. Solution : Discovery Service

42. Solution : Discovery Service

43. Enfer du débugging

44. Enfer du débugging

45. Solution : Correlation ID

46. Solution : Correlation ID
1. Tagguer avec un ID tous les messages entrants
2. Le service enregistre l’ID
3. L’ID est transmis au service de logs
4. Tagguer toute nouvelle requête avec cet ID

47. Les bouchons (Mocks)

48. Les bouchons (Mocks)

49. Mock : le service fournit le bouchon

50. Mock : Le service possède un client

51. Multi-techno / Multi-plateform

52. En synthèse

53. Du monolithe aux micro-services
En ai-je
vraiment
besoin ?
Mon
organisation
est-elle
mature ?
Mon infra et
mes
pratiques
logicielles
sont-elles
matures ?

54. API
Service
Cache
DB
API
Service
Cache
DB
API
Service
Cache
DB
API Management
API
Service
Cache
DB
Service bus
Protocole AMQP
User Interface (ISIS Web 2)
Queues
Pub/SubSynchronous
Asynchronous
External Network
ISIS Open
Data
REST / JSON REST / JSON
SOAP / WCF REST / JSON
SignalR
Un exemple d’application

55. Quelques solutions

56. Infrastructure et plateforme
 Docker extensions pour les VM Linux
 Azure Container Service : simplifier la création /
configuration, la gestion de cluster de VM Azure pour
des applications containerisés.
 Apache Mesos ou Docker Swarm pour l’orchestration
des applications.

57. Cloud Services et App Services

58. Azure Service Fabric
 Plateforme distribuée pour
développer, packager, déployer,
hoster, gérer des micro-services pour
des applications à grande échelle.
 Fournit également un Framework
pour coder/packager les micro-
services (afin de profiter pleinement
des capacités offertes par la
plateforme).
 Services stateless / statefull.
 Multi-langage : ASP.NET, Node Js,
 Plateforme éprouvé car services Azure sont basés dessus.

59. States dans Azure Service Fabric

60. Conclusion
En ai-je
vraiment
besoin ?
Mon
organisation
est-elle
mature ?
Mon infra et
mes
pratiques
logicielles
sont-elles
matures ?