Serverless

Le serverless est un modèle de cloud computing où le code s'exécute dans des fonctions entièrement gérées par un fournisseur, sans serveur à provisionner, corriger ou dimensionner manuellement. Des serveurs existent toujours quelque part, le nom fait référence au fait qu'un développeur n'a jamais à y penser : le code est déployé, le fournisseur l'exécute à la demande, et la capacité s'ajuste automatiquement à la hausse ou à la baisse selon le trafic, jusqu'à zéro quand rien ne se passe.

‍

Qu'est-ce que le serverless ?

Dans une architecture serverless, une application est découpée en petites fonctions indépendantes qui s'exécutent chacune en réponse à un événement, une requête HTTP, un changement en base de données, un déclenchement planifié, plutôt que de tourner en continu sur un serveur en attente de trafic. Le fournisseur alloue le calcul nécessaire à chaque invocation, exécute la fonction, puis démonte l'environnement. La facturation suit la même logique : au lieu de payer un serveur allumé 24 heures sur 24, une équipe ne paie que les millisecondes d'exécution réelle.

Le modèle déplace la responsabilité : une équipe ne gère plus de système d'exploitation, de correctifs de sécurité ni de planification de capacité, et se concentre uniquement sur la logique métier à l'intérieur de chaque fonction.

‍

Comment fonctionne une fonction serverless

Une fonction est écrite pour traiter un seul événement et déployée chez un fournisseur, qui la relie à un déclencheur. Un exemple minimal sur Supabase Edge Functions :

Deno.serve((req) => {
    return new Response("Hello, world");
});

Aucune configuration de serveur n'accompagne ce code : le déployer suffit pour que le fournisseur expose un point d'accès, invoque la fonction à chaque requête, et ajuste automatiquement le nombre d'exécutions concurrentes à mesure que le trafic augmente.

‍

Les types de services serverless

• FaaS (Function as a Service) : des fonctions individuelles déclenchées par des événements, comme AWS Lambda ou Supabase Edge Functions.
• BaaS (Backend as a Service) : des briques backend gérées, base de données, authentification, stockage, exposées via une API, comme Supabase ou Firebase.
• Bases de données serverless : des bases qui ajustent automatiquement stockage et calcul et facturent à l'usage plutôt qu'une taille d'instance fixe.
• Fonctions edge : des fonctions serverless déployées pour s'exécuter physiquement près du visiteur, réduisant la latence pour une audience mondiale.

‍

Serverless vs serveur traditionnel

‍

Bonnes pratiques et pièges courants

Le serverless convient aux charges qui varient de façon imprévisible ou restent inactives la majorité du temps, car un serveur traditionnel payé en continu gaspillerait de l'argent dans ces conditions. Le principal piège technique est la latence du cold start : une fonction qui n'a pas tourné récemment peut mettre plus de temps à répondre à sa première invocation, ce qui compte pour des requêtes sensibles à la latence. Le verrouillage fournisseur est aussi un risque réel, car les fonctions serverless sont souvent écrites contre les déclencheurs et API spécifiques d'un fournisseur, rendant une migration ultérieure non triviale. Garder des fonctions petites et sans état, avec toute donnée persistante stockée dans une vraie base plutôt que dans la fonction elle-même, évite la plupart des erreurs de conception.

‍

Serverless et performance applicative

Parce que les fonctions serverless peuvent être déployées en périphérie, près des visiteurs partout dans le monde, elles réduisent souvent la latence par rapport à un unique serveur traditionnel dans une seule région, ce qui profite à la fois à l'expérience utilisateur et à des métriques comme le Time to First Byte. La contrepartie est que les cold starts peuvent introduire des pics de latence occasionnels, si bien que les chemins critiques en latence justifient parfois encore un service tournant en continu.

‍

Le serverless chez BeBranded

Nous mobilisons fonctions serverless et backends gérés, Supabase, Firebase, Cloudflare Workers, quand la charge d'un projet correspond réellement à ce modèle, pour que nos clients évitent de payer une capacité serveur inactive ou de gérer une infrastructure dont ils n'ont pas besoin. C'est l'une des fondations que nous envisageons pour chaque application web que nous concevons.