SlideShare une entreprise Scribd logo
1  sur  15
Microservices
Vue 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
Service
Service
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
Service
Service
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
Service
Service
Service
Service
Bus
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
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
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
Server
Configuration
store
ConfigurationService
Server
ConfigurationService
Server
Service
Server
Service
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 Discovery
Service 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
VM
ServiceService
VM
ServiceService
AuthenticationSecurity Traffic
control
Monitoring
Questions
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

Contenu connexe

Similaire à Paris Innovation & New tech - Meetup #1 - Microservices

Introduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaSIntroduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaSGerard Konan
 
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private CloudLe Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private CloudMicrosoft Technet France
 
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...Amazon Web Services
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfFootballLovers9
 
Boostez vos applications en migrant vos bases vers SQL Server 2012 !
Boostez vos applications en migrant vos bases vers SQL Server 2012 !Boostez vos applications en migrant vos bases vers SQL Server 2012 !
Boostez vos applications en migrant vos bases vers SQL Server 2012 !Microsoft Technet France
 
Azure Service Fabric pour les développeurs
Azure Service Fabric pour les développeursAzure Service Fabric pour les développeurs
Azure Service Fabric pour les développeursMicrosoft
 
Xebicon architectures microservices azure v1.0
Xebicon   architectures microservices azure v1.0Xebicon   architectures microservices azure v1.0
Xebicon architectures microservices azure v1.0Michel HUBERT
 
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAmazon Web Services
 
Architectures microservices
Architectures microservicesArchitectures microservices
Architectures microservicesRiadh MNASRI
 
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...Christophe Furmaniak
 
Migrez vos bases de données vers SQL Server et SQL Azure avec Microsoft SQL S...
Migrez vos bases de données vers SQL Server et SQL Azure avec Microsoft SQL S...Migrez vos bases de données vers SQL Server et SQL Azure avec Microsoft SQL S...
Migrez vos bases de données vers SQL Server et SQL Azure avec Microsoft SQL S...Microsoft Technet France
 
XebiCon'16 : Architecture MicroServices avec Azure par Michel Hubert, CTO de ...
XebiCon'16 : Architecture MicroServices avec Azure par Michel Hubert, CTO de ...XebiCon'16 : Architecture MicroServices avec Azure par Michel Hubert, CTO de ...
XebiCon'16 : Architecture MicroServices avec Azure par Michel Hubert, CTO de ...Publicis Sapient Engineering
 
Introduction à Cloud Foundry Journée du Code 2017
Introduction à Cloud Foundry Journée du Code 2017Introduction à Cloud Foundry Journée du Code 2017
Introduction à Cloud Foundry Journée du Code 2017Gerard Konan
 
Automatisez progressivement vos releases
Automatisez progressivement vos releasesAutomatisez progressivement vos releases
Automatisez progressivement vos releasesXebiaLabs
 
Quelles architectures pour vos applications Cloud, de la VM au conteneur : ça...
Quelles architectures pour vos applications Cloud, de la VM au conteneur : ça...Quelles architectures pour vos applications Cloud, de la VM au conteneur : ça...
Quelles architectures pour vos applications Cloud, de la VM au conteneur : ça...Microsoft
 
Webinar XL Release in French - November 2016
Webinar XL Release in French - November 2016Webinar XL Release in French - November 2016
Webinar XL Release in French - November 2016XebiaLabs
 
eServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementeServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementLilia Sfaxi
 
Cellenza microservices - tour d'horizon - v0.1
Cellenza   microservices - tour d'horizon - v0.1Cellenza   microservices - tour d'horizon - v0.1
Cellenza microservices - tour d'horizon - v0.1Radoine Douhou
 
Conférence AFUP 20minutes.Fr
Conférence AFUP 20minutes.FrConférence AFUP 20minutes.Fr
Conférence AFUP 20minutes.FrOxalide
 

Similaire à Paris Innovation & New tech - Meetup #1 - Microservices (20)

Introduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaSIntroduction à Cloud Foundry et au PaaS
Introduction à Cloud Foundry et au PaaS
 
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private CloudLe Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
Le Cloud Privé, de la théorie à la réalité avec Microsoft Private Cloud
 
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
AWS Summit Paris - Track 4 - Session 2 - Migration Cloud, modernisation des a...
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdf
 
Boostez vos applications en migrant vos bases vers SQL Server 2012 !
Boostez vos applications en migrant vos bases vers SQL Server 2012 !Boostez vos applications en migrant vos bases vers SQL Server 2012 !
Boostez vos applications en migrant vos bases vers SQL Server 2012 !
 
Azure Service Fabric pour les développeurs
Azure Service Fabric pour les développeursAzure Service Fabric pour les développeurs
Azure Service Fabric pour les développeurs
 
Xebicon architectures microservices azure v1.0
Xebicon   architectures microservices azure v1.0Xebicon   architectures microservices azure v1.0
Xebicon architectures microservices azure v1.0
 
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWSAWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
AWS Paris Summit 2014 - T4 - Créez votre PaaS avec AWS
 
Architectures microservices
Architectures microservicesArchitectures microservices
Architectures microservices
 
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
Prez -chtijug-29032016-(micro)services, loadbalancing et gestion des erreurs ...
 
Migrez vos bases de données vers SQL Server et SQL Azure avec Microsoft SQL S...
Migrez vos bases de données vers SQL Server et SQL Azure avec Microsoft SQL S...Migrez vos bases de données vers SQL Server et SQL Azure avec Microsoft SQL S...
Migrez vos bases de données vers SQL Server et SQL Azure avec Microsoft SQL S...
 
XebiCon'16 : Architecture MicroServices avec Azure par Michel Hubert, CTO de ...
XebiCon'16 : Architecture MicroServices avec Azure par Michel Hubert, CTO de ...XebiCon'16 : Architecture MicroServices avec Azure par Michel Hubert, CTO de ...
XebiCon'16 : Architecture MicroServices avec Azure par Michel Hubert, CTO de ...
 
Introduction à Cloud Foundry Journée du Code 2017
Introduction à Cloud Foundry Journée du Code 2017Introduction à Cloud Foundry Journée du Code 2017
Introduction à Cloud Foundry Journée du Code 2017
 
Automatisez progressivement vos releases
Automatisez progressivement vos releasesAutomatisez progressivement vos releases
Automatisez progressivement vos releases
 
Quelles architectures pour vos applications Cloud, de la VM au conteneur : ça...
Quelles architectures pour vos applications Cloud, de la VM au conteneur : ça...Quelles architectures pour vos applications Cloud, de la VM au conteneur : ça...
Quelles architectures pour vos applications Cloud, de la VM au conteneur : ça...
 
Webinar XL Release in French - November 2016
Webinar XL Release in French - November 2016Webinar XL Release in French - November 2016
Webinar XL Release in French - November 2016
 
eServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API ManagementeServices-Chp5: Microservices et API Management
eServices-Chp5: Microservices et API Management
 
Retour d'experience projet AngularJS
Retour d'experience projet AngularJSRetour d'experience projet AngularJS
Retour d'experience projet AngularJS
 
Cellenza microservices - tour d'horizon - v0.1
Cellenza   microservices - tour d'horizon - v0.1Cellenza   microservices - tour d'horizon - v0.1
Cellenza microservices - tour d'horizon - v0.1
 
Conférence AFUP 20minutes.Fr
Conférence AFUP 20minutes.FrConférence AFUP 20minutes.Fr
Conférence AFUP 20minutes.Fr
 

Paris Innovation & New tech - Meetup #1 - Microservices

  • 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

  1. 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 ?
  2. 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
  3. Archi classique WOA (REST SOA)
  4. Event sourcing (EDA) + asynchronisme : messages comme interfaces = souplesse (approches réactives) Exemple Ingenico / LinkedIn
  5. Exemple Openstack
  6. Design for failure: les monolithes sont moins sujets à la panne mais leurs impacts sont énormes
  7. 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)
  8. 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
  9. 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
  10. Configuration Store : Distributed Key Value Store (CA du CAP theorem) : peu performant mais très robuste et distribuable CAP theorem = Consistency / Availability / Partition tolerance
  11. Service Discovery : Enregistre les services et maintient les infos sur leur état de santé dans le configuration store (interfaces REST + DNS SRV record)
  12. Configuration daemon remplit un template à partir des données du configuration store puis recharge le service (haproxy/apache/nginx reload par exemple)
  13. Configuration daemon remplit un template à partir des données du configuration store puis recharge le service (haproxy/apache/nginx reload par exemple)
  14. Reactive pattern : automated corrective action on failure detection (décommissionnement d’une VM + création et installation nouvelle VM avec service)
  15. Reactive pattern : automated corrective action on failure detection (décommissionnement d’une VM + création et installation nouvelle VM avec service)