MicroservicesVue d’ensemble

Speaker

https://github.com/migibert

https://galaxy.ansible.com/migibert

https://twitter.com/migibert

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

ServiceService

Service

Service

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

ServiceService

Service

Service

Bus

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

ServiceService

Service

Service

Bus

ConceptsGarder l’intelligence aux extrémités

BPM / ESB / EAIRevenir aux fondamentaux du web et éviter l’intelligence dans les couches de transportUtiliser des services de plus haut niveau pour gérer l’orchestration

Design for failureMonolithe peu sujet à la panne mais quand elle survient…Focaliser sur la résilience du systèmeNouveaux outils, nouvelles pratiques, nouvelle culture

Scaler grâce au modèle de processusServeur d’applications / 1 machine par serviceUn service = un processusLa plateforme doit être capable de gérer intelligemment les ressources

Ce qui changeLes 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

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

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

De nouveaux outils - Configuration store

ServerConfiguration

storeConfigurationService

ServerConfigurationService

ServerService

ServerService

Configuration store

Server

Service

Server

Service

Agent

Agent

De nouveaux outils - Service Discovery

UDDI

Server Server Service Discovery

Service Service

Server Server

Service Service

Configuration store

REST DNS

REST

De nouveaux outils - Load Balancing

Load Balancer

VM VM

Service DiscoveryService Service

Load Balancer

VM VM

Service Service

Configuration daemon

Configuration store

REST REST DNS

De nouveaux outils – API Gateway

Service Discovery

VM

Configuration store

REST REST DNS

API Gateway

Service Service

VM

Service Service

VMServiceService

VMServiceService

AuthenticationSecurity Traffic control

Monitoring

Questions

BonusService scaling : PaaS, Marathon, Kubernetes, Swarm, NomadService Discovery : Consul, Eureka, SkyDNS, SmartStackConfiguration Store : etcd, zookeeper, consulConfiguration daemon : consul-template, confdMessage Bus: RabbitMQ, ZeroMQ, KafkaAPI Gateway: Zuul, Tyk, Kong, Nginx plusMonitoring:

Log management: Elastic Search, Logstach, Fluentd, Kibana, SplunkMetric management: Telegraf, Collectd, InfluxDB, OpenTSDB, Graphite, Grafana