1.
34 AVENUE DE L'OPÉRA > 75002 PARIS > FRANCE > WWW.OCTO.COM

2.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
SERVICE MESH : NOTRE DÉFINITION
Composant d’infrastructure prenant en charge l’interconnexion
et la gestion d’une architecture de services à large échelle
Il peut proposer des fonctions avancées comme le load
balancing, la résilience, l’accès aux services, l’observabilité, la
sécurité...

3.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
MICROSERVICES : NOTRE DÉFINITION
Bonne application du pattern SOA avec, quelquefois, une
organisation du support en production sur un principe simple :
“You build it, you run it”
Le principe “You build it, you run it” n’est pas toujours
applicable dans nos SI franco-français

4.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
QUEL LIEN AVEC LES FRAMEWORKS D’ENTREPRISE ?
Les composants ont majoritairement débuté comme frameworks
chez les géants du Web
La communauté Open Source s’est approprié ces composants
et les fait évoluer librement
La philosophie d’autonomie des microservices est à conjuguer
avec les besoins de rationalisation à l’échelle de l’entreprise

5.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
Avec le déploiement des service meshes au sein de nos SI,
pour couvrir les mêmes besoins d’antan, va-t-on assister à
un (grand) retour des frameworks d’entreprise ?

6.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
NOTRE VISION DES FRAMEWORKS D’ENTREPRISE
Un ensemble cohérent
d’éléments permettant
de bâtir des logiciels
d’entreprise avec un
objectif essentiel
“plus vite, mieux et
moins cher dans la
durée”
ESB
Serveurs
d’apps
ETL
Repackaging de
frameworks open
source
EAI
Rules engine
BPM
TOGAF
CMMI
fr.magrandebanque.fwk

7.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
QUELLES EN ÉTAIENT LES PRINCIPALES DOULEURS ?
Évolutions plus lentes que tout ce qui est librement disponible sur Internet
◉ Arbitrage de budget & Compétences
Consanguinité des équipes
◉ Progression limitée sans apport de sang neuf
Organisation en centre de services inadaptée au développement des applications
◉ Exemple des EAI, ESB...
Couplage des cycles de vie des applications et du framework
◉ Synchronisation des montées de versions
◉ Complexité du multi-langage
Performance et disponibilité pas toujours au rendez-vous

8.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
DÉPLOIEMENT DES MICROSERVICES : A L’ORIGINE - V1
Les applications embarquent des librairies dont elles restent dépendantes
App A
- Business logic
Library v1
- Service discovery
- Circuit breaker
- Routing
- Throttling
App B
Library
v1
...
App A
Library
v1
App C
Library
v2
App C
Library
v2
Registry

9.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
LES ENSEIGNEMENTS DES MICROSERVICES V1
Socle logiciel sur lequel l’entreprise bâtit ses logiciels
◉ Utilisation et packaging avec le code applicatif
◉ Autonomie de chaque service
Faire évoluer ce socle est difficile
◉ Maîtrise indispensable
◉ Couplage fort aux applications et aux langages
App A
- Business logic
Library v1
- Service discovery
- Circuit breaker
- Routing
- Throttling

10.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
LES LIMITATIONS DES DÉPLOIEMENTS V1
L’augmentation du nombre de microservices amène des problèmes d’échelle
◉ Augmentation de la complexité des développements
◉ Difficulté accrue du debugging en cas d’incident
◉ Couplage et intrusion des frameworks utilisés dans des applications hétérogènes
Avant Après

11.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
La conteneurisation est un levier majeur
pour la gestion d’applications à grande échelle,
et s’appuie sur les patterns des applications “cloud native”
MICROSERVICES V2 : CONTENEURISATION ET APPLICATIONS CLOUD NATIVE
Docker Kubernetes
12-Factor
App

12.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
SERVICE MESH : PRINCIPES DE FONCTIONNEMENT
Sidecar
Front
App
Container
Injection d’un proxy
sidecar à proximité
des containers
applicatifs
Proxy sidecar
compatible avec tous
les langages
Requête
entrante
Sidecar
App A
Container
Sidecar
App B
Container
Sidecar
App A
Container
Sidecar
App C
Container

13.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
ANATOMIE D’UN SERVICE MESH
Data Plane
Control Plane
Proxies de médiation &
Génération des métriques
Gestion de la
Configuration

14.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
EXEMPLE D’ARCHITECTURE DE SERVICE MESH : ISTIO
Data
Plane
Control
Plane
Pilot Mixer Citadel
Sidecar
Front
App
Container
Requête
entrante
Sidecar
App A
Container
Sidecar
App C
Container
ISTIO
TLS
certs
Policy
checks
TelemetryDiscovery
Config

15.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
PEU D’IMPLÉMENTATIONS DE SERVICE MESHES
Istio
fr.magrandenanque.fwk

16.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
EXEMPLE DE DÉPLOIEMENT
21 lignes de configuration
du déploiement
130 lignes de configuration
du déploiement
kubectl apply -f <(istioctl kube-inject
-f jira-deployment.yml)
containers:
- image: jira:7.13.0
name: jira
- args:
- proxy
- sidecar
- --discoveryAddress
- istio-pilot.istio-system:15007
- --zipkinAddress
- zipkin.istio-system:9411
- --proxyAdminPort
- "15000"
- --controlPlaneAuthPolicy
SourceCible

17.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
LE DÉPLOIEMENT EST-IL AISÉ ?
Istio
Kubernetes
Certaines fonctions simples sont déjà proposées par Kubernetes
Les cas d’usage avancés requièrent toutefois un service mesh
La maîtrise des composants est primordiale vu leur niveau de
maturité hétérogène et la potentielle complexité

18.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
SERVICE MESH : RÉELLE NOUVEAUTÉ OU FRAMEWORKS CONTRAIGNANTS ?
Un changement de paradigme sur la nature des solutions
Réelle nouveauté pour répondre aux mêmes problématiques qu’avant
avec une approche résolument différente
◉ Couplage réseau/service moins intrusif, applicable à tous les containers quel
que soit leur langage de développement
◉ Solutions éprouvées parce qu’open source et portées par les géants du Web
◉ Nécessité d’adopter une orientation “cloud native”
Années 2000 Aujourd’hui
Dev Ops Dev Ops

19.
#LaDuckConf by OCTO Technology © 2019 - All rights reserved
TAKEAWAY
Pas de grande similitude entre Service mesh et framework
d’entreprise
◉ Adhérer à un standard de fait du marché permet de ne pas payer le
surcoût d’une solution “maison”
◉ Pas besoin d’équipe spécialisée de développement
◉ Développer suivant les patterns “cloud native” est nécessaire et
suffisant
Déployer les service meshes peut se faire de manière progressive
et sans grande contrepartie
◉ Vous pourrez revenir en arrière, à coût maîtrisé, si vous le souhaitez
◉ Le ticket d’entrée lorsque vous maîtrisez une stack complète telle
que Kubernetes est minime