Azure – Introduction au Serverless
Au sein d’une architecture classique d’entreprise, les systèmes d’informations sont généralement hébergés sur des serveurs, connectés entre eux via des réseaux puis exposés au grand public via Internet. Ce modèle de conception a perduré pendant des décennies, et a permis aux hommes de développer des systèmes de plus en plus complexes afin de satisfaire aux besoins métiers divers et variés.
Les équipes de développement font ainsi faces à plusieurs problématiques d’ordres classiques tels que les bugs et la qualité, mais malheureusement aussi ils doivent côtoyer les problèmes d’infrastructures, de serveurs, de machines virtuelles ou encore de réseau qui peuvent très rapidement devenir une vraie plaie pour l’équipe.
Le concept de Serverless peut paraître bien flou aux premiers abords. Que veut dire Serverless ? Quel est la place des machines dans tout cela ? A qui est délégué la gestion des serveurs ? Quel est le rôle du développeur dans tout cela ?
La notion de Serverless
La première notion importante du Serverless est que la gestion des serveurs et des machines est complètement déléguée au fournisseur Cloud. Le développeur ne se préoccupe que de son code et de son workflow d’exécution, et le fournisseur s’occupe d’héberger cela sur des machines appropriées et au bon endroit tout en garantissant une haute disponibilité du code qui est hébergé. Ainsi, la gestion de la scalabilité de l’application est également automatiquement gérer par le fournisseur Cloud : plus il y a de code a exécuté, plus le fournisseur va s’occuper de « scaler » la logique métier pour suivre la cadence.
Ensuite, la deuxième notion importante est le coût d’exécution du code : si aucune demande n’est effectuée sur l’application Serverless, aucune facturation n’est opérée sur le client. Cela permet assez facilement de réduire de 50% (selon les cas) les coûts d’infrastructure, ce qui n’est pas négligeable. Finalement, le client ne paie que lorsque l’application est en activité.
Enfin, la troisième notion est le mode d’exécution du Serverless : par événement. Vu que l’application ne fonctionne pas tout le temps, il faut bien des déclencheurs pour « réveiller » le code hébergé. C’est là que les événements rentrent en jeu, et il en existe approximativement 200 dans Azure : ajout d’un fichier, appel à une API, envoi d’un Tweet, réception d’un e-mail, déclenchement d’une CI/CD et bien plus encore. Ces déclencheurs sont vraiment le liant fort d’une application Serverless, et continuellement de nouveaux sont ajoutés à la plateforme pour enrichir l’offre.
Les offres Serverless chez Azure
La plateforme Cloud de Microsoft est particulièrement bien fournie en termes de technologie Serverless. Dans cette section nous allons faire un tour d’horizon des offres Azure qui sont Azure Functions, Logic App et Event Grid avec un exemple pour illustrer.
Azure Functions
Les Azure Functions représentent un concept dans Azure permettant de lancer du code C#, F#, JavaScript ou TypeScript au déclenchement d’une action. Le développeur n’a pas à se soucier d’où et comment sont code est hébergé : il est déclenché selon un événement particulier, puis effectue une action afin d’interagir avec la plateforme Cloud : écriture dans une base de données, retour d’une valeur au format JSON … La documentation fournie tous les déclencheurs possibles selon la version d’Azure Functions : https://docs.microsoft.com/fr-fr/azure/azure-functions/functions-triggers-bindings.
Le gros avantage des Azure Functions est la scalabilité et la souplesse que peut apporter ce genre de solution car il est bien plus facile de mettre à l’échelle une fonction d’une application toute entière. Une Azure Functions doit rester courte et concise et ne représente qu’un seul traitement. S’il le faut, la plateforme peut comporter plusieurs Azure Functions qui s’enchaînent pour former un workflow (si le workflow est conséquent, il vaut mieux coupler cela avec Azure Logic App).
Sur le portal Azure, lorsqu’on souhaite créer une Azure Functions, ce dernier nous propose plusieurs scénarios prédéfinis. Le premier (Webhooks + API) nous donne la fonction suivante :
using System.Net;
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
// parse query parameter
string name = req.GetQueryNameValuePairs()
.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
.Value;
if (name == null)
{
// Get request body
dynamic data = await req.Content.ReadAsAsync<object>();
name = data?.name;
}
return name == null
? req.CreateResponse(HttpStatusCode.BadRequest, "Please pass a name on the query string or in the request body")
: req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
}
Cette fonction récupère simplement un paramètre dans l’URL intitulé name et le renvoi dans la réponse avec un code HTTP 200. S’il n’existe pas dans l’URL, la fonction va chercher dans le corps de la requête. Sinon, la fonction renvoi un code d’erreur.
En cliquant sur le bouton Run au-dessus du code, le développeur peut tester sa fonction en modifiant la requête entrante : en-tête, corps, verbe, paramètre d’URL … Le développeur peut également récupérer un lien afin de tester sa fonction via l’URL du site. En étudiant plus précisément la fonction, on se rend compte qu’elle est sauvegardée dans un fichier run.csx. L’extension .csx indique que les Azure Functions sont simplement des scripts C# qu’on exécute à la volée selon les besoins.
Sur la gauche du code, on peut voir que les Azure Functions regorgent de fonctionnalités.
Configuration d’une Azure Function
- Functions: Azure Functions classique avec des options de déclenchement et de monitoring ;
- Proxy : fonctionnalités capables de créer plus rapidement des APIs à partir d’Azure Functions, Cela permet notamment d’agréger plusieurs fonctions en un seule API ;
- Slots : options de déploiement en silo pour les Azure Functions (prod, staging …).
Le développeur a ainsi accès à un paramétrage plutôt complet pour ses fonctions. Les IDE Visual Studio et Visual Studio Code permettent également de développer des Azure Functions localement ou en mode remote selon les besoins.
Azure Logic App
L’offre Logic App de Azure permet de connecter l’application Cloud de diverses manières et avec des centaines de connecteurs différents (Office 365, Twitter, Dropbox …) et ceci avec 0 ligne de code. Logic App est vraiment une solution d’intégration pour la plateforme Cloud, et le principal concept est le workflow : on enchaîne des étapes qui vont chacune pouvoir interagir avec les centaines de connecteurs disponibles pour lancer une action, un code, une Azure Function … Il est même possible de mettre des conditions et des boucles. Sur le même principe que les Azure Functions, une Logic App se déclenche lors d’un événement.
Au niveau des actions possibles, il en existe des centaines également. Par exemple, vous pouvez demander aux cognitives services d’analyser un texte afin de déterminer l’humeur du message. Ou alors vous pouvez envoyer un mail, un SMS, un message dans Teams ou Slack, et tout ceci sans une seule ligne de code.
Dès la création d’une Logic App, Azure nous propose les déclencheurs les plus populaires que le développeur peut utiliser. En dessous Azure nous propose des templates de Logic App les plus communs.
Déclencheurs Azure Function
Prenons le déclencheur ‘When a http request is received’. Azure va générer pour nous une URL lorsque nous allons sauvegarder l’application. On se retrouve alors dans un designer où l’on peut facilement rajouter de nouvelles étapes, tout ceci sans code. Il est également possible de rajouter un schéma JSON pour le corps de la requête HTTP afin d’obliger l’appelant à mettre des paramètres.
{
"type": "object",
"properties": {
"Name": {
"type": "string"
}
}
}
Ensuite, nous allons rajouter une étape d’envoi de mail. Le workflow de notre application est donc le suivant : lorsque que l’URL est appelée, envoi d’un mail avec le paramètre dans le corps du mail. L’étape de l’envoi de mail est la suivante :
Etape d’envoi de mail
Avec un utilitaire comme Postman, il suffit de simuler un envoi sur l’URL fourni par Azure, et constater qu’un email est envoyé à chaque fois que l’URL est requêtée.
Mail envoyé
Le développeur a accès ainsi à des milliers de scénario possible selon son workflow et les déclencheurs qu’il va utiliser.
Azure Event Grid
Avec Azure Functions et Azure Logic App, les applications basées sur événements peuvent grandir et l’architecture devient alors trop complexe pour assurer une maintenabilité optimale. L’offre Azure Event Grid intervient afin de simplifier la gestion des événements dans ce genre de situation.
Azure Event Grid
L’objectif de Event Grid est de proposer une fonctionnalité capable de centraliser les événements tout en garantissant le minimum de latence possible entre la ressource qui a émis l’événement et l’application qui s’est branché dessus, pour atteindre le quasi temps réel. Event Grid met en œuvre également des fonctionnalités telles que :
- Routage intelligent des événements ;
- Filtrage des événements ;
- Connexion multi-application ;
Il existe 2 notions importantes dans Event Grid : les Topics et les WebHooks. Les Topics sont des regroupements d’événements, permettant ainsi de les catégoriser. Un émetteur va alors envoyer des événements à ces topics, et peut également répondre à des événements relayer par les topics. Les WebHooks sont simplement des callbacks HTTP qui vont permettre de répondre aux appels envoyés aux topics.
Dans le portal, lorsqu’on créé un Event Grid Topics, Azure nous génère une URL qui va pouvoir être utilisé par les autres ressources Azure pour publier des événements.
Info Azure Event grid
Ensuite, il suffit de rajouter des Subscriptions. Avec notre Logic App précédente, il suffit de mettre l’URL de la Logic App en Endpoint afin qu’elle réponde lorsque le Topics est appelé, et le tour est joué !
Ajout d’une souscription Event Grid
Conclusion
Le Serverless dans Azure possède un grand nombre d’avantage : interconnexion, réactivité, souplesse, scalabilité. Les piliers de la programmation Serverless restent indéniablement les événements générés par les différentes ressources et / ou systèmes gravitant autour de Azure, et offre ainsi des capacités infinies tant sur le plan de l’intégration avec des systèmes d’entreprises que des scénarios possibles.
