Informatique sans serveur

6 minutes

Au début du cloud computing, les fournisseurs de services cloud comme Amazon et Microsoft se sont attachés à offrir un vaste choix de services IaaS à leurs clients. Cela a favorisé le développement des clouds publics en permettant aux clients de déplacer plutôt facilement les charges de travail qui ont été exécutées localement sur des serveurs physiques ou des machines virtuelles vers des machines virtuelles dans le cloud. Mais avec IaaS arrive la responsabilité. Une organisation qui lance une machine virtuelle dans le cloud prend également en charge la gestion des éléments qu’elle contient : le système d’exploitation, tous les runtimes nécessaires, les applications qui utilisent ces runtimes, etc.

PaaS transfère une partie de cette responsabilité au fournisseur de services cloud et bénéficie d’autres investissements soutenus dans le cloud. Avec des services tels qu’AWS Elastic Beanstalk et Azure App Service, les clients peuvent provisionner des serveurs web virtuels disposant de runtimes populaires, comme Java, Node.js et Microsoft .NET, et sur lesquels les logiciels s’exécutent en quelques minutes. Même si les machines virtuelles font une grande partie du travail en arrière-plan, il est largement fait abstraction de la présence de ces machines virtuelles. PaaS permet aux clients de se concentrer sur les applications qu’ils écrivent pour résoudre les problèmes métier, plutôt que de consacrer des phases à gérer les machines virtuelles et à maintenir les plateformes corrigées et à jour.

L’informatique Serverless est une innovation relativement récente du cloud computing qui approfondit de telles abstractions. Supposons que votre organisation écrive et tienne à jour du code qui effectue des sauvegardes nocturnes de données critiques, qui exécute des cycles de facturation hebdomadaires ou qui transmet un paiement électronique chaque fois qu’une facture est chargée dans le stockage cloud. Dans ce cas, l’objectif principal est d’exécuter ce code et de le faire au moment opportun. Tout le reste, notamment l’endroit où le code est stocké, ainsi que son mode et son emplacement d’exécution, est secondaire.

Vous pouvez adopter une approche IaaS en créant une ou plusieurs machines virtuelles pour exécuter votre code et en installant les plateformes et bibliothèques nécessaires. Vous pouvez provisionner une instance Elastic Beanstalk ou App Service et y héberger le code. Vous pouvez également utiliser un runtime de fonction comme AWS Lambda ou Azure Functions pour exécuter votre code chaque fois que vous le souhaitez sans tenir compte de son emplacement ou de son mode d’hébergement. AWS Lambda et Azure Functions sont deux exemples d’informatique Serverless (en particulier, de fonctions serverless), tout comme Google Cloud Functions. Tous les trois représentent l’étape suivante de l’évolution naturelle de cloud computing, depuis IaaS, où vous êtes en charge de toutes les opérations, jusqu’à l’expérience serverless, où vous vous concentrez sur les actions que vous voulez effectuer (le code que vous souhaitez exécuter) dans le cloud et où vous laissez le fournisseur de services cloud gérer tout le reste.

Les fonctions serverless exécutées par les environnements d'exécution de fonctions dans le cloud sont la forme la plus courante de l’informatique serverless, mais elles n’en sont pas la seule. Amazon, Microsoft et Google offrent des versions serverless de certains de leurs autres services PaaS, notamment les bases de données serverless. Certains fournisseurs prennent en charge les flux de travail serverless, ce qui vous permet de définir des flux de travail métier dans le cloud et de les exécuter en réponse à des événements externes, comme des factures en cours de chargement dans le stockage cloud, des minuteurs qui se déclenchent à intervalles spécifiés ou des e-mails atteignant une boîte de réception, souvent sans écrire une seule ligne de code. Enfin, un grand nombre des services de conteneur proposés par les fournisseurs de services cloud, notamment Azure Container Instances et AWS Elastic Container Service, sont considérés comme des exemples d’informatique Serverless, car ils vous permettent d’exécuter des conteneurs dans le cloud tout en faisant abstraction de l’infrastructure sous-jacente.

Avantages de l’informatique sans serveur

L’informatique Serverless offre trois principaux avantages aux organisations qui bénéficient du cloud computing :

Réduction des coûts informatiques : les clients paient généralement des frais mensuels pour les machines virtuelles IaaS et les services PaaS, comme Elastic Beanstalk and Azure App Service. La facturation continue même si les services sont inactifs. Toutefois, la plupart des services informatiques serverless prennent en charge le tarif basé sur la consommation, dans lesquels vous êtes facturé uniquement en fonction du temps d’exécution de votre code. Imaginez que vous dédiez une machine virtuelle vous coûtant 100 dollars par mois à l’exécution de code qui effectue une sauvegarde nocturne de données critiques, et que le code s’exécute pendant 30 minutes chaque nuit. Vous payez 100 dollars par mois pour exécuter du code pendant 1/48ème de mois, soit moins d’une journée. Le déploiement du même code en tant que fonction serverless peut vous coûter seulement quelques dollars par mois. Avec le tarif basé sur la consommation, vous ne payez pas le temps d’inactivité.

Scalabilité automatique : Les fournisseurs de cloud proposent des mécanismes pour les services IaaS de mise à l’échelle dans des produits tels qu’AWS Auto Scaling et les groupes de machines virtuelles identiques dans Azure. Ils fournissent également des options de mise à l’échelle manuelle et automatique pour les services PaaS. Toutefois, même si la mise à l’échelle est effectuée automatiquement, un administrateur de cloud doit activer la mise à l’échelle automatique et la configurer pour que le fournisseur de cloud sache comment et quand elle doit avoir lieu. L’un des aspects sous-jacents que les administrateurs doivent prendre en compte est que, puisque vous payez pour des instances individuelles de services IaaS et PaaS, vous voulez configurer le service pour effectuer une mise à l’échelle suffisante sans qu’elle soit excessive. L’informatique Serverless offre la possibilité d’effectuer un scale-out transparent et automatique pour répondre à une augmentation de la demande et un scale-in en cas de baisse de celle-ci. Un administrateur de cloud n’effectue généralement aucune configuration autre que l’activation de cette option dans le service. Si vous devez faire face à 100 demandes simultanées d’exécution d’une fonction serverless, le fournisseur de services cloud vérifie que les demandes peuvent être exécutées en parallèle (ou principalement en parallèle). Le coût n’est pas impacté car, avec le tarif basé sur la consommation, le coût est le même si vous exécutez une fonction 100 fois, que l’exécution soit en série ou en parallèle.

Réduction des coûts administratifs : L’expérience serverless vous permet de vous concentrer sur l’exécution du code et des flux de travail tout en transférant la responsabilité de tout le reste, notamment la gestion de la plateforme sous-jacente, au fournisseur de services cloud.

L’informatique Serverless présente également des inconvénients. Voici quelques-unes des limitations à prendre en compte :

Certains runtimes de fonction imposent une limite quant à la durée pendant laquelle une fonction est autorisée à s’exécuter.
Certains runtimes de fonction ne garantissent pas qu’une fonction sera exécutée immédiatement, sauf si vous êtes prêt à payer davantage pour que cela se produise. Si, par exemple, Azure Functions est configuré pour utiliser le tarif basé sur la consommation, une fonction peut ne pas s’exécuter pendant 10 minutes après son déclenchement. Cela peut ne pas être un problème pour une sauvegarde nocturne, car cela ne vous importe probablement pas que la sauvegarde s’exécute à 1 h 00 ou à 1 h 10 du matin. Mais ce peut être rédhibitoire pour les fonctions qui sont limitées dans le temps, c’est-à-dire les fonctions qui doivent s’exécuter en temps réel (ou en quasi-temps réel).
Les fonctions serverless sont généralement sans état, c’est-à-dire qu’elles ne peuvent pas stocker des données en interne et supposer qu’elles seront conservées d’un appel de fonction à l’autre. Elles peuvent utiliser des services de stockage cloud externes comme Amazon S3 et le Storage Azure pour conserver les données entre les appels, mais cela rend le code de la fonction plus complexe.

Certains fournisseurs de services cloud offrent une prise en charge des fonctions avec état (qu’Azure appelle « fonctions durables »), mais les fonctions qui conservent l’état sont un ajout relativement récent à l’informatique Serverless et ne sont pas universellement prises en charge.

Fonctions sans serveur

L’exemple le plus courant d’informatique Serverless est l’utilisation de fonctions serverless. Vous chargez du code dans le cloud et vous lui indiquez quand s’exécuter. Le code peut être écrit dans différents langages, notamment Java et C#.

La figure 11 répertorie les langages de programmation pris en charge par les fonctions serverless dans Azure, AWS et GCP au moment de la rédaction de cet article :

Langage	Azure Functions	AWS Lambda	Fonctions Google Cloud
C#	x	x
F#	x
Allez		x	x
Java	x	x
JavaScript (Node.js)	x	x	x
PowerShell	x	x
Python	x	x	x
Ruby		x
TypeScript	x

Figure 11 : Langages de programmation pris en charge par les runtimes de fonction serverless courants.

Quand vous créez une fonction et que vous fournissez le code qu’elle exécutera, vous identifiez également l’événement externe qui provoque l’exécution de la fonction. Les plateformes cloud courantes prennent en charge des déclencheurs de différents types, notamment des minuteries, des événements se produisant dans d’autres services cloud (par exemple le chargement d’un document dans le stockage cloud) et des appels HTTP. Il est très simple de charger un code de facturation dans un runtime de fonction et de le configurer pour qu’il s’exécute une fois par jour, une fois par semaine ou une fois par mois. Il est tout aussi simple d’activer une fonction chaque fois qu’une facture est chargée dans le stockage cloud (par exemple Amazon S3 ou Stockage Azure) ou chaque fois qu’un appel est effectué à un point de terminaison REST associé à la fonction.

Les fonctions serverless sont fréquemment utilisées pour effectuer des tâches autonomes, comme des sauvegardes nocturnes et la facturation. Elles sont également utilisées pour connecter d’autres services cloud et pour composer des solutions complexes en utilisant des services cloud en tant que composants. La figure 12 présente une solution de ce type qui est utilisée pour combiner plusieurs services Azure de façon à surveiller l’activité des ours polaires dans l’Arctique. Une fonction Azure joue un rôle clé dans l’architecture en prenant la sortie d’Azure Stream Analytics (déclenchée par un appel HTTP), en récupérant une photo auprès de Stockage Blob Azure et en envoyant la photo à un modèle entraîné avec le service Vision personnalisée Azure, qui utilise l’intelligence artificielle pour déterminer si la photo contient un ours polaire. La fonction est la « colle » qui lie ensemble Stream Analytics, Stockage Blob et le Service Vision personnalisée.

Figure 12 : Utilisation d’une fonction Azure pour connecter d’autres services Azure.

Figure 12 : Utilisation d’une fonction Azure pour connecter d’autres services Azure.

Flux de travail sans serveur

Certains services de calcul serverless permettent aux clients d’automatiser des workflows métier sans écrire du code. Azure Logic Apps, par exemple, fournit plus de 100 connecteurs intégrés pour interagir avec des sources de données allant des bases de données Oracle aux services de réseaux sociaux tels que X. Ils fournissent des déclencheurs pour définir quand les workflows doivent s’exécuter, par exemple lorsqu’un fichier est chargé sur Box.com ou qu’un message est tweeté avec un hashtag spécifique. Ils fournissent également des centaines d’actions prédéfinies, qui définissent ce qui se produit quand un déclencheur est activé et qui peuvent être chaînées pour former des workflows complexes, et des conditions qui autorisent l’exécution conditionnelle des actions. Elles sont extensibles à l’infini, car une des actions prises en charge par Azure Logic Apps est l’appel d’une fonction Azure. Si un workflow implique une logique personnalisée qui n’est pas encapsulée dans une action, vous pouvez fournir le code qui implémente cette logique et l’inclure dans le workflow comme s’il s’agissait d’une action prédéfinie.

La figure 13 illustre un flux de travail de ce type dans le concepteur Azure Logic Apps¹. Quand un e-mail arrive, l’application logique entre en action et recherche une expression clé dans la ligne d’objet de l’e-mail et la présence d’une pièce jointe. Si les deux conditions sont satisfaites, l’application logique appelle une fonction Azure pour enlever le code HTML du corps de l’e-mail. Elle dépose ensuite l’e-mail nettoyé et les pièces jointes qui l’accompagnent dans Stockage Blob Azure, et envoie un e-mail avec des liens vers les documents concernés dans Stockage Blob pour avertir les parties prenantes que les informations sont disponibles et sont en attente de révision. Cet exemple combine deux paradigmes serverless : une application logique qui exécute des actions sans code (du moins pas du code que vous-même ou une personne de votre organisation avez écrit) et une fonction Azure contenant du code que vous avez fourni pour personnaliser le workflow. Il est représentatif du mouvement qui se produit dans le cloud computing : passer de machines virtuelles que vous créez vous-même à des abstractions de haut niveau qui permettent aux organisations de concentrer leur énergie sur la résolution des problèmes métier, plutôt que sur la gestion des machines virtuelles, et sur l’installation et la gestion des runtimes.

Figure 13 : Définition d’un workflow dans Azure Logic Apps.

Figure 13 : Définition d’un workflow dans Azure Logic Apps.

Amazon offre un service similaire sous la forme d’AWS Step Functions. Avec Step Functions, vous pouvez composer des workflows visuels qui combinent d’autres services, comme AWS Lambda et AWS ECS. Les workflows comprennent une série d’étapes, la sortie d’une étape servant d’entrée à la suivante. Comme Azure Logic Apps, AWS Step Functions fournit des primitives pour les branchements et l’exécution en parallèle, ce qui vous évite d’écrire du code pour obtenir le même résultat. En effet, un workflow métier devient un diagramme de machine à états facile à comprendre, facile à expliquer à d’autres et facile à modifier.

Base de données sans serveur

Au début du cloud computing, l’hébergement d’une base de données dans le cloud signifiait le provisionnement d’une machine virtuelle et l’installation d’un produit de base de données comme MySQL, PostgreSQL ou SQL Server. Le PaaS a changé cela en offrant des bases de données en tant que service. Par exemple, avec Azure SQL Database ou Amazon RDS (Relational Database Service), vous provisionnez simplement une instance et, en quelques minutes, vous disposez d’une base de données hébergée dans le cloud prête à être utilisée par des clients. En outre, le fournisseur de services cloud maintient à jour la plateforme de base de données en appliquant les mises à jour logicielles et des correctifs.

Les bases de données serverless sont une innovation plus récente dans le cloud computing, qui offrent un modèle prix/performances optimisé qui est idéal pour les bases de données uniques avec des modèles d’utilisation irréguliers. Par exemple, Azure offre une version serverless d’Azure SQL Database. Avec la version standard d’Azure SQL Database, vous choisissez un niveau de prix/performances en fonction de la charge maximale que vous prévoyez pour la base de données. Si les charges sont très variables ou intermittentes, vous payez au final souvent comme si la base de données était soumise en permanence à des charges élevées.

La version serverless d’Azure SQL Database atténue ce problème en mettant à l’échelle la base de données en fonction des besoins pour gérer les charges qu’elle rencontre, avec des coûts basés sur la somme des coûts de calcul et des coûts de stockage. Comme avec les fonctions serverless utilisant un modèle de consommation, vous payez seulement pour ce que vous utilisez. Amazon offre un service similaire sous la forme d’AWS Aurora Serverless, qui est une version serverless du service de base de données Aurora d’Amazon, tandis que Google offre à ses clients un service de base de données NoSQL serverless, connu sous le nom de Google Cloud Firestore.

Références

Microsoft (2019). Automatiser les tâches de traitement des e-mails et des pièces jointes avec Azure Logic Apps. https://learn.microsoft.com/azure/logic-apps/tutorial-process-email-attachments-workflow.

Commentaires

Cette page a-t-elle été utile ?

Informatique sans serveur

Vérifiez vos connaissances

Commentaires