The Doppler Quarterly (FRANÇAIS) Printemps 2018 | Page 67

téressant »), dont la fonction est d’associer une intention, laquelle déclenche une
fonction qui implémente la sélection d'une citation aléatoire et renvoie au final une
directive vocale à Alexa. Cette fonction peut être associée à AWS Lambda par le
biais d'un nom de ressource Amazon (ARN). AWS Lambda étant un service facturé
à l'usage (dans lequel vous ne payez que ce que vous utilisez), son exploitation est
beaucoup plus rentable pour l’exécution de vos compétences Alexa qu'une mise en
œuvre effectuée dans une instance EC2 réservée.
À la base, une architecture sans serveur se compose de quelques fonctions
spécifiques au langage qui sont lancées à la demande, planifiées, exécutées et ter-
minées. L'architecture sans serveur est présentée comme un moyen post-VM et
post-conteneur de construire et déployer des applications, mais même les fonctions
Serverless doivent être exécutées sur une plateforme, et cela tombe bien, puisqu'il
existe pour cela Kubernetes ! En fait, il existe au moins deux projets open-source
qui utilisent K8s comme plateforme sous-jacente pour le sans-serveur : Kubeless et
Fission. Le projet Fission est un excellent exemple de la manière dont K8s peut être
utilisé pour l’architecture sans serveur. Fission se compose d’un serveur d’API, d'un
routeur de services, d'un gestionnaire de pool et d'un ensemble de Pods fonction-
nels disposés en couches complémentaire dans K8s (voir Figure 4). Fission gère un
pool de fonctions d'hébergement de Pods chargées dans Fission. Le contrôleur
assure le suivi des fonctions et gère les déclencheurs d’événements et images de
conteneurs configurés via des fonctions définies. Le gestionnaire de pool permet
d'administrer un ensemble de conteneurs en vue d’exécuter des fonctions. Le ges-
Requêtes HTTP
Interface
CLI de
Fission
Contrôleur
poolmgr
Routeur
...
Pods
Pods fonctionnels
« génériques » « spécifiques »
Figure 4 : Fission — Fonctions sans serveur pour Kubernetes
tionnaire de pool maintient ces conteneurs à l'état «  tiède  » et les planifie à la
demande lorsqu'ils sont déclenchés par des événements spécifiques. Le routeur
reçoit les requêtes HTTP et les transmet au Pod fonctionnel approprié, en deman-
dant à ce qu'un Pod soit planifié par le gestionnaire de pool si nécessaire. Le ges-
tionnaire de pool est crucial dans Fission, car il permet à une fonction de s'exécuter
avec un temps de démarrage quasi-instantané, ce qui évite le temps de latence dû
au chargement des conteneurs.
PRINTEMPS 2018 | THE DOPPLER | 65