En 20 ans, l'hébergement web a connu de nombreuses révolutions. Dernière en date : le serverless. Comme le « Cloud », il s'agit là surtout d'un nom marketing, qui n'a rien à voir avec une solution qui se serait débarrassé des serveurs. Ils sont toujours là. Du coup, dans la pratique, qu'est-ce qui change ?
Au commencement étaient le serveur dédié et les services mutualisés. Au début du web « grand public », c'était en effet les deux manières principales de se faire héberger.
On accédait encore au contenu des sites à travers un serveur FTP, certains poussaient même la folie jusqu'à éditer leurs pages avec le (non) regretté FrontPage de Microsoft ou encore Dreamweaver d'Adobe. À l'époque, changer de prestataire était aisé : il suffisait de déplacer des fichiers d'un serveur à un autre, et au pire de faire un peu de configuration. Notamment pendant les grandes années de PHP.
Derrière le cloud, de petites menottes numériques
Puis, le « cloud » est arrivé, poussé par les grands acteurs américains, avec la promesse d'infrastructures plus flexibles et résilientes, simple à gérer au quotidien. Ils ont en réalité poussé l'analogie de l'hébergeur/propriétaire immobilier à l'extrême. Si certains louent aux étudiants de petites pièces (voir des colocations) avec de nombreux services pour un prix bien supérieur au mètre carré, ils ont fait de même dans l'environnement numérique.
Partis très tôt avec la force de frappe qui est la leur, ils ont rapidement pris le pas en transformant l'écosystème de l'hébergement au niveau mondial. On le voit très bien à travers le poids qu'ils prennent, notamment en France. Jusqu'à réussir à se placer sans problème sur des marchés aussi sensibles que l'hébergement des données de santé.
Et même si la mode est désormais au multi-cloud et aux données réversibles, que l'on peut transférer rapidement d'un service à l'autre, chaque écosystème dispose de ses habitudes et de ses outils qui sont autant de micro-dépendances. Le tout avec une tarification en général assez opaque/complexe. Un point sur lequel le législateur français ne semble pas pressé d'intervenir. La Fiche d'Informations Standardisées (FIS) du cloud, ce n'est pas pour demain !
IaaS, PaaS, SaaS et compagnie
La promesse reste alléchante : trop de monde sur votre site ? Il « scale » (tout comme votre facture), avec une tarification à l'heure, la minute et pourquoi pas la seconde. Publier votre site web ? C'est simple comme un commit au sein d'un dépôt GitHub. Le stockage de données devient objet, passant par des requêtes HTTPS.
Là aussi, avec la promesse d'une performance en toutes circonstances, sans avoir à demander que de nouveaux serveurs soient installés sous 48h.
Le « Cloud » est ainsi un concept aussi nuageux que son nom, regroupant diverses possibilités, connues par leurs acronymes. Dans ce monde-là, disposer de ses propres serveurs pour y héberger ses données et applications à l'ancienne est connu sous le petit nom d'on-premise. Sinon, on parle d'Infrastructure-as-a-Service (IaaS), de Platform-as-a-Service (PaaS) et de Software-as-a-Service. En passant de l'un à l'autre, vous avez de moins en moins de choses à gérer.
Dans le premier cas, vous louez vos instances à la demande. On ne parle déjà plus de serveurs, puisqu'ils ont été virtualisés. Dans le second, vous ne vous occupez plus de l'OS et de la couche logicielle, juste de déployer vos applications. Dans le dernier, vous louez un simple service en ligne.
Et comme les acteurs proposant ces solutions sont mondiaux, l'accès par les utilisateurs peut se faire au plus proche d'eux. Ces géants n'opèrent en général pas leurs datacenters en direct, mais sont partout.
La modularité, mère du serverless
La montée en puissance du cloud computing s'est accompagnée d'une autre tendance : la plus grande modularité des applications. Que ce soit dans leur conception, avec le trio Angular/React/Vue et Node.js, mais aussi dans l'infrastructure technique qu'elles exploitent. Une application est de plus en plus un ensemble de micro-services, d'API (REST, GraphQL), conteneurisés via Docker, orchestrés à travers Kubernetes et adaptés à la demande des utilisateurs en temps réel.
C'est ce qui a donné naissance au Serverless, ou Function-as-a-Service (FaaS). Une pratique qui n'est pas nouvelle puisque le premier grand fournisseur de service cloud (CSP) à l'avoir proposé est AWS avec Lambda fin 2014. L'idée était de pousser le concept du SaaS jusqu'au développeur : il ne s'occupe de rien, juste de publier son code.
Il sera exécuté à la demande, sur un ensemble de machines plus ou moins puissantes. Toujours fonctionnel, même si la charge augmente. La facturation se fait au temps d'exécution par pouillème de centimes et par tranches de 100 ms. Il n'y a pas d'OS à choisir, pas d'instance ou de sécurité à configurer. Idéal pour un service par requêtes ou une API qui « juste marche ». C'est notamment pour cela qu'AWS le fait travailler conjointement avec son API Gateway.
Le serverless se répand partout
Amazon n'est bien entendu pas le seul acteur sur ce marché. En près de six ans, son initiative en a inspiré d'autres : les Functions de Google, Microsoft ou Netlify, les Workers (Bounded/Unbound) de CloudFlare. En France, Scaleway vient de sauter le pas en mettant en place son offre Serverless en bêta. Elle est gratuite pendant cette phase d'essai et assure, comme d'autres, une compatibilité avec AWS Lambda pour faciliter la migration vers son service.
D'anciens employés du CSP ont d'ailleurs fondé Koyeb, une startup qui veut devenir une sorte d'IFTTT du cloud, permettant un usage serverless multi-cloud. Vous pouvez ainsi récupérer des données chez l'un, les traiter chez l'autre puis stocker le résultat chez un troisième. Le tout avec un catalogue de fonctions clé en main.
De quoi éviter d'avoir à louer constamment des serveurs lorsque ce n'est pas nécessaire, ce qui peut avoir du sens au sein d'une architecture complète. Mais le serverless ne sera pas la réponse à tout et doit être utilisé avec raison. Car peu coûteux à petite dose, il aura l'effet inverse si vous dimensionnez mal vos besoins.
Dans la pratique, comment ça fonctionne ?
Nous aurons l'occasion de revenir plus en détail sur le serverless et ce qu'il permet dans de prochains articles. Mais pour vous permettre de comprendre de quoi il est question concrètement, nous avons conçu de petits exemples que vous pouvez simplement mettre en place.
Nous avons opté pour l'offre de Scaleway, gratuite et simple à prendre en main. Beta oblige, elle est un peu limitée, mais ce sera suffisant pour notre essai du jour. Une fois dans l'interface, vous devrez créer un espace de nom (namespace). Vous pourrez lui attribuer des variables d'environnement sous la forme d'une clé/valeur. Elles seront accessibles à l'ensemble des fonctions et conteneurs qu'il contiendra.
Nous avons ajouté la suivante au nôtre :
URL : https://api.github.com/repos/microsoft/winget-pkgs/contents/manifests
Elle mène à un fichier au format JSON contenant les manifestes de toutes les applications disponibles à travers l'outil winget de Microsoft, permettant leur installation.
Le namespace dispose d'un point d'entrée (endpoint), une URL sous la forme :
rg.fr-par.scw.cloud/funcscw<nom du namespace><caractères alphanumériques>
Passons maintenant à la création de la fonction elle-même. Celle-ci peut être mise en ligne à travers l'éditeur en ligne, un fichier .zip ou pour aller bien plus loin l'interface CLI Scaleway Serverless installable sous la forme d'un paquet npm. Sa documentation complète et son code source sont disponibles par ici.
Pour cet exemple nous nous contenterons de l'éditeur en ligne. Il faut choisir l'environnement d'exécution de la fonction (runtime) entre NodeJS 8.x/10.x, Python 2.x/3.x et Go (seul le zip est proposé). Django et Ruby on rails peuvent être utilisés à travers les conteneurs, précise Scaleway dans sa documentation. Nous avons opté pour Python 3.
Il faut ensuite choisir le niveau de ressources, correspondant à une quantité de mémoire et une portion de processeur. le nombre d'instances pouvant être déployées au minimum et au maximum, si la fonction est accessible en public ou de manière privée, les variables d'environnement qui lui sont propres, etc.
Par défaut, le déclenchement se fait via un endpoint HTTPS. Mais Scaleway évoque d'autres possibilités : CRON (time-based) qui est déjà disponible, puis plus tard MQTT, sans doute en lien avec son IoT Hub.
L'édition d'une fonction Node.js en ligne et les différents paramètres proposés
La fonction par défaut est la suivante :
def handle(event, context):
return {
"body": {
"message": 'Hello, world',
},
"statusCode": 200,
}
Il s'agit d'une méthode dont le nom est handle (correspondant au nom du handler dans l'interface Scaleway) qui reçoit deux dictionnaires en paramètre : event contenant des détails sur ce qui a déclenché la fonction, où l'on trouve notamment le chemin qui vient compléter l'URL de base (path) ou encore les paramètres et context contenant le nom de la fonction et sa version ainsi que la quantité de mémoire accessible.
Le code est plutôt simple, renvoyant un objet body qui sera affiché dans la page (dans une balise <pre>)avec un statut HTTP 200 indiquant que tout s'est bien passé. On peut par exemple la modifier pour afficher le contenu d'event, context, mais aussi l'URL issue des variables d'environnement :
import json, os
def handle(event, context):
return {
"body": {
"event" : json.dumps(event),
"context" : json.dumps(context),
"envvar" : os.environ["URL"],
},
"statusCode": 200,
}
event et context étant des dictionnaires, on utilise json.dumps() pour les sérialiser et en afficher le contenu sous la forme d'une chaine de caractères (string).
Une fois le code modifié, il faut déployer la fonction, ce qui demande quelques dizaines de secondes. Une fois que c'est fait, l'activation peut se faire via l'URL faisant office de point d'entrée. Un bouton de test apparaît alors dans l'interface. Des onglets permettent d'accéder aux paramètres, à la console et aux donnée de monitoring (utilisation CPU, mémoire, nombre de requêtes, latence). Pour vérifier que tout ce passe bien :
Récupérons maintenant le contenu de l'URL pour l'afficher dans la page sous la forme d'un objet avec un décompte du nombre d'applications référencées et la liste complète :
import json, os, urllib.request
def handle(event, context):
with urllib.request.urlopen(os.environ["URL"]) as response:
data = json.loads(response.read())
return {
"body": {
"appsCount": len(data),
"apssList": data,
},
"statusCode": 200,
}
On présente enfin le résultat sous la forme d'un texte mis en forme :
import json, os, urllib.request
def handle(event, context):
with urllib.request.urlopen(os.environ['URL']) as response:
data = json.loads(response.read())
appsList = ""
titre = """Liste des applications disponibles via winget:
-----------------------------------------------
"""
for app in data:
appsList += f"""- {app['name']} ({app['sha']})
{app['url']}
"""
return {
"body": titre + appsList,
"statusCode": 200,
}
Nous n'utilisons pas de code HTML puisque la balise <pre> empêche qu'il ne soit interprété et serve à la mise en forme. Nous avons donc simplement utilisé du texte contenu dans des variables string à triple guillemets permettant de prendre en compte les sauts de ligne. On pourrait faire de même en Markdown par exemple.
Nous obtenons ainsi une fonction qui lit le contenu d'un fichier JSON depuis une URL passée en variable d'environnement, le traiter, mettre en forme le résultat et l'afficher dans le navigateur. Bien entendu, l'exemple donné est trivial et il est possible d'aller bien plus loin avec les fonctions serverless.
Le code modifié et le résultat obtenu
On peut leur passer des paramètres, agir différemment selon le chemin entré dans l'URL. On pourrait imaginer un service vérifiant que tel ou tel site est actif ou non, un autre qui récupèrerait une image pour la traiter puis la renvoyer, etc. L'important est ici d'avoir réussi à obtenir un résultat fonctionnel et accessible en ligne avec quelques lignes de Python, sans avoir à gérer de serveur et où l'on ne paiera que pour les requêtes effectuées.
L'avenir ? Rendez-vous dans dix ans pour en faire le bilan.
