Serverless - Serverless (Architecture Cloud sans Serveur & FaaS)

Par Amazon Web Services (AWS Lambda) · 2014 · Sources officielles vérifiées

DevOps & CloudDonnée vérifiée & sourcéeCloudAWSVercelFaaSLambdaScalabilité

En résumé

Modèle d'exécution cloud où le fournisseur alloue dynamiquement les ressources de calcul à la demande, facturant uniquement le temps d'exécution réel sans gestion manuelle de serveurs.

1. Définition détaillée & Contexte d'émergence

Le Serverless (ou architecture 'sans serveur') ne signifie pas l'absence physique de serveurs, mais le fait que l'infrastructure est complètement abstraite pour le développeur. Il s'incarne principalement à travers le Function-as-a-Service (FaaS, comme AWS Lambda, Vercel Serverless Functions, Cloudflare Workers). Les fonctions se réveillent sur réception d'un événement (requête HTTP, message dans une file, webhook), exécutent le code et s'éteignent aussitôt, avec une mise à l'échelle automatique de 0 à des milliers d'exécutions simultanées.

Pourquoi ce concept a été créé : Créé pour libérer les développeurs de la gestion des machines virtuelles (EC2), du provisionnement de serveurs et des configurations de clusters d'auto-scaling.

2. Piliers de l’Architecture Serverless

Un paradigme purement stateless et événementiel.

1. Stateless Execution (Sans état)

Les fonctions sont éphémères et ne doivent conserver aucun état local en mémoire entre deux requêtes : l'état est externalisé dans des bases de données ou caches distribués (Redis, PostgreSQL).

2. Scale to Zero (Mise à l’échelle à zéro)

Si aucune requête ne parvient au système, aucune ressource ne tourne et la facture de calcul s'élève à 0 $.

3. Gestion des Cold Starts

Délai d'initialisation (quelques dizaines à centaines de millisecondes) lorsqu'une nouvelle instance de conteneur doit être démarrée pour répondre à une requête entrante.

3. Caractéristiques fondamentales

  • Facturation à la milliseconde de calcul consommé (pay-per-use).
  • Mise à l’échelle automatique transparente face aux pics de trafic imprévus.
  • Maintenance zéro : OS, correctifs de sécurité et répartition de charge gérés par le cloud.
  • Intégration native dans les frameworks modernes comme Next.js sur Vercel.

5. Avantages et limites techniques

Points forts

  • ✓Coûts d’infrastructure dérisoires pour les projets en démarrage ou à trafic intermittent.
  • ✓Temps consacré à l’infrastructure réduit au minimum pour l’équipe de développement.

Points de vigilance

  • ⚠Cold starts perceptibles sur les fonctions peu sollicitées.
  • ⚠Connexions persistantes aux bases de données relationnelles nécessitant des proxys (Connection Pooling type Supabase/Prisma Accelerate).
  • ⚠Temps d’exécution maximum limité (ex: 15 minutes sur AWS Lambda, 60s sur Vercel Hobby).

6. Recommandations : Quand l'utiliser ?

Idéal pour :

  • APIs web, traitement d’événements asynchrones, webhooks, tâches en tâche de fond brèves.
  • Applications Next.js ou sites jamstack.

À éviter pour :

  • Tâches de calcul continu 24h/24 très intensives (où un serveur dédié ou conteneur Docker permanent revient moins cher).
  • WebSockets avec maintien de connexions persistantes longues (préférer des passerelles gérées ou serveurs dédiés).

8. Sources officielles vérifiées

Données techniques vérifiées auprès des documentations officielles, des RFCs et des spécifications standards.

CNCF Serverless WhitepaperCloud Native Computing Foundation (CNCF)