Tu as entendu le terme « serverless » des centaines de fois. Et à chaque fois quelqu’un précise : « ça ne veut pas dire qu’il n’y a pas de serveurs. » Exact. Les serveurs existent, mais ce n’est plus ton problème. AWS les gère, les scale, les patche — et tu paies seulement quand ton code s’exécute vraiment. Zéro trafic ? Zéro coût.
Dans les articles précédents on a parlé de la migration d’une app classique (React + Node.js + PostgreSQL + Redis) sur EC2 avec Auto Scaling et du zero-downtime deployment. Là on explore l’alternative radicale : et si tu enlevais complètement les serveurs de l’équation ?
C’est quoi le serverless, concrètement ?
Serverless, ça veut dire que tu écris des fonctions (des bouts de code) qui s’exécutent en réaction à des événements — une requête HTTP, un fichier uploadé sur S3, un message dans une file SQS, un changement en base. Tu ne provisionnes pas de serveurs, tu ne configures pas d’Auto Scaling Groups, tu ne penses pas à la RAM des instances.
Sur AWS, l’écosystème serverless repose sur quelques services clés :
AWS Lambda — le moteur de compute. Tu écris une fonction (Node.js, Python, Java, Go, etc.), tu la déploies, et Lambda l’exécute à chaque événement reçu. Scale automatiquement de zéro à des milliers d’exécutions simultanées.
API Gateway — la porte d’entrée. Reçoit les requêtes HTTP/HTTPS et les route vers les fonctions Lambda. Gère l’auth, le rate limiting, le versioning de l’API.
DynamoDB — la base serverless. NoSQL, entièrement managée, scale automatiquement, latence en millisecondes. Tu paies par requête et par Go stocké.
S3 + CloudFront — pour le front statique (React/Vue), comme en architecture classique.
SQS / SNS / EventBridge — pour la communication asynchrone entre fonctions.
À quoi ressemble le code d’une fonction Lambda ?
Prenons un exemple concret. Un endpoint qui renvoie une liste de produits depuis DynamoDB :
// handler.js
const { DynamoDBClient } = require('@aws-sdk/client-dynamodb');
const { DynamoDBDocumentClient, ScanCommand } = require('@aws-sdk/lib-dynamodb');
const client = new DynamoDBClient({});
const docClient = DynamoDBDocumentClient.from(client);
exports.getProducts = async (event) => {
try {
const result = await docClient.send(
new ScanCommand({ TableName: 'Products' })
);
return {
statusCode: 200,
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(result.Items)
};
} catch (error) {
return {
statusCode: 500,
body: JSON.stringify({ error: 'Internal Server Error' })
};
}
};
La fonction reçoit un event (détails de la requête HTTP — path, headers, body, query params) et renvoie un objet avec statusCode, headers et body. C’est tout. Pas d’Express, pas de serveur qui écoute sur un port, pas de gestion de processus.
La différence fondamentale avec une app Node.js classique : pas de processus qui tourne en continu. La fonction « se réveille » à chaque requête, exécute le code et s’arrête. AWS garde un pool de conteneurs prêts pour limiter la latence (mais au premier appel après une période d’inactivité tu auras un « cold start » de 100–500 ms).
Comment on déploie ?
Le déploiement serverless n’a rien à voir avec EC2. Pas d’instances à mettre à jour, pas de rolling ou blue/green. Tu uploades le code, la nouvelle version est live.
Option 1 : AWS SAM (Serverless Application Model) — le framework le plus utilisé. Tu définis l’infra dans un fichier template.yaml :
# template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Globals:
Function:
Runtime: nodejs20.x
Timeout: 10
MemorySize: 256
Resources:
GetProductsFunction:
Type: AWS::Serverless::Function
Properties:
Handler: handler.getProducts
Events:
Api:
Type: HttpApi
Properties:
Path: /products
Method: get
Policies:
- DynamoDBReadPolicy:
TableName: Products
ProductsTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: Products
BillingMode: PAY_PER_REQUEST
AttributeDefinitions:
- AttributeName: id
AttributeType: S
KeySchema:
- AttributeName: id
KeyType: HASH
Déploiement en deux commandes :
sam build
sam deploy --guided
SAM pack le code, crée un stack CloudFormation, provisionne Lambda, API Gateway et DynamoDB — le tout depuis un seul fichier de config. Mise à jour ? Tu modifies le code ou le template et tu relances sam deploy.
Option 2 : Serverless Framework — alternative populaire avec beaucoup de plugins. Utilise serverless.yml au lieu de template.yaml, même principe.
Option 3 : AWS CDK (Cloud Development Kit) — pour ceux qui préfèrent définir l’infra en code (TypeScript, Python) plutôt qu’en YAML. Plus verbeux, mais plus flexible et plus facile à tester.
L’intégration CI/CD est simple. Dans GitHub Actions, un step qui lance sam build && sam deploy --no-confirm-changeset. Idem dans GitLab CI/CD. Plus besoin de CodeDeploy — SAM gère tout via CloudFormation.
Les vrais avantages du serverless
Zéro admin d’infra. Pas de serveurs à patcher, pas d’OS à mettre à jour, pas de config Nginx. L’équipe se concentre à 100 % sur le code.
Scale à zéro. Avec EC2, même avec Auto Scaling, tu paies au minimum 2 instances 24/7 (~67 $/mois). Avec Lambda, si personne n’appelle l’API, le coût est littéralement 0 $.
Paiement à l’exécution. Lambda : 0,20 $ par million de requêtes plus 0,0000166667 $ par Go-seconde de compute. Le free tier inclut 1 million de requêtes et 400 000 Go-secondes par mois — en permanence, pas seulement 12 mois.
Exemple de coût concret : une app avec 5 millions de requêtes/mois, chaque fonction en 256 Mo et 200 ms en moyenne, coûte environ 4–5 $/mois sur Lambda. La même sur EC2 avec ALB : au moins 90–100 $/mois.
Déploiement instantané. Tu uploades le code, Lambda le sert tout de suite. Pas de rolling update, pas de downtime. Tu peux utiliser alias et versions Lambda pour du canary deployment si tu veux.
Résilience intégrée. Lambda tourne automatiquement dans plusieurs Availability Zones. Si une zone tombe, le trafic part ailleurs. Rien à configurer.
Les inconvénients à connaître
Cold starts. Quand une fonction n’a pas été appelée depuis un moment, le premier appel peut prendre 100–500 ms de plus (ou plus pour Java). Solution : Provisioned Concurrency (fonctions préchauffées), mais ça coûte plus cher.
Limite 15 minutes. Une fonction Lambda ne peut pas tourner plus de 15 minutes. Les traitements longs doivent être découpés (Step Functions) ou déplacés sur ECS/EC2.
Timeout API Gateway : 29 secondes. Si la Lambda ne répond pas en 29 s via API Gateway, la requête timeout. Pour les opérations longues : pattern async — la fonction lance le traitement, renvoie un job ID, le client fait du polling.
Vendor lock-in. Le code Lambda est fortement couplé à l’écosystème AWS. Migrer vers un autre cloud demande un refactor important. Tu peux atténuer un peu avec des frameworks comme Serverless Framework qui abstractisent le provider.
Debug plus difficile. Pas de SSH sur un serveur pour voir ce qui se passe. Tu dépends de CloudWatch Logs, X-Ray pour le tracing, et des tests locaux avec SAM CLI (sam local invoke).
Complexité architecturale. Une app avec 50 fonctions Lambda, 10 files SQS et 5 tables DynamoDB peut être plus difficile à comprendre et déboguer qu’un seul serveur Node.js.
Serverless vs. EC2 : quand choisir quoi ?
Choisis serverless quand : le trafic est variable ou imprévisible (de 0 à des pics massifs), tu veux un time-to-market rapide, l’équipe est petite et ne veut pas gérer l’infra, l’app se découpe naturellement en fonctions indépendantes, ou le budget pour peu de trafic doit être minimal.
Choisis EC2/containers quand : tu as un trafic constant et prévisible (24/7 à forte charge), l’app a des processus long-running (websockets, traitement vidéo), tu as besoin d’un contrôle total sur l’environnement d’exécution, ou l’app existante est un monolithe qui ne se découpe pas facilement.
La variante hybride est souvent la plus pragmatique : front sur CloudFront + S3, API principale sur Lambda + API Gateway, mais traitements lourds en background sur ECS Fargate ou EC2. PostgreSQL reste sur RDS, Redis sur ElastiCache — tout n’a pas besoin d’être serverless.
De la théorie à la pratique
Pour tester le serverless sans te lancer dans une migration complète, commence par un seul endpoint. Crée une fonction Lambda avec SAM, connecte-la à API Gateway et observe le comportement. Le free tier AWS couvre largement l’expérimentation.
Le premier pas le plus naturel : déplacer le traitement asynchrone sur Lambda. Envoi d’emails, génération de PDF, traitement d’images, cron jobs — tous sont de bons candidats. Le backend principal peut rester sur EC2, Lambda prend en charge les tâches qui n’ont pas besoin de répondre de façon synchrone.
Le serverless n’est pas « tout ou rien ». C’est un outil de plus dans ta boîte — très puissant quand il est utilisé dans le bon contexte.
Publié sur teninvent.ro — TEN INVENT S.R.L. propose du conseil et de l’implémentation de solutions serverless sur AWS. Contacte-nous pour évaluer si le serverless convient à ton application.