L’offre Serverless de Scaleway (FaaS/CaaS) en disponibilité générale

Si les annonces se multiplient dans le domaine du PaaS et de l'IaaS chez les fournisseurs de services cloud (CSP), Scaleway donne le coup d'envoi de son offre serverless qui regroupe à la fois du CaaS et du FaaS (Container et Function-as-a-Service). Elle est désormais accessible à tous.

Depuis quelques mois, Scaleway prépare de nombreuses nouveautés et les met peu à peu en production. Après son Kubernetes managé multi-cloud Kosmos c'est au tour de son offre de fonctions et conteneurs.

Serverless : code and (cold) run

Présentée comme « Serverless », elle n'est pour autant pas « sans serveur », mais permet de « se focaliser sur l'essentiel » comme le veut la formule consacrée. Vous n'avez ainsi rien à administrer, juste à développer des outils qui seront activés à la demande. Une solution que l'on trouve chez AWS Lambda ou les Workers de CloudFlare.

« La plupart des instances Cloud sont inactives 93 % du temps » indique Scaleway pour justifier l'intérêt de cette solution qui est facturée uniquement à la demande et selon les ressources utilisées. Ainsi, vous n'avez pas besoin de payer pour une instance disponible 24/7. Vous avez besoin d'un script ? Il est lancé, vous obtenez le résultat, il est fermé. Une solution intéressante, mais qui implique parfois un « cold start » et donc un délai qu'il faut gérer.

Elle vient ainsi se placer au-dessus du PaaS où il faut en général choisir un environnement d'exécution de votre application, déployée selon un fichier de configuration. Ici, ce n'est pas le cas, il n'y a pas de phase de configuration, de build ou autre. Vous pouvez simplement envoyer votre code via l'interface en ligne, l'enregistrer et l'appeler.

Le serverless vient se placer entre le PaaS et le SaaS - Crédits : Red Hat

Ce service, présenté comme une première en Europe en complément d'une offre complète, était en test depuis plus d'un an. Nous l'avions d'ailleurs utilisé pour vous expliquer ce qu’est le FaaS/Serverless. 2 000 organisations ont participé à cette phase d'essai, on passe désormais à la disponibilité générale avec une grille tarifaire.

Scaleway semble d'ailleurs le destiner surtout à ses clients à l'international puisque bien que nous ayons reçu un communiqué en français, les trois billets de blog publiés depuis (1, 2, 3) sont exclusivement en anglais, tout comme la documentation (ici et là) de cette solution. Comme l'entreprise recrute, espérons qu'elle trouvera des traducteurs.

Une approche présentée comme plus moderne

Elle a d'ailleurs été dévoilée à un évènement européen, le Web Summit qui se tenait début novembre à Lisbonne. Scaleway y vantait « les architectures microservices [qui] sont plus simples à maintenir, à faire évoluer, à mettre à jour, et sont moins exigeantes en termes de ressources et permettent une mise à l’échelle automatique ».

En réalité, ce ne sont d'ailleurs pas une mais deux solutions qui sont disponibles : Serveless Functions et Serverless Containers qui « permettent aux utilisateurs de facilement déployer du code et d’exécuter des conteneurs dans l'écosystème cloud complet de Scaleway, sans la difficulté opérationnelle liée à la gestion de l'infrastructure ». Elles sont respectivement compatibles avec AWS Lambda et Terraform/Serverless.com.

L'entreprise vante aussi les avantages d'une telle approche pour l'éco-conception des architectures applicatives et la présente comme « efficace sur le plan énergétique puisqu'elle permet de réduire sa consommation à zéro, optimisant ainsi notre service global en tant que fournisseur de cloud public » selon son DG, Yann Lechelle.

Et la société d'évoquer « les futurs développeurs s'éloignent de la conception d'applications monolithiques pour privilégier le développement d'applications via une série de microservices complémentaires. L’approche serverless pour le développement d’applications devient de plus en plus populaire ».

Scaleway donne l'exemple d'une fonction qui aurait pour rôle de lister les images d'un espace de stockage (bucket) S3, appelant pour chacune d'entre elle une autre fonction qui accèdera au fichier, lui appliquera une transformation et le transfèrera ensuite dans un autre bucket S3. Pour les conteneurs, elle présente cette manière de gérer son architecture comme ayant les avantages de Kubernetes, sans avoir à se préoccuper des fichiers YAML.

Pour autant, et comme tout service du genre, le CaaS/FaaS n'est pas la réponse à tous les problèmes. Elle est adaptée surtout pour des micro-services ou applicatifs qui répondent à des besoins ponctuels, fluctuants, qui ne nécessitent pas de mobiliser une instance entière 24/7 ou que vous ne voulez pas avoir à la gérer.

Pour une solution massive et constamment sous pression, il faudra sans doute regarder ailleurs. L'ensemble peut d'ailleurs être utilisé en complément de déploiements plus classiques. Cette approche pourra également poser question si elle est utilisée à l'extrême dans des entreprises qui cherchent à préserver une certaine indépendance technologique. Car tout compatible qu'elle soit avec un service équivalent chez AWS, elle qui tend à déporter tout le savoir-faire de gestion des infrastructures et de déploiement chez un tiers.

Crédits : D. Taibi, J. Spillner and K. Wawruch, "Serverless Computing-Where Are We Now, and Where Are We Heading?,"

Les conteneurs et fonctions selon Scaleway

En pratique, Scaleway se repose sur sa propre architecture de déploiement Kubernetes depuis le registre de conteneurs de votre compte. Dans le cas d'une Fonction, le code que vous soumettiez via l'interface web (Console) ou l'API/CLI passe auparavant par une phase de build dans Tekton (un environnement CI/CD).

Lorsqu'une requête ou un évènement interviennent, Knative (qui vient de passer en 1.0) récupère l'image dans le registre puis la déploie dans un nœud d'un cluster Kubernetes (Kapsule) où il est exécuté. La Console et l'API/CLI peuvent recevoir des informations de la part de ce nœud, ce qui permet notamment d'assurer tout le monitoring.

L'activation peut se faire sur un appel via une requête HTTP ou une tâche automatisée via CRON. Vous pouvez exécuter n'importe quel type de conteneur et donc d'applicatifs dans le CaaS, « par exemple, recadrez des vidéos ou traitez des fichiers audio à l’aide de C++ » indique le site de Scaleway.

Le FaaS est pour sa part limité à certains langages, un éditeur en ligne très léger étant proposé dans l'interface : Go (1.11+), Node.js (8/10/14) et Python (2.7/3.7). D'autres pourront être ajoutés, aucune feuille de route n'a été précisée.

Leur tarification est de 0,15 euro par million de demandes par tranches de 120 ms nécessaires à l'exécution et de 128 Mo de mémoire (celle-ci varie selon un choix de l'utilisateur). L'unité obtenue est ainsi le 100k Go-s, facturé 1,2 euro. Pour les conteneurs, cela dépend de la consommation de mémoire (0,10 euro par 100k Go-s) et de vCPU (1 euro par 100k vCPU-s) selon des tranches et là aussi par 100 ms d'exécution.

Il est précisé que pour « atténuer la latence de cold start, vous pouvez également provisionner des fonctions, nous facturerons un supplément de 0,36 euro par 100k Go-s pour garder vos fonctions au chaud [...] Vous pouvez approvisionner des conteneurs pour atténuer la latence du Cold Start ou assurer des activités plus longues, vous serez facturé sur les ressources consommées ».

Des paliers de gratuité sont proposés dans tous les cas : 400k Go-s par compte et par mois pour l'usage mémoire des fonctions et conteneurs, 200k vCPU-s par compte et par mois pour les conteneurs. Soit quelques euros au total, mais cela devrait le plus souvent suffire à se faire une idée du fonctionnement de ces deux services.

Vous trouverez quelques exemples de fonctions prêtes à l'emploi dans la documentation.