Le serverless, nouvelle révolution de l'hébergement ? On vous l'explique par l'exemple

if (servers == 0) return {"serverless": false}
Le serverless, nouvelle révolution de l'hébergement ? On vous l'explique par l'exempleCrédits : gremlin/iStock

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.

IaaS PaaS SaaS Cloud
Crédits : Red Hat

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.

Scaleway ServerlessScaleway Serverless

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.

Scaleway ServerlessScaleway Serverless
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 :

Scaleway ServerlessScaleway Serverless

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.

Scaleway ServerlessScaleway 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.

  • Introduction
  • Derrière le cloud, de petites menottes numériques
  • IaaS, PaaS, SaaS et compagnie
  • La modularité, mère du serverless
  • Le serverless se répand partout
  • Dans la pratique, comment ça fonctionne ?
S'abonner à partir de 3,75 €
60 commentaires
Avatar de flamme-demon Abonné
Avatar de flamme-demonflamme-demon- 07/08/20 à 15:53:44
#1

C'est moi ou tous le monde va perdre en connaissance, ce qui risque de créer des dépendances encore plus grandes ?

Avatar de David_L Équipe
Avatar de David_LDavid_L- 07/08/20 à 15:58:30
#2

undefined

C'est toujours une question de rapport entre le besoin et les moyens. Est-ce qu'une startup a besoin de gérer l'ensemble de son infrasctructure en propre et en dur, de monopoliser sur capex là-dessus, de multiplier les sysops pour espérer ne pas se faire trouer ou est-ce qu'elle doit déporter un minimum ? Cela peut venir avec le temps, mais ce n'est pas forcément le plus adapté à toutes les structures.

Le problème se pose aussi autrement comme je le dis dans le papier. Tu peux très bien utiliser du serverless pour certains besoins, pour porter une API ou l'accès à des micro-services par exemple, tout en ayant des services on-premise pour d'autres besoins où ce n'est pas la scalabilité à la seconde qui t'importe.

Rien n'est jamais tout blanc ou tout noir. Parfois on prend le bus. Ce n'est pas pour ça qu'on ne conduit plus.

Avatar de kgersen Abonné
Avatar de kgersenkgersen- 07/08/20 à 16:14:48
#3

de nos jours on distingue 2 approches "serveless":

FaaS:

  • AWS Function
  • Google Cloud Functions
  • Azure Functions

KaaS ou Managed Container Services:

  • GCP Cloud Run
  • AWS Fargate/EKS
  • Azure Container Instances

Scaleway Serverless que je ne pratique pas semble faire le grand écart entre les 2.

Édité par kgersen le 07/08/2020 à 16:15
Avatar de LordZurp Abonné
Avatar de LordZurpLordZurp- 07/08/20 à 16:24:10
#4

j'me sens un vieux crouton à gérer mon serveur à la main et maintenir une pile LAMP :craint:

Avatar de SebGF Abonné
Avatar de SebGFSebGF- 07/08/20 à 16:26:23
#5

undefined

Dans la pratique c'est déjà le cas : les grandes entreprises sous traitent déjà leurs DSI depuis longtemps si bien que la compétence interne s'est perdue au fil des années (perso je suis chez des clients qui n'ont quasi plus de compétence infra en interne, pas de DBA, pas d'ingé système, tout est externalisé en TME). Ce n'est donc qu'une évolution du modèle d'externalisation de l'IT et des couches pour lesquelles une entreprise qui n'a pas forcément d'intérêt à payer des compétences internes mais aussi les frais qui vont derrière ira sous traiter.

Comme le dit David, tout est une question de relation avec le besoin.

Sinon un petit article complémentaire à ce sujet pourra être par rapport à l'Infrastructure as Code ou encore au GitOps qui se généralise pas mal aussi. Les applications et environnements ne sont plus que des fichiers de configs versionnés par un gestionnaire de sources, les actions se faisant par des commits et push sur ceux-ci et derrière l'automatisation se charge de faire sa magie. C'est notamment les sujets sur lesquels je travaille avec la possibilité de faire pop des instances applicatives à la volée (peu importe leur mode d'hébergement), gérer leurs montées de versions et maintenances le tout en se reposant sur du code versionné par Git (typiquement de l'Ansible). Dans notre cas nous avons justement pas mal d'applications historiquement hébergés en mode "lourd" (stand alone sur une VM notamment) ou même sous forme de dockers (mais plus en mode image tomcat + webapp, donc sans exploiter l'intérêt des containers) qui sont en train de se transformer dans ce modèle.

Avatar de David_L Équipe
Avatar de David_LDavid_L- 07/08/20 à 16:28:09
#6

undefined

Ah ben à l'heure où tu peux foutre du HTML statique généré en local dans du S3... #Teasing :D

undefined

En cours ;)

Édité par David_L le 07/08/2020 à 16:29
Avatar de SebGF Abonné
Avatar de SebGFSebGF- 07/08/20 à 16:29:33
#7

undefined

Sur mon dédié que j'ai chez OVH j'ai préféré l'approche Proxmox et monter plusieurs VM répondant à mes diverses besoins plutôt qu'une machine qui gère tout comme je faisais avant. Et surtout ça me permet de tester des trucs sur une VM sans niquer ma prod perso :transpi:

undefined

:yes:

Édité par SebGF le 07/08/2020 à 16:30
Avatar de David_L Équipe
Avatar de David_LDavid_L- 07/08/20 à 16:32:56
#8

undefined

J'ai quand même du mal à voir le KaaS comme du serverless, on tombe plus dans l'Infrastructure as Code comme dit au dessus non ? Chez Scaleway en tous cas c'est plutôt la pile K8S qui gère ça que serverless où c'est du pur FaaS (même l'option conteneur qui n'existe apparemment que pour gérer des couches logicielles différentes de celles proposées clé en main.

undefined

C'est notamment pour ça qu'on a commencé à parler de Multipass côté NXi (histoire d'introduire le sujet en douceur :D

Édité par David_L le 07/08/2020 à 16:34
Avatar de zwindler Abonné
Avatar de zwindlerzwindler- 07/08/20 à 17:48:39
#9

Le KaaS c'est pas du tout du serverless.

Faut voir Kubernetes comme un genre PaaS un peu moins "opinionated" qu'un PaaS classique, dans le sens où les objets que tu crée dedans sont standards. C'est pas pour rien que OpenShift, le PaaS de Redhat, a tout jeté en v2 pour passer sur Kubernetes en v3. C'est un PaaS.

Le KaaS, c'est ni plus ni moins qu'un Kubernetes qu'on installe pour toi

Avatar de Cqoicebordel Abonné
Avatar de CqoicebordelCqoicebordel- 07/08/20 à 18:05:05
#10

Article intéressant, mais de mon point de vue, il manque des trucs : avoir les exemples de scripts, c'est cool, mais ce serait pas mal de montrer les résultats également.

Par ailleurs, comment ces scripts sont exécutés ?

undefined

Ca veux dire qu'en faisant une requête GET, ça déclenche le script ?

Vous dites utiliser du Python, mais dans la capture, c'est écrit "runtime: node8".
Vous mentionnez MQTT, sans faire de définition.

Bref, tout ça pour dire, c'est un sujet complexe, et laisser des zones pas claires, c'est pas idéal pour aider à la compréhension.
Je juge pas, hein, je sais que c'est pas évident non plus. Je pense juste qu'un poil plus de formalisme pourrait aider tout le monde :)

Il n'est plus possible de commenter cette actualité.

Page 1 / 6

2000 - 2020 INpact MediaGroup - SARL de presse, membre du SPIIL. N° de CPPAP 0321 Z 92244.

Marque déposée. Tous droits réservés. Mentions légales et contact