Introduction au serverless (AWS Lambda, Google Cloud Functions, Azure Functions)

Le paradigme Serverless : Exécuter du code sans serveur

Le terme "serverless" peut sembler contre-intuitif, car il y a bien sûr toujours des serveurs quelque part ! Cependant, ce paradigme fait référence à une approche de développement et d'exécution d'applications où le développeur n'a plus besoin de provisionner, gérer ou maintenir l'infrastructure serveur sous-jacente. La responsabilité de la gestion des serveurs, du système d'exploitation, de la mise à l'échelle, du patching et de la disponibilité est entièrement déléguée au fournisseur de services cloud.

Au coeur du serverless se trouve le modèle FaaS (Function as a Service). Au lieu de déployer une application monolithique ou des microservices qui tournent en permanence sur des serveurs ou dans des conteneurs, vous déployez des unités de code plus petites et indépendantes : des fonctions. Ces fonctions sont conçues pour exécuter une tâche spécifique en réponse à un événement.

Les caractéristiques clés du FaaS sont :

• Piloté par les événements (Event-Driven) : Les fonctions ne s'exécutent que lorsqu'elles sont déclenchées par un événement spécifique (une requête HTTP, un message dans une file d'attente, une modification dans une base de données, un upload de fichier, une tâche planifiée, etc.).
• Sans état (Stateless) : Chaque invocation d'une fonction est généralement indépendante des précédentes. L'état doit être géré à l'extérieur de la fonction, via des bases de données, des caches ou d'autres services.
• Mise à l'échelle automatique et instantanée : La plateforme cloud gère automatiquement la mise à l'échelle du nombre d'instances de fonction en fonction de la charge, de zéro à potentiellement des milliers d'invocations parallèles.
• Paiement à l'usage (Pay-per-execution) : Vous ne payez que pour le temps d'exécution réel de vos fonctions (souvent à la milliseconde près) et le nombre d'invocations, au lieu de payer pour des serveurs qui tournent en continu, même lorsqu'ils sont inactifs.

Cette approche transforme la façon dont les applications sont conçues, développées et déployées, en permettant aux équipes de se concentrer davantage sur la logique métier plutôt que sur l'infrastructure.

Les géants du FaaS : Lambda, Cloud Functions et Azure Functions

Les principaux fournisseurs de cloud proposent tous des offres FaaS robustes, qui constituent la pierre angulaire de leurs écosystèmes serverless :

AWS Lambda (Amazon Web Services) : C'est le service FaaS pionnier et le plus mature du marché. Lambda s'intègre profondément avec l'écosystème AWS. Les fonctions peuvent être déclenchées par plus de 200 services AWS, notamment API Gateway (pour créer des API RESTful), S3 (événements sur les fichiers), DynamoDB (changements de données), SQS (files de messages), EventBridge (bus d'événements), ou des planificateurs (CloudWatch Events). Il supporte nativement Node.js, Python, Java, Go, Ruby, C# (.NET Core) et permet d'apporter des runtimes personnalisés.

Google Cloud Functions (GCP) : L'offre FaaS de Google Cloud. Elle s'intègre étroitement avec les services GCP comme Cloud Storage, Pub/Sub (messagerie), Firestore (base de données NoSQL), HTTP(S) via des points de terminaison directs ou API Gateway, et Cloud Scheduler. Cloud Functions supporte Node.js, Python, Go, Java, .NET Core, Ruby et PHP. Il se distingue par sa simplicité de déploiement et son modèle de scaling rapide.

Azure Functions (Microsoft Azure) : Le service FaaS de Microsoft Azure. Il offre une grande flexibilité avec divers modèles d'hébergement (Plan Consommation pour le paiement à l'usage, Plan Premium pour éviter les cold starts, Plan App Service pour des ressources dédiées). Azure Functions propose un large éventail de déclencheurs (HTTP, Blob Storage, Queue Storage, Service Bus, Event Grid, Cosmos DB, Timers) et de liaisons (bindings) qui simplifient l'interaction avec d'autres services Azure. Il supporte C#, JavaScript (Node.js), F#, Java, PowerShell, Python et TypeScript.

Bien que les concepts de base soient similaires, chaque plateforme a ses spécificités en termes d'intégrations, de limites (temps d'exécution, taille de payload), de modèle de tarification détaillé, et d'outillage. Le choix dépend souvent de l'écosystème cloud existant de l'entreprise ou des préférences de l'équipe.

Pourquoi le Serverless est attractif pour les développeurs Node.js

Node.js est un choix particulièrement populaire et pertinent pour le développement serverless. Son modèle événementiel et non bloquant s'aligne bien avec la nature éphémère et événementielle des fonctions FaaS. Les temps de démarrage rapides de Node.js (comparés à certains autres runtimes comme Java) sont un atout pour minimiser l'impact des "cold starts".

La scalabilité automatique inhérente au FaaS est un avantage majeur pour les applications Node.js. Plutôt que de devoir gérer manuellement le clustering ou la mise à l'échelle horizontale de serveurs Node.js pour gérer la charge, la plateforme FaaS s'en charge, en lançant autant d'instances parallèles de votre fonction que nécessaire pour traiter les événements entrants.

Le modèle de coût basé sur l'exécution peut être très avantageux, surtout pour les applications avec un trafic variable ou intermittent. Payer uniquement lorsque le code s'exécute peut entraîner des économies significatives par rapport à des serveurs ou des conteneurs constamment actifs. Cela rend le serverless idéal pour les API, les backends mobiles, le traitement de données en temps réel, les tâches planifiées, les chatbots, et bien d'autres cas d'usage.

En déchargeant la gestion de l'infrastructure, le serverless permet aux développeurs Node.js de se concentrer sur l'écriture du code métier et de livrer de la valeur plus rapidement. Le déploiement d'une fonction est souvent plus simple et rapide que le déploiement d'une application complète sur un serveur ou un cluster de conteneurs.

Défis et points d'attention du modèle Serverless

Malgré ses nombreux avantages, le modèle serverless présente également des défis et des aspects à considérer attentivement. Les "cold starts" sont l'un des plus connus : lorsqu'une fonction n'a pas été invoquée depuis un certain temps, la plateforme peut désallouer ses ressources. La première invocation suivante subira alors une latence supplémentaire, le temps de provisionner un nouvel environnement et de charger le code. Bien que des stratégies existent pour atténuer ce phénomène (fonctions pré-chauffées, optimisation du code), cela reste une considération importante pour les applications sensibles à la latence.

Les plateformes FaaS imposent certaines limitations : durée maximale d'exécution (quelques minutes en général), taille maximale du paquet de déploiement, taille des requêtes/réponses, nombre maximum d'exécutions concurrentes (souvent configurable). Il est crucial de connaître ces limites pour s'assurer que le cas d'usage est compatible avec le modèle FaaS.

La nature stateless des fonctions signifie que la gestion de l'état (sessions utilisateur, données transactionnelles) doit être externalisée vers d'autres services (bases de données, caches, systèmes de fichiers distribués). Cela peut complexifier l'architecture par rapport à une application stateful traditionnelle.

Le monitoring et le débogage d'applications distribuées composées de nombreuses petites fonctions peuvent être plus complexes. Il faut s'appuyer sur des outils de logging centralisé, de tracing distribué et de monitoring spécifiques au serverless pour comprendre le flux d'exécution et diagnostiquer les problèmes.

Enfin, bien que le serverless favorise la modularité, il peut aussi introduire une dépendance plus forte vis-à-vis des services spécifiques du fournisseur cloud (vendor lock-in). Concevoir des fonctions avec des interfaces claires et potentiellement utiliser des frameworks agnostiques (comme le Serverless Framework) peut aider à mitiger ce risque, bien qu'une migration complète reste souvent un effort non négligeable.