Premier meetup du groupe Paris Innovation & new tech autour des problématiques posées par les microservices.
Talk architecture : Distributed Key/Value store, Service Discovery, Automated configuration, API management, development pattern deployment patterns.
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
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
Notes de l'éditeur
Lien avec francois : les microservices on sait ce que c’est, on sait pourquoi en faire, mais pour les architectes, developpeurs, exploitation, qu’est ce que ca change ?
Dev java qui s’est passionné pour le cloud, a travaillé dans le cloud et y a découvert la culture devops et les outils d’IaC et de CM
Archi classique WOA (REST SOA)
Event sourcing (EDA) + asynchronisme : messages comme interfaces = souplesse (approches réactives)
Exemple Ingenico / LinkedIn
Exemple Openstack
Design for failure: les monolithes sont moins sujets à la panne mais leurs impacts sont énormes
Monitoring réactif = actions correctives automatisées sur détection de panne (un service répond lentement et a un uptime de - de 1j => désactivation du service)
Gestion des ressources = utiliser au mieux les ressources disponibles (plusieurs services / machines)
Blue Green : validation sur l’environnement offline, si ok routage vers le nouvel env, sinon pas de changement
Canary release : Ajout d’un nouveau service à côté des anciens pour analyser son comportement en situation réelle
Dark launching : Analyse les impacts des features en cours de dev sur le système actuel
Blue Green : validation sur l’environnement offline, si ok routage vers le nouvel env, sinon pas de changement
Canary release : Ajout d’un nouveau service à côté des anciens pour analyser son comportement en situation réelle
Dark launching : Analyse les impacts des features en cours de dev sur le système actuel
Configuration Store : Distributed Key Value Store (CA du CAP theorem) : peu performant mais très robuste et distribuable
CAP theorem = Consistency / Availability / Partition tolerance
Service Discovery : Enregistre les services et maintient les infos sur leur état de santé dans le configuration store (interfaces REST + DNS SRV record)
Configuration daemon remplit un template à partir des données du configuration store puis recharge le service (haproxy/apache/nginx reload par exemple)
Configuration daemon remplit un template à partir des données du configuration store puis recharge le service (haproxy/apache/nginx reload par exemple)
Reactive pattern : automated corrective action on failure detection (décommissionnement d’une VM + création et installation nouvelle VM avec service)
Reactive pattern : automated corrective action on failure detection (décommissionnement d’une VM + création et installation nouvelle VM avec service)