Les entreprises optent pour un architecture sans serveur. Il en résulte une délai de mise sur le marché plus court, réduit les coûts d'exploitation et les développeurs peuvent se concentrer sur l'amélioration des applications au lieu de gérer les infrastructures.
Si ce concept vous est nouveau, vous vous demandez peut-être : Qu'est-ce qu'une application sans serveur ? En gros, il s'agit d'un logiciel qui s'exécute dans un environnement où vous n'avez pas besoin de gérer de serveurs. L'hébergeur qui le fournit est entièrement responsable de la gestion de toutes les tâches d'infrastructure et opérationnelles.
AWS Lambda est l'une des solutions permettant de résoudre ce problème. Selon un rapport de Datadog, dans moins de 5 ans AWS Lambda est utilisé par la moitié des utilisateurs AWS et est plus fréquent dans les environnements les plus vastes.
En tant que stagiaire chez Imaginary Cloud, j'avais un projet en main : une application appelée Dwipper. Il s'agissait d'un réseau social permettant de partager des idées sur la douche (similaire à Twitter). J'avais besoin d'un backend prenant en charge toutes les opérations essentielles telles que l'authentification et le traitement des données. AWS Lambda pouvait fournir tout ce dont j'avais besoin pour le backend grâce à l'intégration des autres services proposés par AWS, tels que Cognito, API Gateway, DynamoDB, CloudWatch, CodeCommit et CodePipeline. Je n'ai même pas eu à me soucier de la gestion des serveurs. Mais avant de passer directement à l'application développée, je veux que vous compreniez ce qu'est AWS Lambda.
AWS Lambda, fourni par AWS (Amazon Web Services), est un service informatique sans serveur qui vous permet d'exécuter du code sans avoir à vous soucier de l'infrastructure ou de la gestion des serveurs. Le code exécuté sur AWS Lambda est appelé fonction Lambda et, une fois créé, il est prêt à être exécuté lorsqu'il est déclenché.
Cette fonction peut être associée à une ressource AWS spécifique. Par exemple AWS SNS (Simple Notification Service), qui est un service de messagerie. Dès que cette ressource change, Lambda exécute votre fonction et gère ce qui est nécessaire.
La première chose à faire est de créer un compte AWS. Si vous n'en avez pas, vous devez le configurer. Amazon IAM (Identity and Access Management) assure la gestion des utilisateurs et les autorisations dans AWS. Si vous travaillez en équipe, vous devrez peut-être créer un utilisateur IAM pour accorder les autorisations nécessaires à votre console AWS ou au cas où votre application aurait besoin d'effectuer des appels d'API vers AWS.
L'étape suivante consiste à configurez votre backend sans serveur, choisissez les services dont vous aurez besoin, configurez-les et enfin, pour créez votre dépôt Git afin que vous puissiez commencer à travailler sur votre application.
Vous pouvez maintenant commencer par écrire du code dans n'importe quelle langue prise en charge par AWS Lambda et le charger. Vous pouvez également écrire votre code dans l'éditeur de code fourni par Lambda. Vous configurez ensuite votre code pour qu'il soit déclenché à partir d'autres services AWS ou d'une activité intégrée à l'application. Lambda reçoit votre demande et exécute votre code uniquement lorsqu'il est déclenché.
AWS Lambda vous offre de nombreux avantages que vous devriez probablement connaître avant de choisir un autre service informatique sans serveur. Si vous vous êtes déjà posé la question pourquoi utiliser AWS Lambda, jetez un œil aux principaux avantages ci-dessous.
Pour le moment, AWS Lambda ne prend pas en charge tous les langages de programmation. Mais il prend en charge le code Java, Go, PowerShell, Node.js, C#, Python et Ruby. Pour chacun d'entre eux, AWS fournit un SDK qui vous permet d'écrire plus facilement vos fonctions Lambda et de les intégrer à d'autres services AWS. Il fournit également une API Runtime, qui vous permet d'utiliser n'importe quel langage de programmation supplémentaire pour créer vos fonctions.
Dans AWS, vous ne payez que pour le temps de calcul que vous consommez. Vous n'avez pas à payer pour le service pour héberger votre code. AWS Lambda vous facture plutôt en fonction de la date à laquelle ce code est exécuté. Vous êtes facturé en fonction du nombre de demandes et de leur durée, ce qui exclut les minutes de temps de serveur non utilisées.
Une fois que vos fonctions sont exécutées sur l'infrastructure AWS, celle-ci s'occupe des serveurs pour vous. Les développeurs ont ainsi plus de temps à consacrer à l'amélioration du produit au lieu d'effectuer des tâches opérationnelles telles que la gestion de la couche réseau ou l'évolutivité.
Imaginons que d'un moment à l'autre, votre application attire de nombreux nouveaux utilisateurs. Cela peut poser problème si le serveur n'est pas prêt à gérer un grand nombre de requêtes. Avec AWS Lambda, vous n'avez pas à vous en soucier, car l'application s'adapte précisément à la taille de la charge de travail. Il adapte automatiquement vos fonctions en fonction de leur demande, de sorte que les différentes parties de votre application peuvent évoluer différemment en fonction des niveaux d'utilisation actuels.
AWS Lambda s'intègre aux services AWS tels que DynamoDB, API Gateway, Cognito et bien d'autres. Chacun de ces services envoie des données à votre fonction au format JSON sous la forme d'un événement que les environnements d'exécution de Lambda convertissent d'abord en objet, puis les transmettent à votre fonction. Tout cela vous permet de créer une application entièrement fonctionnelle au sein de vos fonctions Lambda.
Comme toute autre plateforme informatique, AWS Lambda est mieux adaptée à certains scénarios en raison de ses caractéristiques. Tout d'abord, nous verrons dans quels scénarios il s'agirait d'un service informatique adapté, en vérifiant ce qu'était AWS Lambda, comme vous pouvez le voir ci-dessous :
Imaginez que vous disposez d'une application pour télécharger des photos et les redimensionner dans différentes tailles. Votre application stocke ces images dans un compartiment Amazon S3. Il existe donc probablement une fonction Lambda qui effectue ce travail de redimensionnement des images. Amazon S3 est l'une des sources d'événements AWS prises en charge. Elle permet de publier des événements créés par des objets et d'invoquer votre fonction Lambda. Tout cela est entièrement automatique et il n'y a aucun serveur à gérer. Le code de votre fonction Lambda peut lire l'objet image à partir du compartiment S3, créer la version redimensionnée et enfin l'enregistrer dans un autre compartiment S3.
Imaginez que vous créez une application contenant des données que vous devez stocker. Pour cela, vous pouvez utiliser DynamoDB, un service de base de données entièrement géré qui gère l'écriture, la mise à jour et la suppression d'éléments dans une table.
Imaginez que vous créez un site Web et que vous souhaitez héberger la connexion du backend sur Lambda. Lambda est excellent à cet égard, car l'interface Web peut envoyer des requêtes aux fonctions Lambda via des points de terminaison HTTP à l'aide d'Amazon API Gateway.
Tout comme les sites Web, Amazon API Gateway peut être utile pour les applications mobiles, mais cela ne s'arrête pas là. Vous pouvez créer, par exemple, une fonction Lambda pour traiter les clics au sein de votre application.
Outre les scénarios dans lesquels ce service convient le mieux, il est bon de garder à l'esprit les limites de Lambda et de déterminer s'il s'agit réellement du meilleur service à intégrer à votre produit.
Les fonctions sans serveur signifient que vous serez confronté à un temps de démarrage à froid. Lorsqu'une fonction est déclenchée, il peut y avoir un court laps de temps entre le début de l'appel et son exécution. Si cette fonction n'a pas été utilisée au cours des 15 dernières minutes, ce temps peut être très long, 5 secondes ou plus.
Il peut s'agir d'un problème potentiel à prendre en compte si vos charges de travail sont urgentes. Certaines solutions de contournement tentent de l'éviter, par exemple, gardez vos fonctions restreintes et concentrées, car les temps de démarrage à froid augmentent de façon linéaire en fonction de la taille de la mémoire et du code.
Les fonctions Lambda présentent certaines limites, telles que durée d'exécution, mémoire, taille et simultanéité. La durée maximale d'exécution d'une fonction est de 15 minutes, ce qui rend Lambda impropre aux charges de travail de longue durée. Si votre fonction prend généralement plus de 15 minutes, AWS Lambda n'est peut-être pas une bonne solution. La quantité de mémoire vive disponible pour les fonctions Lambda est comprise entre 128 Mo et 3 008 Mo, par incréments de 64 Mo. Il existe également une limite de 75 Go pour toutes les fonctions AWS Lambda qui ont été déployées. Pour éviter cette limite, veillez à ne pas conserver les anciennes versions de vos fonctions Lambda. Par défaut, l'exécution simultanée pour tous Les fonctions AWS Lambda au sein d'un seul compte AWS sont limitées à 1 000. Toute exécution Lambda déclenchée au-delà de cette limite sera obligée d'attendre que les autres fonctions aient fini de s'exécuter. Pour éviter cela, vous pouvez demander une augmentation de la limite en contactant le support AWS.
À première vue, le fait de ne payer que pour ce que vous consommez peut vous permettre de réaliser d'importantes économies, mais ce n'est peut-être pas le cas à chaque fois. Plusieurs facteurs déterminent le coût de vos fonctions Lambda et il n'est pas facile de déterminer ce coût.
Si la charge de votre application augmente, elle augmentera proportionnellement et pourrait s'avérer coûteuse. N'oubliez pas que tout autre service que vous décidez d'utiliser en plus de vos fonctions Lambda, comme API Gateway, CloudWatch ou tout autre service, augmentera ce coût. Vous devriez donc envisager dans quelle mesure vous pensez que votre application évoluera.
AWS Lambda n'est pas le seul service sans serveur que vous pouvez choisir pour votre projet. Sur ce sujet, vous pouvez voir d'autres alternatives à Lambda, très similaires à celle-ci. À quelques différences près, vous voudrez peut-être prendre en compte lors du choix du service sans serveur à utiliser.
AWS Lambda et Azure Functions prennent tous deux en charge Node.js, Python et C#, mais Azure Functions prend également en charge F# et PHP. Ils prennent également en charge la mise à l'échelle automatique.
AWS Lambda dispose d'un modèle de programmation simple, tandis qu'Azure Functions en possède une plus sophistiquée, basée sur des déclencheurs et des liaisons. Le système de reliure offre une flexibilité supplémentaire, mais il apporte également une certaine complexité. Les deux services peuvent exécuter simultanément plusieurs exécutions de la même fonction.
Si vous souhaitez ajouter une intégration HTTP, avec AWS Lambda, vous aurez un coût supplémentaire, comme nous l'avons déjà vu, vous payez pour des services supplémentaires. D'autre part, Azure Functions intègre les points de terminaison HTTP sans frais supplémentaires.
AWS Lambda et Google Cloud Functions prennent tous deux en charge Node.js, Python et Go. Lambda permet un nombre illimité de fonctions, tandis que Google Cloud Functions n'autorise que 1 000 fonctions par projet. Ils prennent également en charge la mise à l'échelle automatique.
En termes de temps d'exécution maximal d'une fonction, AWS Lambda garde une longueur d'avance avec six minutes de plus que Google Cloud Functions.
En ce qui concerne le paiement, tout comme AWS Lambda, avec Cloud Functions vous ne payez que pour le temps d'exécution de votre fonction. Vous n'êtes pas facturé lorsque votre fonction est inactive.
AWS Lambda et Kubernetes sont deux réalités différentes. Alors que Lambda vise à passer au mode sans serveur, Kubernetes est axé sur les conteneurs.
Sur AWS Lambda, vous ne gérez pas l'infrastructure et vous ne pouvez pas installer de logiciel supplémentaire. Sur Kubernetes, vous devez gérer l'infrastructure et vous pouvez installer des logiciels supplémentaires.
Ce ne sont là que quelques-unes des différences importantes et principales entre les deux. En conclusion, si vous souhaitez avoir contrôle complet de l'environnement, optez pour un service de conteneurs comme Kubernetes. Si tu veux quelque chose de plus gérable et concentrez-vous davantage sur l'amélioration du produit lui-même, vous devez choisir un service sans serveur tel que AWS Lambda.
AWS Cognito est un service de gestion de l'authentification. Vous pouvez ajouter un compte utilisateur et vous connecter rapidement et facilement. Il prend toujours en charge la connexion avec des fournisseurs d'identité sociale, tels qu'Amazon, Google et Facebook. Il fournit même une fonctionnalité de groupes d'utilisateurs pour vous aider à gérer les comptes utilisateurs.
Ce service Amazon gère toutes les tâches liées à l'acceptation et au traitement des appels d'API. Il permet aux développeurs de définir les points de terminaison HTTP et de les connecter au backend correspondant. API Gateway peut également valider si l'utilisateur est authentifié en ajoutant un autorisateur à un mappage de point de terminaison connecté à un groupe d'utilisateurs Cognito, ce qui signifie que seuls les utilisateurs du groupe d'utilisateurs peuvent accéder au point de terminaison.
AWS DynamoDB est une base de données entièrement gérée qui peut évoluer automatiquement et qui permet de créer des tables de base de données capables de stocker et de récupérer n'importe quelle quantité de données.
Cloudwatch est un service qui permet de surveiller toutes vos ressources, applications et services AWS qui s'exécutent sur AWS. Il collecte des données sous forme de journaux, de mesures et d'événements que vous pouvez consulter pour résoudre rapidement les problèmes et assurer le bon fonctionnement de votre application.
CodeCommit est un service de contrôle de code source qui aide les équipes à collaborer au développement de logiciels, en leur permettant d'importer et d'héberger des référentiels de code Git privés en toute sécurité.
AWS CodePipeline est un service de diffusion continue qui automatise les phases de création, de test et de déploiement de votre processus de publication chaque fois qu'un changement de code est effectué en fonction de la façon dont vous avez défini le flux de travail.
Comme indiqué précédemment, nous avons intégré d'autres services à AWS Lambda pour créer notre backend. Notre application Dwipper consiste en un réseau social de partage d'idées, appelé Dwipps, sur lequel les utilisateurs doivent s'inscrire pour commencer à partager ce qu'ils pensent. Les fonctionnalités créées sont les suivantes :
Nous avons intégré DynamoDB à notre base de données, où nous stockons tous les Dwipps créés par les utilisateurs à partir de notre application, ainsi que nous les modifions et les supprimons.
Pour l'authentification, AWS Cognito était la solution. Il a permis de gérer facilement l'authentification des utilisateurs qui était nécessaire pour que les clients enregistrent leur courrier électronique, en générant facilement des jetons pour chaque utilisateur chaque fois qu'il se connecte pour avoir accès à un contenu spécifique.
Pour créer l'API REST et générer les points de terminaison nécessaires à l'ensemble du flux de notre application, nous avons intégré Amazon API Gateway. Nous avons dû configurer AWS Lambda pour exécuter notre code en réponse à des requêtes HTTP à l'aide d'API Gateway, qui peut valider le jeton généré lors de la connexion et injecter les données utilisateur dans l'exécution d'un environnement Lambda.
En commençant par l'authentification, nous avons utilisé Cognito User Pools dans notre fonction pour créer un nouveau compte utilisateur. En ce qui concerne l'enregistrement, il demande un e-mail et un mot de passe et la fonction obtient ces valeurs, les envoie à Cognito et renvoie la réponse, que l'utilisateur ait été enregistré avec succès ou non. Le point de terminaison est configuré dans un fichier séparé avec les autres points de terminaison, où nous plaçons sa fonction. Pour la fonction de connexion, nous accédons à nouveau à Cognito en envoyant les données de l'utilisateur. Si cet utilisateur existe, Cognito renvoie le jeton nécessaire à l'accès de l'utilisateur au contenu de l'application.
Une fonction cruciale consiste à afficher tous les Dwipps de tous les utilisateurs. Pour celui-ci, nous devons accéder à DynamoDB, pour obtenir la table spécifique et renvoyer tout son contenu. La fonction pour créer un Dwipp est fondamentalement la même, mais au lieu d'obtenir tous les éléments du tableau, nous voulons y insérer un nouvel élément. L'identifiant unique de chaque Dwipp est créé avec uuidv4, un package JavaScript qui permet de créer des identifiants. L'identifiant et le contenu du nouveau Dwipp sont envoyés à cette table avec chaque champ de sa colonne. L'utilisateur doit disposer d'un jeton généré lors de la connexion, l'API Gateway valide ce jeton et injecte les données utilisateur dans l'environnement de l'exécution lambda. De cette façon, nous pouvons identifier l'utilisateur qui essaie de créer un nouveau Dwipp.
Pour voter pour un Dwipp, nous utilisons le même tableau que précédemment. Mais pour les Dwipps préférés, nous avons dû créer une nouvelle table. Pour le premier tableau, nous avons une fonction qui vérifie l'adresse e-mail de l'utilisateur actuel et vérifie si celui-ci a déjà voté pour le Dwipp inscrit dans le tableau. Dans l'affirmative, le nombre de votes positifs diminue d'un point et l'adresse e-mail est supprimée de la liste. Dans le cas contraire, il est augmenté d'un point et l'adresse e-mail est ajoutée.
En ce qui concerne la fonction permettant de marquer un Dwipp comme favori, nous vérifions si ce Dwipp est déjà dans la table des Dwipp favoris. S'il s'y trouve, nous confirmons si cet utilisateur l'a déjà ajouté à ses favoris. Sinon, un nouveau Dwipp favori est ajouté à ce tableau. Les informations des utilisateurs qui ont mis en favori un Dwipp spécifique sont également conservées dans le tableau.
Avec tous ces services disponibles et faciles à intégrer, nous avons créé une application fonctionnelle avec authentification et certaines fonctionnalités en moins d'un mois.
Au départ, notre idée était d'utiliser à la fois AWS Lambda et Google Cloud Functions. Nous avons choisi AWS car il fournit des outils pour la création et l'authentification des utilisateurs, contrairement à Google Cloud Functions. Tout est à la hauteur des attentes, car toutes les fonctionnalités requises n'ont pu être mises en œuvre qu'avec AWS.
Il peut sembler difficile de comprendre tous ces services à première vue, mais AWS fournit une documentation complète en clarifiant chacun d'entre eux et en fournissant des exemples utiles. Si vous prenez le temps de le comprendre, de commencer à l'essayer et de le tester, vous serez rapidement en mesure de créer un backend fonctionnel complet pour votre application : sans gestion des serveurs et des infrastructures, en peu de temps et à moindre coût.
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
J'aspire à devenir développeur d'applications mobiles. L'un de mes centres d'intérêt concerne l'intelligence artificielle, tandis que ma véritable passion est de voyager à travers le monde.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
