Aws Lambda
Serverless event-driven computing.
AWS Lambda est un service de calcul serverless et événementiel fourni par Amazon Web Services (AWS). Il permet aux développeurs d'exécuter du code sans avoir à provisionner ou gérer de serveurs. Les développeurs téléchargent leur code sous forme de fonctions Lambda, et AWS gère automatiquement l'infrastructure nécessaire pour exécuter et faire évoluer ce code avec une haute disponibilité. Les fonctions sont déclenchées par divers événements, tels que des modifications de données dans un bucket Amazon S3, des mises à jour d'une table Amazon DynamoDB, ou des requêtes [API Gateway](/fr/terms/api-gateway). Lorsqu'un déclencheur se produit, Lambda exécute la fonction, allouant les ressources de calcul nécessaires. La facturation est basée sur le nombre de requêtes et la durée/mémoire consommée pendant l'exécution, avec un généreux niveau gratuit. Les fonctionnalités clés incluent la mise à l'échelle automatique, des environnements d'exécution sans état (bien que l'état puisse être géré en externe), la prise en charge de plusieurs langages de programmation (Node.js, Python, Java, C#, Go, Ruby, PowerShell et runtimes personnalisés), et l'intégration avec une vaste gamme de services AWS. Les fonctions Lambda sont généralement de courte durée, conçues pour des tâches spécifiques plutôt que pour des applications de longue durée. Les compromis incluent les démarrages à froid potentiels (latence lorsqu'une fonction n'a pas été invoquée récemment), les limites de temps d'exécution, les limitations de mémoire et de stockage temporaire, et le verrouillage fournisseur dans l'écosystème AWS. C'est idéal pour le traitement d'événements, les microservices, la transformation de données et les API backend.
graph LR
Center["Aws Lambda"]:::main
Rel_api_gateway["api-gateway"]:::related -.-> Center
click Rel_api_gateway "/terms/api-gateway"
Rel_microservices["microservices"]:::related -.-> Center
click Rel_microservices "/terms/microservices"
Rel_serverless["serverless"]:::related -.-> Center
click Rel_serverless "/terms/serverless"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Test de connaissances
🧒 Explique-moi comme si j'avais 5 ans
Pensez à AWS Lambda comme à un chef cuisinier magique qui ne cuisine que lorsque vous demandez un plat spécifique (un événement se produit). Vous donnez la recette (votre code) au chef, et il la cuisine instantanément en utilisant les bons outils, vous facturant uniquement le temps passé à cuisiner.
🤓 Expert Deep Dive
AWS Lambda fonctionne sur un modèle d'exécution basé sur des conteneurs. Lorsqu'une fonction est invoquée, Lambda provisionne un micro-conteneur, charge le code de la fonction et l'exécute. Pour les fonctions rarement invoquées, cette étape de provisionnement introduit une latence de 'démarrage à froid'. Les invocations ultérieures dans un court laps de temps réutilisent le conteneur existant ('démarrage à chaud'), réduisant considérablement la latence. Les fonctions Lambda sont intrinsèquement sans état ; tout état requis doit être persisté en externe (par exemple, dans DynamoDB, S3, RDS). Le modèle de concurrence permet à plusieurs instances d'une fonction de s'exécuter en parallèle, géré par AWS pour répondre à la demande jusqu'aux limites de concurrence au niveau du compte. La concurrence provisionnée peut être utilisée pour atténuer les démarrages à froid pour les applications sensibles à la latence en maintenant au chaud un nombre spécifié d'environnements d'exécution. La sécurité est gérée via des rôles IAM, accordant aux fonctions des autorisations granulaires pour accéder à d'autres ressources AWS. Le mécanisme de mappage de source d'événements permet à Lambda d'interroger les sources d'événements (comme les flux Kinesis) et d'invoquer des fonctions avec des lots d'enregistrements. Les considérations architecturales incluent l'optimisation de l'allocation mémoire de la fonction (qui affecte également l'allocation CPU), la gestion des dépendances et la conception pour l'idempotence en raison des tentatives potentielles.