serverless-designer

name	serverless-designer
description	Conception d'architectures serverless couvrant Functions, event-driven, cold start et patterns avancés. Se déclenche avec "serverless", "functions as a service", "FaaS", "cold start", "event-driven serverless", "Azure Functions", "Lambda. Also triggers on "serverless architecture", "event-driven functions", "cold start optimization".

Serverless Designer

Workflow

1. Évaluer l'adéquation serverless

Appliquer la grille de décision avant tout design :

Critère	Serverless ✅	Conteneur/VM ❌
Durée d'exécution	< 15 min (Lambda), < 10 min (AZ Func)	Longue durée / streaming
Trafic	Très variable, spiky	Stable et prévisible
Cold start toléré	Oui (< 2 s acceptable)	Non (latence < 50 ms requise)
État local requis	Non	Oui (session, cache local)
Charge réseau	Faible à modérée	Très haute (> 10 K req/s en continu)

Si 3 critères ou plus sont dans la colonne droite, proposer un déploiement conteneurisé (ECS/AKS/Cloud Run).

2. Cartographier les déclencheurs

Lister tous les événements et associer chaque source à une fonction :

HTTP/REST      → API Gateway + Lambda / Azure APIM + Function
File upload    → S3 Event / Blob Trigger
Message queue  → SQS / Service Bus → fonction consumer
Timer/CRON     → EventBridge Scheduler / Timer Trigger
Stream         → Kinesis / Event Hub → fonction par batch
Auth event     → Cognito / AAD B2C → Pre/Post trigger

Documenter le schéma de l'événement d'entrée dès cette étape pour éviter les surprises au déploiement.

3. Découper les fonctions (SRP)

• 1 fonction = 1 responsabilité = 1 déclencheur
• Timeout explicite (ne jamais laisser le défaut)
• Taille de payload max définie (ex. 6 MB Lambda, 100 MB AZ Functions)
• Extraire la logique métier dans des modules testables indépendamment du handler

# Handler thin — délègue à un module testable
def handler(event, context):
    payload = parse_event(event)          # module pur
    result = process_order(payload)       # logique métier
    return format_response(result)        # module pur

4. Choisir plateforme et runtime

Comparatif 2026 rapide :

Plateforme	Runtime top	Timeout max	Cold start typique
AWS Lambda	Python 3.12, Node 22, Java 21	15 min	200 ms–1 s (SnapStart Java)
Azure Functions v4	.NET 8 Isolated, Node 20	10 min (Consumption)	300 ms–2 s
Google Cloud Functions 2nd gen	Python 3.12, Go 1.22	60 min	100–500 ms
Cloudflare Workers	JS/TS (V8 Isolates)	30 s CPU	< 5 ms (pas de cold start)

Cloudflare Workers = meilleur choix si latence critique et logique légère. AWS Lambda SnapStart = meilleur choix Java/JVM pour éliminer le cold start.

5. Gérer l'état et la persistance

Les fonctions sont stateless — tout état doit être externalisé :

Session courte     → ElastiCache (Redis) / Azure Cache for Redis
Données structurées → DynamoDB / Cosmos DB (mode serverless)
Fichiers           → S3 / Azure Blob Storage
État de workflow   → Step Functions / Durable Functions
Compteurs atomiques → DynamoDB atomic increment / Redis INCR

Pattern recommandé — idempotence :

# Utiliser un idempotency_key pour éviter les doubles traitements
def process(event):
    key = event["idempotency_key"]
    if cache.exists(key):
        return cache.get(key)
    result = do_work(event)
    cache.set(key, result, ttl=3600)
    return result

6. Optimiser le cold start

Techniques classées par impact :

1. Provisioned Concurrency (Lambda) / Premium Plan (AZ Func) — élimine le cold start sur les fonctions critiques

   aws lambda put-provisioned-concurrency-config \
     --function-name my-api \
     --qualifier prod \
     --provisioned-concurrent-executions 10
   

2. Réduire la taille du package — ne bundler que le strict nécessaire

   # Lambda — vérifier la taille réelle
   zip -r function.zip . --exclude "*.test.*" "node_modules/.cache/*"
   du -sh function.zip   # cible < 5 MB décompressé
   

3. Lazy loading des clients lourds — initialiser hors handler mais avec import paresseux

   _db_client = None
   def get_db():
       global _db_client
       if _db_client is None:
           _db_client = boto3.resource("dynamodb")
       return _db_client
   

4. SnapStart (Java Lambda) — snapshot post-init, restore ~100 ms

5. Cloudflare Workers / Fastly Compute — V8 Isolates, pas de cold start

7. Choisir le pattern d'orchestration

Séquence simple       → Step Functions Express / Durable Functions Activity Chain
Compensation (saga)   → Step Functions Standard + compensating transactions
Fan-out / fan-in      → SNS → N Lambdas → SQS aggregator
Longue durée          → Durable Functions Orchestrator (stateful)
Event choreography    → EventBridge / Event Grid (pas de coordinateur central)

Orchestration vs Choreography :

• Orchestration (Step Functions) : visibilité totale, debugging facile, couplage fort au moteur
• Choreography (EventBridge) : découplé, scalable, mais flux difficile à tracer → ajouter tracing distribué (X-Ray / OpenTelemetry)

8. Sécurité

- IAM least privilege par fonction (pas de AdministratorAccess)
- Secrets dans Secrets Manager / Key Vault — jamais en variable d'env plaintext
- VPC endpoint si accès RDS/interne (attention cold start accru ~500 ms)
- Validation du schéma d'entrée dès le handler (ex. Pydantic, Zod)
- Activer Lambda function URL auth type IAM si pas d'API Gateway

9. Observabilité

Triad minimal obligatoire :

• Logs structurés JSON avec correlation ID injecté depuis l'événement
• Métriques custom : durée métier, taux d'erreur, taille payload
• Tracing distribué : AWS X-Ray / Azure App Insights / OpenTelemetry

import json, logging
logger = logging.getLogger()
logger.setLevel("INFO")

def handler(event, context):
    logger.info(json.dumps({
        "correlation_id": event.get("headers", {}).get("x-correlation-id"),
        "action": "order_processing",
        "order_id": event["order_id"]
    }))

Garde-fous / Anti-patterns

Anti-pattern	Risque	Correction
Fonction monolithique (> 500 lignes)	Impossible à tester, cold start long	Découper par responsabilité
Appels synchrones chaînés (Lambda → Lambda direct)	Couplage fort, timeout cumulé	Passer par une queue SQS/SNS
Connexions DB ouvertes dans le handler	Pool épuisé, connexions orphelines	RDS Proxy / Cosmos serverless / client hors handler
Pas de DLQ sur les consumers async	Perte silencieuse de messages	DLQ systématique + alerte CloudWatch
Variables d'env avec secrets plaintext	Exposition dans logs/console	Secrets Manager + cache en mémoire
Timeout trop long sans circuit-breaker	Coût et latence incontrôlés	Timeout agressif + retry avec backoff exponentiel
Fan-out sans throttling	Throttling DynamoDB/RDS en aval	SQS batch + reserved concurrency

Bonnes pratiques 2026

• Adopt ARM64 (Graviton3 / Ampere) sur Lambda et Cloud Run — 20 % moins cher, souvent plus rapide
• Lambda function URLs remplacent souvent API Gateway pour les APIs simples (< 1 M req/jour)
• Azure Container Apps = alternative si > 10 min d'exécution nécessaire tout en gardant le modèle serverless
• Cold start budget : définir un SLO explicite (ex. p99 < 2 s) et monitorer via CloudWatch Insights
• Infrastructure as Code obligatoire : SAM (AWS), Bicep (Azure), Terraform pour la reproductibilité

  # Déploiement SAM
  sam build && sam deploy --guided
  
  # Azure Functions Core Tools
  func azure functionapp publish <app-name> --python
  

• Tests locaux avant déploiement : sam local invoke, func start, Vitest/Jest pour les handlers purs