Le sujet du jour est un sujet dont presque tout le monde a entendu parler, mais que presque personne ne peut expliquer. Serverless ? Qu'est-ce que c'est exactement ? Est-ce vraiment juste du code qui s'exécute sur rien, ou est-ce quelque chose de bien plus vaste ? Mettons les choses au clair. Serverless ne signifie pas pas de serveur. Cela signifie que vous n'y pensez pas, et cette distinction change tout dans la manière dont vous créez des logiciels. A la fin de cet épisode, vous comprendrez ce que sont réellement Azure Functions, comment fonctionnent réellement les prix et quand vous devriez les utiliser. Nous allons décomposer cela en blocs de construction, en commençant par le plus grand mythe. Ce que signifie réellement serverless ? Démystifions tout de suite quelques mythes. Le terme serverless est le pire terme marketing jamais inventé par Microsoft. Il fait croire aux gens qu'il n'y a littéralement aucun serveur impliqué.

Ce n'est pas vrai. Il y a des serveurs, beaucoup. Vous n'avez tout simplement jamais besoin d'y toucher. Il y a 20 ans, si vous vouliez exécuter un morceau de code sur Internet, vous deviez faire beaucoup de travail. Vous louiez une machine virtuelle, installiez un système d'exploitation, configuriez un serveur web et déployez votre application. Ensuite, vous passiez tous les week-ends à corriger les mises à jour de sécurité et à vous assurer que tout ne plantait pas à 3h du matin. Et voilà le truc. Payez pour ce serveur que votre code soit en cours d'exécution ou non. Il restait là à ronronner et brûlant de l'argent pendant que vous dormiez. Le serverless bouleverse tout ce modèle. Vous écrivez votre code, vous y téléchargez et la plateforme gère tout le reste. Le système d'exploitation, les correctifs de sécurité, la mise à l'échelle et la disponibilité. Votre travail consiste simplement à écrire la logique qui compte.

Voyez cela comme la différence entre gérer une cuisine de restaurant et utiliser un distributeur automatique. Une cuisine de restaurant nécessite un personnel complet, des fournitures constantes et de maintenance. Cela coûte de l'argent tous les jours, même si personne ne passe la porte. Un distributeur automatique reste là dans un coin, sans rien faire jusqu'à ce que quelqu'un appuie sur un bouton. Puis il s'allume, fait son travail et se rendort. Vous ne payez l'électricité que lorsqu'il fonctionne réellement. Voilà en quelques mots ce qu'est le serverless. Azure Functions est la version de Microsoft. Il exécute de petits morceaux de code en réponse à des événements. Votre code est en veille jusqu'à ce que quelque chose le réveille, puis il s'exécute, se termine et se rendort. Alors à quoi ressemble réellement ce code ? Ce que sont Azure Functions ? Une fonction est un morceau de code unique qui effectue une tâche spécifique.

Ce n'est pas une application complète avec une page de connexion, une base de données et 20 écrans. C'est une tâche ciblée. Imaginez-la comme un interrupteur dans votre maison, allumé ou éteint, qui fonctionne, puis s'éteint. Un serveur web traditionnel est l'inverse, comme si vous laissiez toute la lumière de votre maison allumée 24h sur 24, 7 jours sur 7, même lorsque personne n'est à la maison. Azure Functions prend en charge de nombreux langages de programmation différents. Vous pouvez utiliser celui avec lequel vous êtes à l'aise, Javascript, Tython, C, Java, PowerShell. Il n'y a pas de bonne réponse ici. Choisissez langage que vous connaissez déjà. Maintenant, d'ici pour une confusion courante, une application de fonction n'est pas la même chose qu'une fonction. L'application de fonction est le conteneur. Considérez-la comme une boîte à outils. Vous créez une application de fonction, et à l'intérieur de cette boîte à outils, vous ajoutez plusieurs fonctions.

Chaque fonction est un outil distinct qui effectue sa propre tâche. Vous pouvez avoir une fonction qui gère les inscriptions des utilisateurs, une autre qui traite les images téléchargées, et une troisième qui envoie des rapports nocturnes. Elles résident toutes dans la même boîte à outils, mais fonctionnent indépendant. Autre chose à propos des fonctions, elles sont sans état par conception. Cela signifie qu'elles ne se souviennent de rien entre les exécutions. Si votre fonction traite un fichier et se termine, c'est terminé. La prochaine fois qu'elle s'exécute, elle recommence à zéro sans aucun souvenir d'air frais. Cela peut sembler être une limitation, mais c'est en fait la fonctionnalité qui les rend si puissante. Étant donné que les fonctions ne conservent pas la mémoire ou l'état, Azure peut lancer 100 copies de votre fonction instantanément lorsque le trafic augmente, et les arrêter tout aussi rapidement lorsque le trafic diminue.

C'est ainsi que vous obtenez une évolutivité sans payer pour des serveurs inactifs. Voici la question. Si une fonction reste là sans rien faire jusqu'à ce que quelque chose la réveille, qu'est-ce qui la réveille réellement ? C'est là qu'interviennent les déclencheurs. Les déclencheurs, le camp. Chaque fonction doit avoir exactement un déclencheur, et ce n'est pas facultatif. Le déclencheur est l'événement qui réveille votre fonction. Sans lui, votre code reste là sans rien faire. Pensez au déclencheur comme à une sonnette. Votre fonction est à l'intérieur de la maison en train d'attendre. Elle pourrait t'attendre infiniment. Rien ne se passe tant que quelqu'un ne sonne pas à la porte. Ensuite, la fonction entre en action, répond à la porte, fait son travail et se remet en attente. Il existe 4 déclencheurs que les débutants rencontrent le plus souvent. Le déclencheur HTTP est le point de départ, le plus courant.

Quelqu'un visite une URL ou effectue un appel d'API, et votre fonction se déclenche. C'est ainsi que vous créez des API légères, sans configurer un serveur web complet. Ensuite, il y a le déclencheur de minuterie, qui s'exécute selon un calendrier. Vous définissez une expression CRON, quelque chose comme exécuter toutes les heures ou exécuter à minuit tous les soirs, et votre fonction se déclenche à 16 heures précises. Idéal pour les tâches de maintenance, les tâches de nettoyage ou la génération de rapports nocturnes, le déclencheur blob se déclenche lorsqu'un fichier est chargé dans le stockage Azure. Imaginons que quelqu'un charge un PDF dans un dossier spécifique. Le déclencheur blob détecte ce chargement et exécute automatiquement votre fonction. Cela est essentiel pour le traitement d'images, la conversion de documents et la validation de fichiers. Le déclencheur de fil d'attente se déclenche quant à lui lorsqu'un message apparaît dans une file.

Les files d'attente sont un moyen de découpler différentes parties de votre système. Un service dépose un message dans une file d'attente et votre fonction le récupère et le traite dès qu'il est prêt. Cela empêche un service lent de bloquer tout le reste. Voici le point essentiel. Lorsqu'un déclencheur se déclenche, il transmet automatiquement des données à votre fonction. Vous n'avez pas besoin de les interroger ou de vérifier si quelque chose s'est produit. Le déclencheur vous transmet tout ce dont vous avez besoin et votre fonction les traite. Une fonction sans déclencheur n'est que du code qui ne fait rien. Le déclencheur est ce qui lui donne un but. Ainsi, le déclencheur indique à votre fonction quand s'exécute. Mais d'où viennent les données et où vont-elles ? C'est là qu'interviennent les liaisons. Liaisons données entrantes, données sortantes. Les liaisons sont un moyen d'indiquer à votre fonction quelles données lire et où envoyer les résultats sans écrire tout le code supplémentaire.

C'est un peu long, alors laissez-moi simplifier. Il n'en existe plus. Les liaisons d'entrée apportent des données à votre fonction. Les liaisons de sortie envoient des données. Sans liaison, vous devriez écrire du code SDK chaque fois que vous voudriez communiquer avec un compte de stockage, une base de données ou une file d'attente. Vous géreriez les chaînes de connexion, géreriez les nouvelles tentatives, sérialiseriez les données, désérialiseriez les réponses. Cela représente beaucoup de codes passe-partout juste pour lire un fichier. Avec les liaisons, vous déclarez simplement ce dont vous avez besoin. Je vais lire à partir de ce conteneur d'objets bleu. Ok, je vais écrire dans cette file d'attente. Le runtime s'occupe du reste. Il ouvre la connexion, lit les données et les transmet à votre fonction en tant que paramètre. Lorsque votre fonction se termine, elle prend la valeur de retour et l'écrit à l'endroit que vous avez spécifié.

Considérez les liaisons comme des tuyaux. Vous connectez votre fonction à un compte de stockage, une base de données ou une file d'attente. Les données circulent automatiquement dans ces canaux. Votre fonction n'a pas besoin de savoir comment fonctionnent les canaux. Elle reçoit simplement ce qui arrive et envoie ce qui doit sortir. Voici un exemple concret. Imaginons que vous ayez une liaison d'entrée blob. Lorsque votre fonction démarre, elle lit automatiquement un fichier à partir du stockage blob et vous le transmet en tant que paramètre. Vous n'écrivez aucun code SDK de stockage. Vous récupérez simplement les données et les traite. Autre exemple, une liaison de sortie de file d'attente. Votre fonction traite quelque chose et à la fin, vous renvoyez une valeur. Runtime prend cette valeur, la sérialise et la dépose dans la file d'attente. Vous n'écrivez aucun code de file d'attente. Vous renvoyez simplement une valeur.

Les liaisons sont facultatives. Vous pouvez en avoir zéro, une ou plusieurs. Certaines fonctions n'ont besoin que d'un déclencheur sans aucune liaison. D'autres peuvent avoir 3 ou 4 liaisons se connectant à différents services. La combinaison de déclencheurs et de liaisons est ce qui rend Azure Functions si puissant. Vous écrivez la logique métier, le code de prise de décision réelle. La plateforme gère toute l'intégration. Votre fonction reste petite, ciblée et facile à comprendre. La tarification. La tarification est ce qui surprend le plus les débutants. Pour la plupart des gens, le plan de consommation est le choix par défaut et vous devriez commencer avec 90% du temps. Voici comment cela fonctionne. Vous ne payez que lorsque votre fonction s'exécute réellement. Lorsqu'elle est inactive, vous ne payez rien. Zéro, pas un centime. Deux éléments composent la facture. Premièrement, le nombre d'exécutions, le nombre de fois que votre fonction se déclenche.

Deuxièmement, le temps d'exécution mesuré en go secondes. Il s'agit en gros de la durée d'exécution de votre fonction multipliée par la quantité de mémoire utilisée. La subvention gratuite est généreuse. Vous obtenez 1 million d'exécutions par mois et 410 000 gigas secondes entièrement gratuites. Pour la plupart des petits projets, les applications de loisirs et des prototypes, vous ne paierez jamais un centime. Jamais. Si vous dépassez la subvention gratuite, les tarifs restent incroyablement. 200 par million d'exécutions. Mais pas une faute de frappe. 200 pour 1 million d'exécutions. Imaginez que vous ne payez l'électricité que lorsque vous allumez l'interrupteur. Il n'y a pas de frais de base mensuel pour le câblage de vos murs. Vous ne payez que l'électricité que vous utilisez. Il existe d'autres formules. Flex Consumption est plus récente et vous offre une prise en charge du réseau Virtue.

Premium maintient vos fonctions toujours prêtes. Il n'y a donc pas des démarrages à froid. Dedicated vous offre une capacité fixe sur un plan App Service traditionnel. Mais pour commencer, Consumption est le bon choix presque à chaque fois. Un avertissement. La subvention gratuite est partagée entre toutes vos applications de fonctions dans le même abonnement. Si vous avez 10 applications de fonctions, elles utilisent toutes le même million d'exécutions gratuites. Gardez donc cela à l'esprit si vous commencez à en créer plus d'une. Les prix sont excellents. Mais rendons cela réel avec un exemple concret. Un scénario réel. Imaginez que vous gérez un site web sur lequel les utilisateurs téléchargent des photos de profil. Les images sont énormes, environ 10 MHz chacune. Et cela pose quelques problèmes réels. Les fichiers volumineux coûtent plus cher à stocker et ralentissent votre site web à chaque fois qu'un utilisateur charge une page et frustre vos utilisateurs qui doivent attendre des photos.

Vous avez donc besoin d'un moyen de réduire automatiquement ces images. Sans Azure Functions, vous devriez créer un travailleur en arrière-plan à partir de zéro. Cela signifie obtenir un serveur distinct, configurer une file d'attente pour gérer la charge de travail et écrire du code pour gérer tous les éléments mobiles. C'est une tonne de complexité inutile pour quelque chose d'aussi simple que la réduction d'une image. Avec Azure Functions, tout ce dont vous avez besoin est un déclencheur blob et une fonction. Aucun serveur à gérer. Laissez-moi vous expliquer comment cela fonctionne. Un utilisateur télécharge une photo via votre site web et ce fichier atterrit dans le stockage blob Azure. Dès son arrivée, un déclencheur blob se déclenche automatiquement. Votre fonction se réveille, exécute le code de compression et enregistre la version plus petite dans le stockage. Tout cela se produit en quelques secondes.

L'utilisateur n'attend jamais car l'ensemble du processus s'exécute en arrière-plan de manière totalement invisible. Voici un autre exemple courant, l'envoi d'un email de bienvenue lorsqu'une personne s'inscrit à votre service. Un déclencheur HTTP intercepte la demande d'inscription de votre site web. Votre fonction se déclenche, récupère l'adresse email de l'utilisateur, envoie un message de bienvenue via SendGrid et c'est terminé. L'utilisateur reçoit son email presque instantané. Pas de salaire de messagerie à configurer, pas de fil d'attente d'envoi à gérer, juste une fonction, une tâche et c'est terminé. D. Ce sont exactement les tâches pour lesquelles Azure Functions a été conçue, de petites tâches ciblées et pilotées par des événements. Pas d'application volumineuse, pas de workflow complexe, juste une chose bien faite, déclenchée par quelque chose qui se passe ailleurs, à... Quand utiliser Azure Functions ?

Alors, quand faut-il utiliser une fonction et quand faut-il utiliser autre chose ? Voici un moyen rapide de décider. Demandez-vous si la tâche est courte, si elle est pilotée par des événements et si elle est sans état. Si vous avez répondu oui à ces trois questions, Azure Functions est probablement l'outil qu'il vous faut. Commençons par les bons cas d'utilisation. Les API et les Webhook sont parfaitement adaptés. Vous avez besoin d'un point de terminaison léger HTTP, effectue une action et renvoie un résultat. C'est exactement pour cela que les déclencheurs HTTP sont conçus. Le traitement des fichiers et des images est un autre aimant. Un fichier arrive dans le stockage, votre fonction se déclenche, le transforme et enregistre le résultat, le tout sans serveur. Les tâches planifiées telles que le nettoyage nocturne ou la génération de rapports fonctionnent parfaitement avec les déclencheurs de minuteurs.

La transformation des données pour les pipelines OTL est également courante. Et les fonctions constituent un lien d'intégration parfait, reliant deux services qui ne communiquent pas naturellement entre eux. Voyons maintenant dans quel cas les fonctions ne sont pas adaptées. Les processus de longue durée posent problème car dans le plan de consommation, les fonctions ont un délai d'expiration de 5 minutes par défaut jusqu'à 10 si vous le configurez, jusqu'à 10 si vous le configurez. Si votre tâche prend plus de temps, vous avez besoin d'autre chose. Les applications avec ETA constituent une autre incompatibilité. Les fonctions ne se souviennent de rien entre les exécutions. Si vous devez maintenir l'état de la session ou suivre la progression entre les étapes, vous allez à l'encontre de la conception. Les charges de travail de calcul lourdes sont erronées. Si vous avez besoin d'une utilisation soutenue du processeur pendant des minutes ou des heures, une machine virtuelle ou un conteneur est un meilleur choix.

Et les workflows complexes où une tâche dépend d'une autre sont mieux gérées par des fonctions durables ou des applications logiques. Voici un bref aperçu des alternatives. Azure Logic Apps est l'option sans code pour connecter des services. Si vous n'avez pas besoin d'écrire de code personnalisé, Logic Apps peut faire le travail qu'un concepteur visuel. Azure App Service est destiné aux applications web complètes qui s'exécutent 24h24 et 7j7. Si vous avez besoin d'un site web complet ou d'une API toujours active, c'est l'outil qu'il vous faut. Azure Container Apps vous offre des microservices conteneurisés avec plus de contrôle sur l'exécution. Et Azure Virtual Machines vous donne un contrôle total sur le système d'exploitation si vous en avez besoin. Voici une règle empirique. Si vous pouvez décrire la tâche en une phrase, c'est probablement un bon candidat pour une fonction. Compressez les images lorsqu'elles sont téléchargées.

Envoyez un email de bienvenue lorsqu'une personne s'inscrit. Exécutez une tâche de nettoyage tous les soirs à minuit. Une phrase, une tâche, une fonction. Erreur courante à éviter pour les débutants. Parlons maintenant de quelques points à surveiller. Voici des erreurs qui font trébucher presque tout le monde lorsqu'ils débutent. Une erreur courante des débutants est de penser que les fonctions sont toujours gratuites. La gratuité est généreuse. Je sais qu'un million d'exécutions peut sembler beaucoup, mais si votre fonction devient virale ou se fait écraser par un bot, ces exécutions s'additionnent rapidement. Surveillez donc votre utilisation, configurez une alerte budgétaire dans Azure et ne recevez pas de factures surprises à la fin du mois. Une autre erreur consiste à ignorer les démarrages à froid. La première fois que votre fonction s'exécute après avoir été inactive, cela prend plus de temps.

Avec le plan de consommation, cela peut prendre quelques secondes. Pour la plupart des cas d'utilisation, cela ne pose aucun problème. Mais si vous créez une API sensible à la latence où chaque milliseconde compte, envisagez le plan premium ou activez les instances toujours prêtes. Ensuite, il y a l'écriture de fonction qui s'exécute trop longtemps. Le plan de consommation a un délai d'expiration, 5 minutes par défaut, 10 minutes maximum. Si votre fonction prend 15 minutes pour traiter un fichier, elle sera arrêtée à mi-chemin. Divisez cette tâche en plusieurs parties plus petites ou utilisez un autre plan d'hébergement. Une autre erreur facile à éviter est de ne pas utiliser l'exécution à partir du déploiement de paquets. Il s'agit d'une simple modification de configuration qui améliore les déploiements plus fiables et rend les déploiements plus fiables. Au lieu de copier des fichiers individuels, vous déployez un package zip.

Il s'agit d'une case à cocher dans le portail, faites-le. Exposer des points de terminaison HTTP sans authentification est un autre piège. Il est facile de laisser une fonction anonyme pendant que vous testez, puis d'oublier de la verrouiller. Définissez correctement votre niveau d'autorisation dès le début. Utilisez des clés de fonction ou d'administration. Ne laissez pas la porte ouverte. La réutilisation de comptes de stockage sur plusieurs applications de fonction pose également problème. En développement, il est acceptable de partager. En production, chaque application de fonction doit avoir son propre compte de stockage. Sinon, vous rencontrez des problèmes de voisinage bruyant lorsque le trafic d'une fonction ralentit une autre. Et enfin, ne pas activer Application Insights. Sans cela, vous avancez à l'aveuglette. Vous ne verrez pas les échecs, les erreurs ou les problèmes de performance.

Vous ne saurez pas si votre fonction s'exécute trop longtemps ou échoue silencieusement. Activez-le dès le premier jour. Cela prend 30 secondes et vous fait gagner des heures de débogage. La règle d'or pour tout cela est de garder vos fonctions petites, ciblées et sans état. Une tâche par fonction, rien de plus. Voilà donc le système. Azure Functions est un calcul sans serveur qui exécute de petits morceaux de code en réponse à des événements. Vous ne payez que lorsque votre code s'exécute. Les déclencheurs indiquent à votre fonction quand se réveiller. Les liaisons la connectent aux données dont elle a besoin et le plan de consommation le rend presque gratuit pour les petits projets, pour les petits projets. La meilleure chose à faire pour l'instant est de créer une fonction HTTP simple déclenchée dans le portail Azure. Cela prend 5 minutes et ne coûte rien. Abonnez-vous à Microsoft Knowledge Nuggets pour obtenir des explications plus simples et partager cet article avec quelqu'un qui ne cesse de demander ce que signifie qu'il y a sans serveur capable.

Frant.