AWS Lambda Azure GCP sans serveur

Le sans serveur est devenu un modèle de cloud computing répandu, mais de quoi s'agit-il exactement ?

Le développement d'applications sans serveur est devenu populaire ces dernières années. Dans ce blog, nous verrons ce qu'est le sans serveur et quelles sont ses propriétés essentielles, tout en fournissant des références supplémentaires en cours de route.

Le sans serveur est une nouvelle forme d'informatique avec deux caractéristiques principales :

• Les fournisseurs de cloud prennent en charge le l'infrastructure et certaines des opérations de gestion qui incombent traditionnellement aux développeurs et aux ingénieurs devops. Cela permet à l'équipe de développement de se concentrer davantage sur l'écriture de code et moins sur les opérations de type informatique. Par exemple, les fournisseurs de cloud :
• Mettre à l'échelle dynamiquement les instances ou d'autres ressources selon les besoins pour exécuter l'application en fonction de la charge qu'elle reçoit.
• Maintenir ces instances (à partir du matériel pour mettre à niveau le système d'exploitation et les bibliothèques dépendantes) .
• Vous ne payez que ce que vous utilisez. De cette façon, vous pouvez commencer petit et payer uniquement lorsqu'un projet est réussi.

Le sans serveur a été popularisé par Amazon lorsqu'AWS a introduit les fonctions Lambda en 2014. Finalement, Microsoft et Google ont emboîté le pas avec les fonctions Azure et les fonctions Google Cloud. Il est maintenant assez facile de démarrer avec les fonctions sans serveur. Consultez ces blogs pour obtenir des exemples sur la façon de créer vos premières fonctions dans GCP, Azure et AWS :

L'objectif initial des fournisseurs de cloud était les fonctions sans serveur. Avec ces fonctions, le développeur est responsable de l'écriture du code de la fonction tandis que le fournisseur de cloud prend la responsabilité d'exécuter les fonctions à la demande, ainsi que d'augmenter et de réduire le nombre d'instances où ces fonctions s'exécutent (l'infrastructure est élastique).[19659003] En termes de coût, vous ne payez que lorsque la fonction est en cours d'exécution et proportionnellement à la durée d'exécution (et à la quantité de mémoire/à la vitesse du processeur). Lorsqu'aucune fonction n'est en cours d'exécution, votre coût est nul. C'est le concept de payer au fur et à mesure que vous utilisez.

Pour avoir une meilleure idée de son fonctionnement, voici un exemple d'exécution des fonctions AWS Lambda : à 1 Go de mémoire, cela coûte 0,00000000167 $ par ms d'exécution. En d'autres termes : avec 1 million de requêtes par jour chacune à 20 ms pendant 30 jours non-stop, cela vous coûterait 10 $ par mois.

Remarque : ce prix est en vigueur en juillet 2021. Pour connaître les derniers prix, consultez ici.

Cependant, Serverless ne se limite pas aux fonctions. Les améliorations récentes apportées par divers fournisseurs de cloud ont étendu le concept sans serveur à de nombreux autres services, y compris le stockage de données et le flux de travail.

Les principales caractéristiques de tous ces services sans serveur sont : ne pas perdre de temps à créer du code d'infrastructure, à maintenir la disponibilité du serveur et à gérer les infrastructures matérielles et logicielles du serveur (résilience, évolutivité, élasticité, sécurité…).

Avec autant de sans serveur services, il est désormais possible d'envisager l'écriture d'applications uniquement Serverless (Serverless First). Dans un futur blog, nous développerons ce concept.

Bien sûr, sans serveur ne signifie pas qu'il n'y a pas de serveurs, il existe en effet des instances de serveur exécutant votre code et prêtes à répondre aux demandes entrantes. Au lieu de cela, Serverless signifie que l'équipe de développement n'a pas à traiter avec les serveurs.

Bien que les applications doivent toujours être surveillées pour les erreurs et les performances (en effet, les erreurs d'application n'ont pas disparu comme par magie), vous n'avez plus à déterminer si les instances sont en hausse ou en baisse ou si une instance spécifique atteint son maximum.

L'époque de la gestion complexe des ressources et de la planification des capacités est révolue. Par exemple, en un clic, vous pouvez exécuter votre fonction avec 1 Go de mémoire au lieu de seulement 256 Mo et avec un processeur quatre fois plus rapide. Pas besoin de configurer une nouvelle instance et de réinstaller. Mieux encore, vous pouvez régler des fonctions individuelles en fonction de leurs propres besoins : vous pouvez avoir une fonction implémentant un service de décision s'exécutant avec une configuration 10 fois plus rapide qu'une seconde fonction. Vous n'avez pas besoin de faire tourner des instances distinctes.

Alors, pourquoi ne pas passer au sans serveur ?

Toutes ces propriétés sans serveur ont permis à de très petites équipes de rivaliser avec de plus grandes organisations, leur permettant de créer rapidement des applications qui peuvent gérer de grandes quantités de trafic et d'énormes variations de trafic à un coût très faible.

Le sans serveur est un paradigme informatique transformateur qui devient très populaire, et vous devriez certainement en tenir compte lors de la mise en œuvre d'applications basées sur le cloud.

Dans les futurs blogs, nous examinerons divers sujets sans serveur comme les modèles de programmation sans serveur, les tendances, les applications composites et traitement de flux, alors restez à l'écoute. Mais en attendant, je vous invite à consulter ce blog sur l'écriture de logique métier sans serveur de manière extrêmement efficace. De plus, lisez ce blog pour en savoir plus sur la façon d'obtenir votre logique métier à moindre coût.

Si vous souhaitez plus d'informations sur la façon dont une solution low-code/no-code peut vous aider dans votre Parcours sans serveur, vous pouvez visionner cette vidéo (40mn) qui va plus en détail.

Et si vous cherchez à créer, tester et déployer facilement des règles métier, Corticon.js est un excellent outil pour écrire logique métier pour un environnement sans serveur.

En savoir plus sur Corticon.js