Le document traite des architectures de microservices, expliquant les approches synchrones et asynchrones pour la communication entre services, ainsi que les défis associés, tels que la gestion de l'adresse des services et la haute disponibilité. Il met en lumière la nécessité d'une conception axée sur la résilience, la dynamique des services, et l'importance des outils modernes pour le déploiement, la découverte de services, et la gestion des configurations. Enfin, il aborde de nouveaux modèles et pratiques pour assurer un fonctionnement robuste et scalable des applications distribuées.

1. Microservices
Vue d’ensemble

2. Speaker
https://github.com/migibert
https://galaxy.ansible.com/migibert
https://twitter.com/migibert

3. Architectures de référence - synchrone
• Les services communiquent entre eux en REST
• Problématiques :
• Comment connaître l’adresse des services dont l’on dépend au runtime ?
• Que se passe-t-il si un service ne répond plus ou trop lentement ?
• Comment informer le load balancer de la disponibilité de nouveaux services ?
• Comment les services connaissent ils l’emplacement de sa (ses) base(s) ?
UI
Service
Service
Service
Service
Service

4. Architectures de référence - asynchrone
• Les services communiquent entre eux via un bus de messages
• Problématiques :
• Comment connaître l’adresse du bus au runtime ?
• Gérer la haute disponibilité et la sécurité du bus
• Comment gérer le versioning des services et le routage des messages ?
UI
Service
Service
Service
Service
Service
Bus

5. Architectures de référence - hybride
• Les services communiquent entre eux via REST et un bus de messages
• Opérations peu coûteuses réalisées par appels directs (synchrones)
• Opérations coûteuses réalisées par appels indirects (asynchrones)
UI
Service
Service
Service
Service
Service
Bus

6. Concepts
Garder l’intelligence aux extrémités
BPM / ESB / EAI
Revenir aux fondamentaux du web et éviter l’intelligence dans les couches de transport
Utiliser des services de plus haut niveau pour gérer l’orchestration
Design for failure
Monolithe peu sujet à la panne mais quand elle survient…
Focaliser sur la résilience du système
Nouveaux outils, nouvelles pratiques, nouvelle culture
Scaler grâce au modèle de processus
Serveur d’applications / 1 machine par service
Un service = un processus
La plateforme doit être capable de gérer intelligemment les ressources

7. Ce qui change
Les services sont plus petits mais (beaucoup) plus nombreux
• Industrialisation du cycle de développement (CI / CD)
• Ils évoluent plus vite, le versioning est indispensable (cohabitation)
• Tester des concepts devient plus aisé (A/B testing)
Le système devient plus distribué
• Une gestion intelligente des ressources est indispensable
• Les défaillances sont inévitables et les latences sont partout (encore plus à l’ère du cloud)
• Le monitoring réactif devient une nécessité
Le système devient dynamique
• Des services naissent et meurent en permanence
• Il faut être capable de modifier le comportement des applications au runtime
• On ne peut pas se passer de logs agrégés car les services sont éphémères

8. Design for failure – Du produit à la plateforme
• L’environnement devient mouvant
• Les services doivent être capables de s’y adapter automatiquement
• La plateforme doit gérer le scaling / l’autoscaling
• Les services ajoutés à la volée doivent être monitorés
• Les logs des services supprimés / tombés doivent rester disponibles
• Les performances doivent être mesurées en permanence (APM)
• De nouveaux enjeux de testing:
• Les tests fonctionnels assurent que le service est rendu au client
• Les tests de résilience assurent que les services sont tolérants à la panne

9. Design for failure – de nouveaux patterns
• De nouveaux patterns pour gérer la tolérance aux pannes
• Healthchecking : Publier son état de santé
• Graceful degradation : Offrir un mode dégradé
• Circuit breaker : Limiter les échecs en cascade
• Toggle feature : Gérer l’activation des fonctionnalités
• De nouveaux patterns de déploiement (Zero Downtime)
• Blue Green deployment : Duplication de l’environnement
• Dark Launching : Déploiement de fonctionnalités non terminées (mais désactivées)
• Canary Release : Ajout d’un nouveau service à côté des anciens pour analyser son
comportement en situation réelle

10. De nouveaux outils - Configuration store
Server
Configuration
store
ConfigurationService
Server
ConfigurationService
Server
Service
Server
Service
Configuration
store
Server
Service
Server
Service
Agent
Agent

11. De nouveaux outils - Service Discovery
UDDI
Server Server Service Discovery
Service Service
Server Server
Service Service
Configuration store
REST DNS
REST

12. De nouveaux outils - Load Balancing
Load Balancer
VM VM
Service Discovery
Service Service
Load Balancer
VM VM
Service Service
Configuration
daemon
Configuration
store
REST REST DNS

13. De nouveaux outils – API Gateway
Service Discovery
VM
Configuration
store
REST REST DNS
API Gateway
Service Service
VM
Service Service
VM
ServiceService
VM
ServiceService
AuthenticationSecurity Traffic
control
Monitoring

14. Questions

15. Bonus
Service scaling : PaaS, Marathon, Kubernetes, Swarm, Nomad
Service Discovery : Consul, Eureka, SkyDNS, SmartStack
Configuration Store : etcd, zookeeper, consul
Configuration daemon : consul-template, confd
Message Bus: RabbitMQ, ZeroMQ, Kafka
API Gateway: Zuul, Tyk, Kong, Nginx plus
Monitoring:
Log management: Elastic Search, Logstach, Fluentd, Kibana, Splunk
Metric management: Telegraf, Collectd, InfluxDB, OpenTSDB, Graphite, Grafana