Le serverless : une abstraction de l'infrastructure
L'architecture serverless (ou FaaS — Function as a Service) permet d'exécuter du code sans gérer de serveurs. Vous déployez des fonctions, le fournisseur cloud s'occupe du provisionnement, de la mise à l'échelle et de la haute disponibilité. Vous ne payez que pour le temps d'exécution réel.
Les principaux services : AWS Lambda, Google Cloud Functions, Azure Functions, Cloudflare Workers.
Les avantages du serverless
- Zéro gestion d'infrastructure : pas de serveurs à patcher, pas de capacity planning.
- Scalabilité automatique : de 0 à des milliers d'exécutions simultanées sans configuration.
- Modèle de coût à l'usage : pas de trafic = pas de coût. Idéal pour les charges sporadiques.
- Déploiement rapide : déployez une fonction en secondes.
Les pièges courants
Le serverless n'est pas la solution universelle. Les problèmes les plus fréquents :
- Cold starts : la première invocation après une période d'inactivité peut prendre plusieurs centaines de millisecondes (voire secondes pour certains runtimes). Problématique pour les API à faible latence.
- Durée d'exécution limitée : AWS Lambda impose un maximum de 15 minutes. Inadapté aux traitements longs.
- Coûts à l'échelle : pour des charges constantes et élevées, le serverless peut coûter plus cher qu'un serveur dédié.
- Debugging complexe : le debugging local ne reproduit pas fidèlement l'environnement cloud.
- Vendor lock-in : les intégrations avec les services du fournisseur (SQS, DynamoDB, EventBridge) créent une dépendance forte.
Cas d'usage adaptés
- Webhooks et événements : traiter un webhook Stripe, un upload S3, une notification.
- API à trafic variable : API qui reçoit 10 requêtes la nuit et 10 000 pendant les heures de pointe.
- Traitements asynchrones : génération de PDF, envoi d'emails, traitement d'images.
- Cron jobs : tâches planifiées qui s'exécutent quelques minutes par jour.
Cas d'usage inadaptés
- Applications avec des connexions longues (WebSocket, streaming).
- Traitements nécessitant plus de 15 minutes d'exécution.
- Charges constantes et prévisibles où un serveur dédié serait moins cher.
- Applications nécessitant un état local persistant entre les invocations.
Bonnes pratiques d'architecture serverless
- Gardez vos fonctions petites et focalisées sur une seule responsabilité.
- Utilisez des couches (layers) pour partager du code entre fonctions.
- Externalisez l'état dans des services managés (DynamoDB, Redis, S3).
- Mettez en place un monitoring dédié (AWS X-Ray, Datadog Serverless).
- Testez localement avec des outils comme SAM CLI ou Serverless Framework.