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