Série : Azure “Functions” – Présentation

Azure Functions un peu plus en profondeur avec les liaisons d’entrées et de sorties, les déclencheurs. Les langages supportés

Comme nous l’avons présenté dans le billet précédent les Azure Functions font partie des services orientés serverless soit donc le client n’a absolument pas besoin de se préoccuper de l’infrastructure serveurs.

Elle existe, bien évidemment.

Le client va donc pouvoir se focaliser sur le code de sa fonctions uniquement.

Le coût de celle-ci ne sera que son temps d’exécution, rien d’autre.

On parle aussi de FaaS. Pour ma part, je préfère le terme Azure Functions voir même Functions que FaaS.

Alors maintenant regardons de plus prêt et essayons de définir ce que sont les Azure Functions.

Une “Azure Functions” est la possibilité donnée à l’utilisateur d’exécuter d’un ensemble d’instructions / code sans se préoccuper de l’infrastructure sous-jacente et donc serveur. Pas besoin, de savoir si tout cela est à jour. Microsoft le fait pour nous. Microsoft et sa plateforme Cloud nous apporte les garanties d’élasticité et de haute disponibilité.

Principe de fonctionnement

C’est bien beau mais bon, j’ai écrit mon Azure Functions, je l’ai testé en local et déployé dans un groupe de ressource dans ma souscription, je vous rassure tout de suite, je ferai des exemples. La question est comme faire pour les exécuter.

On va alors parler de la notion de déclencheur .

Les déclencheurs

Les déclencheurs sont donc à l’origine de l’exécution d’une fonction. Celle-ci à besoin donc d”être déclenché par un événement. Ces événements peuvent être de différentes natures. Voici quelques exemples de déclencheurs :

  • File d’attente : une message arrive dans une file d’attente et déclenche une fonction ;
  • Requête HTTP : Une fonction se déclenche lors de l’arrivée d’une requête de type HTTP ou retourner une réponse HTTP par le biais d’une fonction ;
  • Des modifications dans une structure de données déclenche une fonction. Une fonction effectue une lecteur ou une écriture de données.

Je ne m’étendrai pas sur la liste exhaustives des déclencheurs car ce n’est pas mon but, ni celui de ce billet.

Mais bon, j’ai développeur ma fonction, elle se trouve dans Azure, elle fonctionne par un déclencheur, elle fait son job. Mais je reste sur ma faim là. Pourquoi, prenons l’exemple suivant :

  • Recevoir une requête HTTP ;
  • Effectue son traitement ;
  • Retourne une réponse HTTP.

C’est le principe des WebHooks. Si l’on regarde de plus prêt cet exemple, il nous manque une notion, comment je fais pour retourner une réponse HTTP simplement. Une nouvelle notion est introduite, celle des liaisons.

Les Liaisons

On peut tout à fait développer les entrées et sorties de nos fonctions mais nous allons augmenter la frictions entre notre code. Le but quand même c’est avant d’avoir une bonne architecture et d’éviter d’avoir à redévelopper ou à développer pour x services, ca fait désordre !!

C’est dans ce sens que les liaisons vont nous aider dans la facilité d’écriture car elle se fera de façon déclarative en fonction du langage utilisé. Pour faire simple, pour le C# ont aura la possibilité par des attributs pour la décoration des méthodes et des paramètres et pour les autres il faudra utilisé d’un fichier JSON, function.json.

Ah !! et oui on peut écrire des fonctions dans différents langages. En tenant compte que le langage choisit sera unique au niveau d’une application de fonction.

  • C# (ouf !! me voilà rassuré lol)
  • JavaScript
  • F#
  • Java
  • PowerShell
  • Python
  • TypeScript

Tout ces langages sont disponibles sous certaines conditions dont celles de la version du runtime des Azure Functions.

Il faut aussi retenir qu’il existe trois types, on parlera du sens de la liaison :

  • Les liaisons d’entrées ;
  • Les liaisons de sorties ;
  • Plus rarement les liaisons d’entrées/sorties.

Mais que faire avec des Fonctions ?

Il faut bien avoir à l’esprit que les Fonctions Azure ne sont pas faites pour faire des traitements longs. Je ne parle pas là, de scale-in / scale-down mais sur le traitement par lui-même. Car il arrivera un moment où le coût sera plus élevé que celui de faire une architecture avec serveur (VM par exemple).

Elles sont particulières utiles dans l’IoT, pour faire des traitements en bloc comme sur les données par exemple, des micro-services ou encore des API basiques. Il existe déjà des modèles mis à disposition par Microsoft comme par exemple :

  • Basé sur les requêtes HTTP (comme l’exemple du Web Hook) ;
  • Déclencher tout les x temps avec le Minuteur ;
  • Le Event Hub pour le traitement d’événements massif (IoT) ;
  • La modification de données sur des objets blob avec le Stockage Blob

Et il en existe encore bien d’autres.

Résumé

Voilà, notre première plongée dans les méandres des Azure Functions de Microsoft. On n’a vu les principales notions qui sont :

  • Les déclencheurs ;
  • Les Liaisons et leurs différents types ;
  • Les différents langages pour leurs développement ;
  • Les domaines d’applications (quelque uns) ;
  • J’ai volontairement fait l’impasse sur toutes la parties des coûts de fonctionnement, ici et dans les autres billets concernant Azure je ne prendrai que l’optique technique.
Stay tuned logo

Frédéric Schmidt

Lead Technical Architect.

Ajouer un commentaire

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Recent Comments

    %d blogueurs aiment cette page :