Serverless : moins d’infrastructure, plus de code
Le serverless permet de déployer du code sans gérer de serveurs. Vous payez uniquement pour le temps d’exécution réel. Cette approche transforme le développement backend. Chez Eve Media, nous utilisons le serverless pour des cas d’usage spécifiques où il excelle.
Qu’est-ce que le serverless
Le serverless ne signifie pas « sans serveur » mais « serveur invisible ». L’infrastructure est entièrement gérée par le provider cloud. Vous déployez des fonctions qui s’exécutent en réponse à des événements.
Les providers principaux sont AWS Lambda, Google Cloud Functions, Azure Functions et Cloudflare Workers.
Le modèle d’exécution
Une fonction serverless est dormante jusqu’à ce qu’un événement la déclenche : requête HTTP, message de queue, upload de fichier, timer. Elle s’exécute, retourne le résultat, puis se met en veille.
Le scaling est automatique : des milliers d’instances peuvent s’exécuter en parallèle si nécessaire.
Avantages du serverless
Le coût suit l’usage réel : pas de paiement pour des serveurs idle. Le scaling est automatique et instantané. Pas de maintenance serveur, mises à jour OS ou patches de sécurité à gérer.
Le time-to-market est accéléré : focus sur le code, pas l’infrastructure.
Cas d’usage idéaux
Les APIs légères et microservices. Le traitement d’événements (webhook, upload, notification). Les tâches planifiées (cron jobs). Les backends pour applications mobiles ou single-page apps.
Tout ce qui a des pics de charge imprévisibles ou des périodes d’inactivité.
Le cold start
Quand une fonction n’a pas été appelée récemment, le premier appel subit un délai de démarrage (cold start) de quelques centaines de millisecondes à quelques secondes selon le runtime.
Les stratégies de mitigation incluent le provisioned concurrency (fonctions pré-chauffées) et le choix de runtimes rapides (Go, Rust vs Java).
Limites du serverless
Les exécutions ont des limites de durée (15 min sur Lambda). Les connexions persistantes (WebSockets) sont complexes. Le debugging et monitoring nécessitent des outils spécifiques.
Les applications avec état permanent ou les traitements longs ne sont pas adaptés.
Frameworks serverless
Le Serverless Framework simplifie le déploiement sur plusieurs providers. SST est excellent pour les projets TypeScript. Vercel et Netlify Functions offrent une expérience simplifiée pour le frontend.
Edge functions
Les edge functions (Cloudflare Workers, Vercel Edge) s’exécutent au plus proche de l’utilisateur, réduisant la latence. Elles sont idéales pour la personnalisation, l’A/B testing et la transformation de réponses.
Architecture hybride
La plupart des projets réels combinent serverless et serveurs traditionnels. Le serverless pour les APIs stateless et le traitement d’événements, les conteneurs pour les workloads longs ou stateful.
Coût : attention aux surprises
Le serverless est économique pour les faibles volumes mais peut coûter cher à grande échelle. Modélisez vos coûts et surveillez la consommation.
Conclusion
Le serverless est un outil puissant pour les bons cas d’usage. Il simplifie l’opérationnel et permet un scaling transparent. Mais il n’est pas la solution universelle : évaluez chaque projet individuellement.
Chez Eve Media, nous concevons des architectures adaptées à chaque besoin. Contactez-nous pour discuter de votre projet.