Architecture Serverless : Patterns, Limites et Économie
Le serverless transfère la responsabilité opérationnelle au fournisseur cloud, permettant aux équipes de se concentrer sur la logique métier. Mais le "serverless" n'est pas une solution universelle -- comprendre ses patterns, contraintes et dynamiques de coût est essentiel pour prendre de bonnes décisions architecturales.
Patterns serverless principaux
Backend API
Le pattern le plus courant : requêtes HTTP routées via une API Gateway vers des fonctions.
- API Gateway + Lambda / Cloud Functions
- Scaling automatique de zéro à des milliers de requêtes concurrentes
- Facturation à l'invocation
Traitement événementiel
Fonctions déclenchées par des événements de files, streams ou changements de stockage.
- Upload S3 déclenche le traitement d'images
- Message SQS/SNS déclenche le traitement de commandes
- Stream Kinesis/Pub-Sub déclenche l'analytique temps réel
Jobs planifiés
Remplacer les serveurs cron par des invocations de fonctions planifiées.
- EventBridge Scheduler + Lambda
- Cloud Scheduler + Cloud Functions
- Idéal pour les syncs périodiques, génération de rapports, tâches de nettoyage
Workflows d'orchestration
Composer plusieurs fonctions en workflows complexes.
- AWS Step Functions / GCP Workflows
- Gestion d'erreurs, retries et exécution parallèle intégrés
- Définition visuelle du workflow
Paysage des services serverless
| Catégorie | AWS | GCP | Azure |
|---|---|---|---|
| Compute | Lambda | Cloud Functions / Cloud Run | Azure Functions |
| API | API Gateway | API Gateway / Cloud Endpoints | API Management |
| Orchestration | Step Functions | Workflows | Durable Functions |
| Base de données | DynamoDB | Firestore | Cosmos DB (serverless) |
| Stockage | S3 | Cloud Storage | Blob Storage |
| Messaging | SQS, SNS, EventBridge | Pub/Sub, Eventarc | Event Grid, Service Bus |
Limites et contraintes connues
| Contrainte | Impact | Mitigation |
|---|---|---|
| Cold starts | 100ms à plusieurs secondes de latence | Concurrence provisionnée, patterns keep-warm |
| Temps d'exécution | Lambda : 15 min, Cloud Functions : 60 min | Découper en étapes, utiliser Step Functions |
| Taille du payload | API Gateway : 10MB, Lambda : 6MB sync | URLs présignées S3 pour les gros payloads |
| Limites de concurrence | 1000 concurrent par défaut par région | Demander des augmentations de quota |
| Vendor lock-in | Intégration profonde avec les services du provider | Logique métier portable, patterns adaptateur |
| Debugging | Le tracing distribué est plus difficile | X-Ray, logging structuré, émulateurs locaux |
Extrait de la fiche « AWS Lambda in Depth: Execution, Invocation, Failure » · Demander la fiche complète
Quand le serverless économise de l'argent
- Trafic variable -- rien à payer à zéro, scaling automatique au pic
- Charges ponctuelles -- jobs planifiés qui tournent quelques minutes par jour
- Prototypage -- aucun coût d'infra tant qu'il n'y a pas de vrai trafic
- Pipelines event-driven -- charges de traitement en rafales et imprévisibles
Quand le serverless coûte plus cher
- Haut débit constant -- une charge stable est moins chère sur des conteneurs/VMs réservées
- Processus longs -- la facturation à la milliseconde s'accumule pour des exécutions de 10+ min
- Charges à haute mémoire -- le prix Lambda augmente linéairement avec l'allocation mémoire
- Architectures bavardes -- beaucoup de petits appels inter-fonctions multiplient les coûts
Exemple chiffré : un faible trafic favorise Lambda (prix publics approximatifs us-east-1, vérifiez les pages de tarification)
tadataExtrait de la fiche « Serverless on AWS: Start Here » · Demander la fiche complète