Temps de lecture : 7 minutes

Il existe plusieurs solutions open sources ou hébergées pour monter sa propre architecture serverless. J’ai choisi de tester les deux solutions open sources plus populaires, ainsi que deux des plus gros acteurs actuellement sur le marché afin de me faire une idée du fonctionnement de chaque solution. Je vais déployer un simple hello world sur l’ensemble des outils afin de tester l’utilisation et les temps de réponses.

Je ne connais aucunes des solutions, mais je vais me faire mon analyse autour des 5 points suivants :

  • Est-ce qu’il est possible d’avoir une solution hautement disponible ?
  • Est-ce qu’il y a un engouement autour de la solution ? (articles, conf, contributions)
  • Est-ce que c’est simple à utiliser pendant les développements ?
  • Est-ce que la solution est scallable ?
  • Est-ce que c’est utilisable/utilisé en prod ?

Pour les solutions hébergées je vais toujours prendre, si possible,  un datacenter proche de la France. Pour les solutions open sources je vais utiliser un serveur Scaleway hébergé en France avec 4 coeurs, 4 Go de ram et 300Mo/s de bande passante entièrement dédiée au test. Chaque test sera fait sur une installation « propre » de Debian Stretch.

Bien évidement il y a d’autres facteurs qui entrent en jeux avant de choisir un solution plutôt qu’une autre tel que les SLA en cas de problème, la fiabilité du partenaire (Est-ce qu’il sera toujours présent dans 5 ans ?), le pays dans lequel les serveurs sont hébergées… Mais dans le cas présent je m’intéresse surtout à la fiabilité du service et je n’ai ni impératifs de production ni données sensibles à hébergées.

A la suite du test je choisirais une solution pour construire une petite application.

Amazon Lambda

Présentation

Le plus célèbre acteur du marcher est Amazon avec ses lambdas functions. Ce qui est vraiment pas mal avec cette solution c’est que pour un petit projet vous pouvez vous en sortir sans rien avoir à payer car le premier million de hit est gratuit.

Il y a plusieurs version de java, node, python et .Net de supportées par Amazon Lambda.

Mise en place

Les fonctions lambda sont intégrées à la solution AWS et peuvent être lancées par beaucoup d’évènements différents. Dans mon cas ce qui m’intéresse c’est les fonctions lambda déclenchées par une API Gateway. Il n’y a aucunes installation à faire avant de pouvoir les utiliser. 

Hello world

Cette lambda est un bête hello world :

Développement /Déploiement

Une fois enregistrée ma lambda est automatiquement disponible via HTTPS sur une URL unique. Il est possible d’activer ou non une couche d’authentification, mais pour mon hello world je ne vais pas la mettre en place.

Via le framework serverless, dont je parlerais dans un prochain article,  le déploiement / mise à jours peux se faire en ligne de commande en quelques secondes.

Benchmark

Je vais lancer un petit benchmark dessus pour voir les temps moyens de réponses sur un hello world.

➜  ~ ab -n 1000 -c 10 https://XXXXXXXXXX.execute-api.eu-central-1.amazonaws.com/default/test
[...]
Concurrency Level:      10
Time taken for tests:   16.969 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      305000 bytes
HTML transferred:       19000 bytes
Requests per second:    58.93 [#/sec] (mean)
Time per request:       169.686 [ms] (mean)
Time per request:       16.969 [ms] (mean, across all concurrent requests)
Transfer rate:          17.55 [Kbytes/sec] received
[...]

Les temps de réponses ne sont vraiment pas mauvais, en moyenne 58 requêtes par seconde.

Conférences

Une conférence en français d’amazon présente assez bien les fonctions lambda :

Ce qui est très sympa avec cette solution c’est que c’est clef en main. On a plus qu’à se concentrer sur notre application en s’abstrayant de la partie gestion des serveurs et de la problématique de haute disponibilité. 

Cloud function Google

Présentation

Google, second grand acteur du serverless avec ses cloud function propose aussi un « forfait » gratuit pour les deux premiers millions d’appel.

Tout comme amazon lambda il est possible de créer et d’administer ses lambda via la console web. Il faut patienter une bonne minute entre le moment ou on crée une fonction et le moment ou elle est mise à disposition. Tout comme les lambdas d’amazon il est possible de déclencher les Cloud functions via des évènements autres que HTTP (ex: modification dans une base firebase).

Mise en place

Il n’y a rien de spécifique à faire à part avoir un compte google développeur.

Hello world

Voici le code de ma cloud function :

Développement / Déploiement

De même que pour Amazon Lambda le framework serverless va permettre de travailler avec Google Cloud function. 

 Ce qui est vraiment un plus, non négligeable, c’est qu’il est possible de lancer les fonctions en locale avec l’emulateur node js pour google cloud.

Benchmark

➜  ~ ab -n 1000 -c 10 https://europe-west1-XXXXXXX-XXXXX.cloudfunctions.net/function-1
Concurrency Level:      10
Time taken for tests:   15.187 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      361008 bytes
HTML transferred:       11000 bytes
Requests per second:    65.85 [#/sec] (mean)
Time per request:       151.870 [ms] (mean)
Time per request:       15.187 [ms] (mean, across all concurrent requests)
Transfer rate:          23.21 [Kbytes/sec] received

Google Cloud function ne support que du python 3.7 et du node js 6 et 8.

Apache OpenWhisk

Présentation

OpenWhisk est la solution open source serverless de la fondation apache. Il est possible mettre en place cette solution sur du kubernates, du mesos ou simplement via docker-compose.

Le support des langages est assez étendu pour les fonctions hébergées sur la solution. Il y a notamment Nodejs, python, PHP, java, Go … 

Les fonctions, appelées Actions,  peuvent être déclenchées par des évènements (trigger), des appels HTTP ou encore via des modifications sur un flux d’information (feed).

Mise en place

J’ai suivi la documentation pour une installation docker compose. Malgrès plusieurs tentative je n’ai jamais réussi à faire tourner OpenWhisk sur mon serveur. Le script d’install a crashé de multiples fois sur des étapes différentes et la seule fois (sur 7) ou il n’a pas crashé pendant les install il n’a pas réussi à configurer le client car la stack ne renvoyait que des 500.

J’ai donc décidé de tester sur mon macbook pro 2017. Sur le mac je n’ai eu aucun problème à l’installation.

Hello world

function main() {
    return {payload: 'Hello world'};
}

Développement /Déploiement

Un client en ligne de commande est disponible pour gérer les functions déployées. Il est donc assez simple et rapide de mettre à jours une fonction pour la tester.

J’ai eu beaucoup de difficultés pour trouver l’URL pour appeler ma fonction, les crédentials pour m’authentifier sur le endpoint (une fois trouvé). 

Benchmark

Le benchmark n’a pas de sens car l’éxecution se fait sur mon mac dans la docker machine. En moyenne les temps de réponses étaient aux alentours de 150ms.

OpenFaas

Présentation

OpenFaas est une solution opensource basée sur des orchestrateurs docker. Pour mon test je vais utiliser swarm avec un seul node. OpenFaas vient par défaut avec une interface web d’administration, une installation prés-configurée de prometheus afin de collecter des metrics sur la plateforme.

OpenFaas permet de créer des fonctions dans divers langages (Go, Python, Node, Ruby, Java…) mais aussi faire une passerelle entre OpenFaas et des binaires. La solution propose aussi un support des lambdas d’amazon.

La documentation est centralisée et assez complète. On peux y trouver  beaucoup d’exemple sur l’ensemble des langages supportés.

Ce qui est important de noter c’est qu’il est possible de déployer openfaas sur des serveurs ARM (Raspberry par exemple).

Mise en place

L’installation sur un docker swarm se fait en moins d’une minute en lancant le script présenter dans la documentation. Pour intéragir avec openfaas il client en ligne de commande est disponible en plus de l’interface web.

Chaque fonction est une image docker qui doit être présente sur un registry docker. 

Hello world

"use strict"

module.exports = (context, callback) => {
    callback(undefined, {status: "Hello World"});
}

Développement /Déploiement

faas new hello-world --lang node --gateway http://51.15.84.114:8080
# coder la fonction dans le fichier hello-world/handler.js
faas build -f hello-world.yml
faas push -f hello-world.yml
faas deploy -f hello-world.yml

Benchmark

➜  ab -n 1000 -c 10 http://51.15.84.114:8080/function/hello-world
Concurrency Level:      10
Time taken for tests:   49.517 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      257000 bytes
HTML transferred:       26000 bytes
Requests per second:    20.20 [#/sec] (mean)
Time per request:       495.166 [ms] (mean)
Time per request:       49.517 [ms] (mean, across all concurrent requests)
Transfer rate:          5.07 [Kbytes/sec] received

Conférences

J’ai aussi regardé du côté de Iron-io mais la solution, bien qu’elle fournisse un interface HTTP, semble plus axée sur les traitements asynchrones. Ce n’est pas spécialement ce qui m’intéresse. Mais pour du traitement de masse comme du travail sur des images, de l’envoie de mail… c’est une solution à explorer.

Résultat du comparatif

[table id=3 /]

OpenFaas est une solution très interessante qu’il faut surveiller mais qui, pour le moment ne me paraît pas être encore assez mature pour héberger une application de production.

Actuellement je dirais que Amazon lambda est la solution la plus fiable/stable/simple car elle est très bien intégrée à l’environnement AWS, il y a une bonne documentation, elle s’appuie sur l’expertise d’un des leaders sur le sujet de l’hébergement.