Logo d'OpenWhisk

Introduction

Sujet : OpenWhisk
Auteur : Servan CHARLOT
Mail : servan.charlot@etu.univ-grenoble-alpes.fr
Démo

Résumé

OpenWhisk est une technologie serverless open source. Elle permet d'envoyer des programmes sur le cloud sous forme d'actions. Ces actions seront exécutées plus tard par des requêtes HTTP ou des éventements (comme des changements sur des bases de données ou des notification GitHub). Cela permet d’éviter de mettre en place un serveur sois même, réduisant entre autres les coûts et la gestion opérationnelle. L’inconvénient est que l'on est dépendant du vendeur qui héberge nos actions, ce qui est un problème si il augmente ses prix ou fixe de nouvelles limites.

Mots-clé : OpenWhisk, serverless, cloud,

Abstract

OpenWhisk is an opensource serverless technology which allows developers to deploy programs on the could. Those programs, also named actions, can be triggered at anytime with a HTTP request or different events (such as changes in a database or GitHub notifications). Thanks to this, there is no need to set up a server, reducing management and operational costs. But there is still drawbacks, like vendor dependency, forcing you to cope with unexpected price changes or new limits.

Keywords: Openwhisk, serverless, cloud.

Synthèse

Description

Architecture OpenWhisk

OpenWhisk est une technologie open source qualifiée de plateforme de calcul événementielle et distribuée, aussi appelée serverless, ou FaaS, Function as a Service. Elle s'exécute en local, ou plus généralement sur le could. Elle permet d'y envoyer des programmes sous forme de fonction, appelés Actions. Ces actions seront par la suite exécutées en réponse à un événement ou à une requête HTTP.

De nombreux langages de programmation sont supportés comme par exemple NodeJS, Swift, Java, Scala, Go, PHP, Python et Ruby. Si l'action à créer n'est développée avec aucun de ces langages, il est toujours possible de faire un exécutable personnalisé qui sera exécuté dans l'environnement Docker, avec le Docker SDK.

Ces actions peuvent ensuite travailler de concert avec de nombreuses applications pour recevoir des événements ou envoyer des résultats. On peut citer les files de messages Kafka, les bases de données Cloudant, les notifications Slack et flux RSS, les pipelines GitHub, JIRA, des capteurs sur des objets connectés, ou des services de données comme IBM Watson ou Weather Company.

Les actions sont déployées instantanément et sont appelées lorsque un événement se présente. Elles peuvent êtres exécutées n'importe quand, une ou plusieurs centaines de fois. L'espace qui leur est alloué dépends de la demande, et les frais sont en conséquence des appels, donc on ne paye que pour ce que l'on utilise.

Ces actions peuvent ensuite êtres mises à la suite pour créer des compositions, ou chaque action renvoie son résultat à la suivante dans la chaîne. C'est un moyen de combiner plusieurs technologies et langages dans le même exécution très facilement.

Fonctionnement

Fonctionnement d'OpenWhisk

Si on regarde un peu plus en détails le fonctionnement d'OpenWhisk on se rends compte qu'elle fait appelle a d'autres technologies pour fonctionner : Nginx, Kafka, Docker et CouchDB.

Partons de principe que l'action est déjà crée. (Pour voir comment créer une action et l'utiliser se référer à la démo). Voyons se qu'il se passe en interne lorsque cette action est appelée par une requête HTTP.

La requête HTTP arrive dans le serveur proxy Nginx, qui s'occupe de la sécurité de la couche transport (SSL) et qui transmet le requête au contrôleur.

Le contrôleur sert d'interface à tout ce que l'utilisateur peut faire. Ici il comprend que l'on veux invoquer une action. Il vérifie d'abord que l'on sois bien identifié et que l'on a le droit de faire ce que l'on demande, en comparant notre profil avec les profils présents dans l'instance de base de donnée CouchDB.

Si tout est en ordre, l'action demandée est chargée depuis cette même base. Elle contient le code à exécuter et ses paramètres par défaut, qui sont fusionnés avec les paramètres de notre requête HTTP. Elle contient aussi des informations sur les restrictions à l'exécution, comme la quantité de mémoire qu'elle peut utiliser.

Le contrôleur fait ensuite appel à son load balancer qui va devoir décider où exécuter l'action. Les exécuteurs sont appelés des Invokers, et un de ceux disponibles sera choisit pour invoquer l'action demandée.

Pour éviter les soucis de surcharge mémoire dans le cas où tous les exécuteurs sont utilisés, les contrôleur et les invokers sont reliés à une file d'attente Kafka. Lorsque la requête arrive dans Kafka, un ActivationID est créé et envoyé à l'utilisateur. Il sera utilisé ultérieurement pour avoir accès aux résultats.

Lorsque l'invoker sélectionné par le load balancer se libère, Kafka relâche la requête et notre action peut alors s'exécuter, et ce de manière isolée et sécurisée dans un environnement Docker. Pour chaque action, un conteneur Docker est créé, elle s'exécute à l'intérieur, on récupère le résultat et le conteneur est détruit.

Le résultat est stocké dans la base de données CouchDB, renseigné par son ActivationID dont on a parlé plus haut. L'utilisateur peut ensuite le récupérer via une API REST.

Cas d'utilisation

La technologie OpenWhisk est utilisée dans différents cas ou il est intéressant d'avoir une architecture serverless:

Les microservices : Ils est difficile de construire des microservices sur des architectures classiques. De plus cela permet aux petites équipes de gagner du temps en évitant les complexités opérationnelles et d'infrastructure. Chaque action est déployée indépendamment et elles sont connectés entre elles grâce aux compositions d'OpenWhisk.
Les applications web : Elles peuvent être entièrement construite autour de fichiers statiques pour la gestions des ressources, et d'API serverless pour les événements et requêtes.
L'internet des objets (IoT) : Dans l'IoT, il y a une grand variété de pipelines et peu de standards autour des données transmises. Les actions OpenWhisk permettent donc d'opérer les formatages intermédiaires facilement. Elles peuvent aussi être exécutées pour réagir à un événement envoyé par un capteur. Comme ces événements peuvent parfois tous arriver en même temps et être très nombreux, le fait que OpenWhisk puisse évoluer rapidement pour tenir la charge avec des temps de réponse prédictibles est une bonne chose.
Les API backend : Pour faciliter l'architecture du coté serveur et se concentrer plus sur l'application en elle même.
La gestion de données : OpenWhisk peut mettre en place des actions pour réagir à des flux de donnés, pour détecter des changements, faire du formatage, transmettre des messages, appeler d'autres actions, et mettre à jour des bases de données ou des fichiers.
Les technologies cognitives : Pour par exemple extraire des informations de flux vidéos.

Avantages et Inconvénients

Avantages

Réduire les coûts opérationnels : Cela comprends les couts d'infrastructure, étant donné que l'on partage une architecture avec plusieurs personnes, et les couts en main d'œuvre, car il est plus simple de gérer une technologie serverless que d'héberger sois même.
Réduire les coûts d'évolution : Comme les ressources nécessaires sont allouées automatiquement suivant les besoins, l'on ne paye que pour ce que l'on utilise.
Facilite la gestion opérationnelle : Maintenir moins de composants demande moins de travail. Encore une fois grâce à l'évolutivité automatique, plus besoin de se demander combien de requêtes concurrentes l'on peut supporter avant de ne plus avoir de mémoire. De plus, il est plus simple de déployer des actions que de déployer un serveur entier, du fait qu'une solution serverless ne demande aucune administration. Enfin, le délai de production et le time to market se retrouvent réduits.
Écologique : Un serveur consomme beaucoup d'énergie, et n'est souvent utilisé que 5-15% du temps, ce qui engendre un gros impact environnemental, surtout à l'échelle de toutes les entreprises. Ici le serveur est dans le Cloud, et est utilisé bien plus fréquemment par tous les utilisateurs et leurs actions.

Inconvénients

Cession du contrôle au vendeur : Avec une solution serverless et donc délocalisée, une partie du contrôle du système est dépendante du vendeur qui met le could à disposition. Cela peut causer des downtimes, des limites imprévues, des changement de prix intempestifs, des mises à jour forcées, etc.
Problèmes de multi-tenant : Dans le cas ou la même application doit servir plusieurs clients (plutôt que chacun ai sa propre instance), même si cela est en général bien fait pour que le client se croit seul sur l'application, il peut y avoir des soucis de sécurité (partages involontaires de données), de robustesse (une erreur chez un client peut en bloquer un autre), et de performance (un client demandant beaucoup de ressources peut en ralentir un autre).
Problèmes de sécurité : Plus le nombre d'action est grand, plus le nombre de pannes et failles potentielles augmentent.
Pas d'état local : Un état local d'une action ne sera pas le même pour une autre action. Pour avoir un état local, il faut mettre en place une base de donnée partagé, ce qui est bien plus lent qu'une architecture classique centralisée.
Auto DoS : En serverless il est commun de faire tourner l'application et les tests sur le même compte utilisateur cloud. Le soucis est que dans le cas ou un test très gourmand est lancé, l'application en production peut être ralentie ou complètement bloquée.
Difficulté des tests et du débogage : Exécuter des tests et dégober ses programmes est plus compliqué car il n'y a pas d'environnement local qui simule un environnement cloud. Aussi comme les conteneurs Dockers sont éphémères, traquer les bugs est plus compliqué.

VT2018 OpenWhisk

Contents