En développement depuis trois ans, elle est désormais accessibles à tous. Il s'agit pour rappel de déployer des scripts sans se soucier de leur hébergement, à la manière d'AWS Lambda ou des Workers de CloudFlare.
Le service est d'ailleurs compatible avec celui d'Amazon, l'éditeur de code en ligne proposé Ace (utilisé par Cloud9).
Dans la pratique, vous créez des Namespaces en déclarant des variables d'environnement, où vous pouvez directement déployer des scripts NodeJS (8.x/10.x), Python (2.x/3.x) ou Go. On peut également opter pour un environnement personnalisé via Docker.
Le mode de tarification n'est pas encore précisé, ni le délai avant la mise en production définitive. La documentation complète est disponible par ici. Pour rappel, IoT Hub est également disponible en bêta, d'autres services comme AI Inference, MySQL ou Domains étant encore réservés à des utilisateurs invités.
Commentaires (8)
#1
C’est super ça, parce que le serverless est clairement le point principal sur lequel les hébergeurs cloud européens ont du retard.
#2
Sans un équivalent à API Gateway on perd une bonne partie de l’intérêt. Mais chaque chose en son temps, je suis content que Scaleway intègre enfin un tel service :)
#3
Je comprends bien pour des besoins spécifiques, mais bon, tout le monde ne cherche pas à faire de l’API avec du serverless. Après je ne connais pas le produit AWS dans le détail, mais il est dans l’impossibilité de fonctionner avec des instances externes ?
#4
Ils ont juste des années de retard sur Azure et Aws complètement à la masse les types
#5
Je ne connaît pas…
Juste quand je voie le tarif à mettre pour avoir l’équivalent d’une machine physique, je trouve que ça ne vaut le coup (pour du hosting web en tout cas). Même si c’est sûrement plus fiable (quand c’est bien géré).
#6
l’intérêt des fonctions serverless réside surtout dans l’intégration de cette brique dans les autres services. (API Gateway, message queue, events, logs, scheduler, etc.)
OVH avait tenté un service de ce type, mais ce service n’était intégré avec aucun autre service OVH. ça perdait beaucoup de son intérêt et ça a été vite abandonné.
#7
Ce n’est pas le but, le but c’est de pouvoir avoir des scripts exécutés à la demande, réagissant à des évènements le plus souvent, et de ne payer que pour le temps actif, plutôt que d’avoir une machine qui fonctionne constamment pour ça.
#8
Visiblement les triggers disponibles sont “CRON (time-based jobs), MQTT queues, and more.”.
Ça permet donc déjà de faire des tâches récurrentes et des actions quand un message arrive depuis de l’IoT.
Le gros avantage de ces solutions c’est qu’on peut gérer des actions sans avoir besoin de se soucier de comment ça scale.
J’avais eu le problème avec une application classique (comprendre par là, un backend en un bloc qui gère tout) placé derrière un load balancer et un système de scaling. Il avait des tâches cron et donc si deux instances tournent, tout est exécutés en double.
Plutôt que mettre en place des mécanismes de lock complexe via un redis ou autre, suffit de mettre les tâches CRON sur du lambda et voila, les tâches sont exécutées une seule fois et toujours quand il faut.
Pareil pour la gestion des messages MQTT.
Il manque maintenant à scaleway un équivalent d’API gateway pour qu’on puisse faire de même avec les requêtes HTTP ;)