Skip to main content

Serverless sur AWS

Introduction au Serverless

Glossaire

●

  • Serverless: Modèle d'exécution où le cloud gère l'infrastructure
    ●
  • Lambda: Service AWS de compute serverless (fonctions as a service)
    ●
  • API Gateway: Service AWS pour créer et gérer des API
    ●
  • DynamoDB: Base de données NoSQL serverless d'AWS
    ●
  • SAM: Serverless Application Model - framework IaC pour serverless
    ●
  • CloudFormation: Service AWS d'infrastructure as code
    ●
  • Cold Start: Délai au premier démarrage d'une fonction Lambda
    ●
  • Warm Start: Exécution d'une fonction Lambda déjà initialisée
    ●
  • IAM: Identity and Access Management - gestion des permissions AWS
    ●
  • CORS: Cross-Origin Resource Sharing - mécanisme de sécurité web

 

Introduction au Serverless

Qu'est-ce que le Serverless ?

Le serverless (ou "sans serveur") est un modèle d'exécution cloud où le fournisseur cloud gère automatiquement l'infrastructure. Contrairement au nom, il y a bien des serveurs, mais vous n'avez pas à les gérer, les configurer ou les maintenir

 

Caractéristiques principales

● Pas de gestion de serveurs: Pas besoin de provisionner, configurer ou maintenir des serveurs
● Mise à l'échelle automatique: Le système s'adapte automatiquement à la charge
● Facturation à l'usage: Vous ne payez que pour les ressources réellement consommées
● Haute disponibilité: Gérée automatiquement par le fournisseur cloud
● Focus sur le code métier: Concentrez-vous sur votre logique applicative

 

Avantages et inconvénients

avantage inconvénient
Réduction des coûts opérationnels (pas de serveurs à maintenir)
 Cold start : temps de démarrage lors de la première invocation
Time-to-market plus rapide (déploiement simplifié) Limites d'exécution (timeout, mémoire, taille du package)
Scalabilité automatique et transparente Dépendance au fournisseur cloud (vendor lock-in)
Paiement à la consommation réelle Débogage plus complexe
Résilience et haute disponibilité natives Coûts potentiellement élevés avec un trafic très important et constant

Services AWS Serverless

AWS Lambda

AWS Lambda est le service de computing serverless d'AWS. Il exécute votre code en réponse à des événements et gère automatiquement les ressources de calcul.

 

fonctions et concepts clés

● Fonction Lambda: Unité de code qui s'exécute en réponse à un événement
● Runtime: Environnement d'exécution (Python, Node.js, Java, Go, .NET, etc.)
● Événement: Déclencheur qui invoque la fonction (API Gateway, S3, DynamoDB, etc.)
● Contexte: Informations sur l'environnement d'exécution
● Handler: Point d'entrée de votre fonction

 

Modèle de facturation

Lambda facture selon deux critères :
● Nombre de requêtes : 0,20$ par million de requêtes
● Durée d'exécution : calculée en Go-secondes (mémoire × temps)
● Free Tier : 1 million de requêtes gratuites et 400 000 Go-secondes par mois

 

Limites importantes

Timeout maximum : 15 minutes (900 secondes)
Mémoire : 128 MB à 10 240 MB
Taille du package déployé : 50 MB (zippé), 250 MB (dézippé)
Variables d'environnement : 4 KB
Concurrence : 1000 exécutions simultanées par défaut (augmentable)
Stockage /tmp : 512 MB à 10 240 MB

 

Anatomie d'une fonction Lambda

exemple en python 
import json

def lambda_handler(event, context):
    """
    Point d'entrée de la fonction Lambda
    
    Args:
        event: Données de l'événement déclencheur (dict)
        context: Informations sur le contexte d'exécution
    
    Returns:
        dict: Réponse avec statusCode et body
    """
    
    # Récupération des paramètres de l'événement
    name = event.get('name', 'World')
    
    # Logique métier
    message = f"Hello, {name}!"
    
    # Retour de la réponse
    return {
        'statusCode': 200,
        'headers': {
            'Content-Type': 'application/json'
        },
        'body': json.dumps({
            'message': message
        })
    }

Amazon API Gateway

Amazon API Gateway est un service entièrement géré qui permet de créer, publier, maintenir, surveiller et sécuriser des API REST, HTTP et WebSocket à n'importe quelle échelle.

 

types d'API

● REST API : API RESTful complètes avec toutes les fonctionnalités
● HTTP API : API optimisées pour les performances et le coût (recommandé pour la plupart des cas)
● WebSocket API : pour les communications bidirectionnelles en temps réel

 

Concepts importants

● Resource: Chemin URL (ex: /tasks, /tasks/{id})
● Method: Verbe HTTP (GET, POST, PUT, DELETE, etc.)
● Integration: Backend connecté (Lambda, HTTP, AWS Service)
● Stage: Environnement de déploiement (dev, staging, prod)

● Deployment: Snapshot de votre API à un instant donné

 

Workflow d'une requête API Gateway

Voici le parcours d'une requête HTTP dans API Gateway :
1. Le client envoie une requête HTTP à l'URL de l'API
2. API Gateway reçoit la requête et applique les validations
3. Les autorisations sont vérifiées (IAM, Cognito, Lambda Authorizer)
4. La requête est transformée si nécessaire (mapping template)
5. Le backend (Lambda) est invoqué avec les données transformées
6. La réponse du backend est transformée si nécessaire
7. API Gateway renvoie la réponse HTTP au client

 

CORS (Cross-Origin Resource Sharing)

CORS est essentiel pour permettre aux applications web frontend d'appeler votre API. Sans CORS, les navigateurs bloquent les requêtes cross-origin par sécurité.

{
    "statusCode": 200,
    "headers": {
        "Access-Control-Allow-Origin": "*",  // ou domaine spécifique
        "Access-Control-Allow-Headers": "Content-Type,X-Amz-Date,Authorization",
        "Access-Control-Allow-Methods": "GET,POST,PUT,DELETE,OPTIONS"
    },
    "body": JSON.stringify(data)
}

Activez CORS directement dans la console API Gateway pour générer automatiquement les méthodes OPTIONS et les headers appropriés. C'est plus simple que de les configurer manuellement !

 

Amazon DynamoDB

Amazon DynamoDB est une base de données NoSQL clé-valeur et orientée document, entièrement gérée et offrant des performances prévisibles à n'importe quelle échelle.

 

Caractéristiques principales

● Performances constantes : latence en millisecondes à un chiffre
● Scalabilité automatique : s'adapte automatiquement au trafic
● Haute disponibilité : réplication multi-AZ automatique
● Sécurité intégrée : chiffrement at-rest et in-transit
● Modèle de données flexible : schéma adaptable

 

Concepts clés

● Table: Conteneur pour les données (équivalent d'une table SQL)
● Item: Enregistrement individuel (équivalent d'une ligne SQL)
● Attribut: Champ de données (équivalent d'une colonne SQL)
● Partition Key (PK): Clé primaire obligatoire qui détermine le partitionnement
● Sort Key (SK): Clé de tri optionnelle pour ordonner les items d'une partition
● Index secondaire: Permet d'interroger sur d'autres attributs

 

Opérations CRUD avec boto3

import boto3
from boto3.dynamodb.conditions import Key
import uuid
from datetime import datetime

# Initialisation du client DynamoDB
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Tasks')

# CREATE - Créer un item
def create_task(title, description):
    """Crée une nouvelle tâche dans DynamoDB"""
    task = {
        'taskId': str(uuid.uuid4()),  # Génère un ID unique
        'title': title,
        'description': description,
        'status': 'pending',
        'createdAt': datetime.now().isoformat()
    }
    
    # Put item dans la table
    table.put_item(Item=task)
    return task

# READ - Lire un item par clé primaire
def get_task(task_id):
    """Récupère une tâche par son ID"""
    response = table.get_item(
        Key={'taskId': task_id}
    )
    return response.get('Item')

# UPDATE - Mettre à jour un item
def update_task(task_id, status):
    """Met à jour le statut d'une tâche"""
    response = table.update_item(
        Key={'taskId': task_id},
        UpdateExpression='SET #status = :status',
        ExpressionAttributeNames={
            '#status': 'status'  # 'status' est un mot réservé
        },
        ExpressionAttributeValues={
            ':status': status
        },
        ReturnValues='ALL_NEW'
    )
    return response.get('Attributes')

# DELETE - Supprimer un item
def delete_task(task_id):
    """Supprime une tâche"""
    table.delete_item(
        Key={'taskId': task_id}
    )
    return {'deleted': True}

Évitez les SCAN autant que possible ! Préférez les Query avec partition key. Les SCAN lisent toute la table et sont très coûteux. Utilisez des index secondaires globaux (GSI) pour interroger sur d'autres attributs que la clé primaire.

 

AWS SAM (Serverless Application Model)

AWS SAM est un framework open-source pour construire des applications serverless. Il étend AWS CloudFormation avec une syntaxe simplifiée pour définir des fonctions Lambda, des API, des tables DynamoDB et plus encore.

 

Avantages de SAM

● Infrastructure as Code : versionnez votre infrastructure avec votre code
● Syntaxe simplifiée : moins verbeux que CloudFormation pur
● Déploiement automatisé : une commande pour tout déployer
● Tests locaux : testez vos fonctions Lambda en local avec sam local
● CI/CD ready : s'intègre facilement dans vos pipelines
● Rollback automatique : annule les déploiements en cas d'échec

 

Structure d'un projet SAM

my-serverless-app/
├── template.yaml          # Template SAM principal
├── samconfig.toml         # Configuration du déploiement
├── src/
│   ├── create_task/       # Fonction Lambda
│   │   ├── app.py
│   │   └── requirements.txt
│   ├── get_tasks/
│   │   └── app.py
│   └── ...
└── events/                # Événements de test
    └── event.json

Commandes SAM essentielles

# Initialiser un nouveau projet SAM
sam init

# Construire l'application
sam build

# Tester localement une fonction
sam local invoke CreateTaskFunction -e events/create-event.json

# Démarrer une API locale
sam local start-api

# Valider le template
sam validate

# Déployer l'application
sam deploy --guided  # première fois
sam deploy           # déploiements suivants

# Supprimer l'application
sam delete

Comparaison Console vs SAM

critère console AWS SAM / IaaC

Temps initial

Rapide (clics) Plus long (code)

Reproductibilité

Faible                Excellente

Versioning                

impossible git natif

Multi-environnements   

difficile  facile

doc

manuelle auto documenté

erreurs humaines

fréquentes réduites

CI/CD

complexe simple

apprentissage

facile moyen

Bonnes pratiques serverless

    Gardez les fonctions légères: Une fonction = une responsabilité Utilisez les variables d'environnement: Pas de secrets en dur dans le code Gérez les timeouts: Définissez des timeouts appropriés Activez les logs: CloudWatch Logs pour le debugging Optimisez les cold starts: Minimisez les dépendances Utilisez des layers Lambda: Partagez le code commun Testez en local: sam local avant de déployer Surveillez les coûts: CloudWatch + Cost Explorer Implémentez le retry: Gestion robuste des erreurs Documentez votre API: OpenAPI/Swagger specs
    Back to top