Charges de travail .NET sur AWS Lambda

Avant de parler de l'informatique sans serveur, abordons un instant l'informatique traditionnelle.

De nombreuses entreprises, petites et grandes, utilisent des serveurs sur site ou des serveurs basés sur des centres de données pour exécuter leurs applications. Lorsque ces entreprises ont besoin de plus de serveurs, elles doivent les acheter, les installer physiquement, les configurer, les sécuriser et les entretenir. (Dans certains cas, un centre de données peut se charger de les installer physiquement en votre nom, mais vous devez tout de même faire le reste.)

Lorsque tout cela est fait, l'entreprise peut déployer ses applications sur ces serveurs. Pour de nombreuses entreprises, cela peut prendre des semaines, voire des mois. Ces retards ont toujours rendu difficile la mise à l'échelle des applications.

Le cloud computing a largement facilité cette tâche. Une entreprise peut lancer une instance d'un serveur (ou plusieurs instances) en quelques minutes. L'entreprise peut créer ses propres images de machine en configurant la machine virtuelle et le système d'exploitation comme elle le souhaite. Cela réduit la quantité de configuration requise une fois le serveur lancé, mais ils doivent tout de même maintenir le serveur à jour avec des correctifs, des mises à jour de sécurité et des mises à jour logicielles, etc.

Dans de nombreux cas, ces serveurs fonctionnent 24 heures sur 24, 7 jours sur 7, même s'ils ne sont pas utilisés pendant tout ce temps. Les serveurs sont souvent provisionnés pour gérer le pic de charge de travail attendu par l'application. Mais en dehors de ce pic, les serveurs sont au moins partiellement inactifs. Des politiques de dimensionnement appropriées peuvent être utilisées pour réduire l'aide apportée à ce problème, mais cela peut être difficile à mettre en œuvre.

En outre, le travail de provisionnement et de maintenance des serveurs, ainsi que le temps qu'ils passent inactifs, entraînent des coûts qui ne profitent pas directement à l'entreprise.
Une alternative à cela est l'informatique sans serveur. Il n'y a pas de serveurs, il n'y a pas de maintenance et la mise à l'échelle est prise en charge pour vous. Vous rédigez votre code, vous le déployez et vous laissez AWS gérer l'infrastructure pour vous.

AWS propose deux options pour l'informatique sans serveur : AWS Fargate pour les applications basées sur des conteneurs et AWS Lambda pour les applications pilotées par des événements.

AWS Lambda est un service de calcul sans serveur qui exécute votre code en réponse aux événements reçus par le service. Les événements peuvent être générés par d'autres services AWS, tels que SNS, SQS, S3, DynamoDB, API Gateway, etc.

L'utilisation d'un API Gateway, ou d'URL de fonction Lambda vous permet de déclencher l'exécution d'une fonction Lambda en réponse à une requête HTTP. Les fonctions Lambda peuvent également être invoquées directement, bien que cela soit également considéré comme un événement.

Vous n'avez pas besoin de provisionner d'infrastructure pour utiliser AWS Lambda. AWS se charge également de la mise à l'échelle automatique pour répondre aux besoins de votre application, qu'il s'agisse de quelques exécutions par jour ou de dizaines de milliers par seconde. L'infrastructure Lambda, gérée par AWS, est hautement disponible et tolérante aux pannes.

Avec les fonctions Lambda, vous ne payez que pour les ressources de calcul que vous utilisez. Lorsque votre code n'est pas exécuté, vous ne payez pas.

Vous écrivez vos applications .NET à l'aide des IDE que vous connaissez déjà, puis à l'aide des outils AWS (ou d'un IaC de votre choix), vous déployez votre application sur AWS Lambda.

Lorsqu'une fonction Lambda est invoquée par un événement, un environnement d'exécution est créé, votre code d'initialisation est exécuté (constructeurs, etc.), puis votre code pour gérer l'événement est exécuté.

Une fois l'exécution terminée, l'environnement d'exécution reste disponible pour être réutilisé pendant une période non déterministe.

Si un autre événement arrive, le même environnement d'exécution est utilisé et le code d'initialisation n'est pas réexécuté.

Si aucun environnement d'exécution n'est disponible, un nouvel environnement est créé et le code d'initialisation est de nouveau exécuté.

Les fonctions AWS Lambda fournissent actuellement des environnements d'exécution gérés pour .NET Core 3.1 et .NET 6. Si vous souhaitez écrire des applications dans d'autres versions de .NET, vous pouvez utiliser des environnements d'exécution personnalisés Lambda ou une version basée sur un conteneur de votre application.

AWS fournit des modèles de projet C# et F# pour les fonctions Lambda. Ils peuvent être utilisés à partir de la ligne de commande, de Visual Studio, de Visual Studio Code et de Rider.

Vous pouvez exécuter votre fonction .NET Lambda sur des processeurs x86_64 et arm64. Le choix de l'architecture du processeur n'a aucune incidence sur la façon dont vous écrivez vos applications. Le déploiement sur le processeur de votre choix se fait simplement en modifiant un seul paramètre de configuration.

Vous n'avez pas besoin d'apprendre un nouveau langage. Utilisez vos connaissances actuelles en C# et F# pour écrire vos fonctions Lambda.

Vous pouvez utiliser les fonctions Lambda avec d'autres services AWS, tels que SNS, SQS, S3, Step Functions et DynamoDB, pour créer des applications pilotées par des événements. Ou effectuez des tâches personnalisées en réponse à des événements provenant de ces services.

Si vous devez orchestrer l'exécution de plusieurs fonctions Lambda, vous pouvez utiliser AWS Step Functions. Avec Step Functions, vous créez une machine à états qui gère l'exécution de vos fonctions Lambda.

Vous n'avez pas besoin de prévoir ni de gérer une infrastructure dédiée. AWS s'occupe de tout cela pour vous. Il vous suffit de décider de l'architecture du processeur et de la quantité de mémoire à allouer à la fonction. En fonction de votre choix de mémoire, AWS choisira la vitesse du processeur, la bande passante du réseau et les E/S disque appropriées.

Vos fonctions Lambda sont hautement disponibles et tolérantes aux pannes, et s'exécutent dans plusieurs zones de disponibilité de chaque région.

Les fonctions AWS Lambda démarrent quelques millisecondes après l'arrivée d'un événement et peuvent évoluer rapidement et automatiquement en fonction du volume d'événements entrants.

Vous ne payez que ce que vous consommez, et cela est facturé à la milliseconde d'utilisation.

Lambda propose un niveau généreux et toujours gratuit, qui vous permet d'exécuter un million de requêtes gratuites par mois et de consacrer 400 000 Go-secondes de temps de calcul par mois

Si vous avez des modèles de trafic en rafale, Lambda s'adapte à ces besoins, et lorsque le trafic diminue, vous ne payez pas pour les ressources dont vous n'avez plus besoin.

Lambda fait partie des Compute Savings Plans, qui proposent des prix plus bas en échange d'un engagement à utiliser un certain temps de calcul sur une période d'un à trois ans.

Dans la section suivante, vous découvrirez à quel point il est facile de démarrer avec AWS Lambda. En quelques minutes de travail, vous disposerez de deux fonctions .NET AWS Lambda exécutées dans le cloud

Durée estimée : 30 minutes

Veuillez noter que vous pouvez suivre les exemples présentés ici, mais ce n'est pas obligatoire.

Si vous n'avez jamais travaillé avec la technologie sans serveur, cela peut sembler intimidant au premier abord. Même savoir par où commencer peut être difficile à comprendre.

À la fin de ce court module, deux fonctions .NET Lambda seront opérationnelles sur AWS.

L'un est invoqué depuis la ligne de commande, l'autre via un point de terminaison HTTPS public que vous configurerez pratiquement sans effort.

Vous utiliserez la ligne de commande pour créer, construire et déployer les deux exemples.

Il s'agit de la fonction Lambda la plus basique que vous puissiez écrire. Elle nécessite quelques entrées et renvoie une réponse. Elle sera opérationnelle en quelques minutes.

Dans cette démonstration, vous allez créer une application API .NET qui gère les requêtes HTTPS. Vous pouvez utiliser le nouveau modèle d'API minimal ou l'ancien modèle d'API complet avec contrôleurs. Les étapes seront les mêmes. Si vous connaissez les instructions de haut niveau et les points de terminaison d'API .NET 6, pensez à utiliser le modèle minimal Serverless.AspNetCoreMinimalAPI. Si vous n'êtes pas familier avec les instructions de haut niveau, utilisez l'ancien modèle, Serverless.AspNetCoreWebAPI.