Série : Azure “Functions” – Serverless

Azure Functions est un service de calcul serverless qui vous permet d’exécuter du code déclenché par des événements sans provisionner ni gérer explicitement l’infrastructure.

Introduction

Avant de plonger dans ce service de calcul. Nous allons faire une présentation de ce qu’est le serverless puisque nos futures functions sont à proprement parlées serverless.

Je ne ferai qu’une présentation succinctes de cette infrastructure.

Serverless

Si nous faisons une traduction à la “française” nous obtiendrons “sans serveur”, ah !!!, enfin plus de serveur, plus d’administration, plus de scale-out ou scale-up. D’investissements hors-normes…. et bien non rien de tout cela. Il est vrai que vu de l’extérieur et pour un client final potentiel, il se dit : comme je ne gère pas de serveurs c’est qu’ils n’hésitent pas.

Oui, mais fallait surtout compter sur Microsoft ou tout autres CSP pour le faire à sa place et en toutes transparences.

Nous pouvons dire qu’une infrastructure serverless est le faite de cacher tout ce qui a un rapport de prêt comme de loin aux serveurs. Cela va permettre au client final de se focaliser uniquement sur son code dans quasiment n’importe quelle langage (supporté par le CSP bien sûr).

C’est lors de son exécution que le dimensionnement pour son exécution sera fait. Autre avantage et non négligeable, l’utilisateur final ne va payer que le temps d’exécution du traitement (temps de calculs, ressources, etc…) et rien d’autres.

Le client va configurer une seule fois, l’environnement d’exécution de son traitement, on parlera souvent de fonctions. Vous voyez où Microsoft veut en venir.

FaaS – Function as a Service

Certains appels cela aussi le FaaS ou Function as a Service. Pour ma part, je vois plus avec FaaS un sous ensemble de cette infrastructure servless. On doit pouvoir utiliser d’autres services dans ce mode comme par exemple les base de données. Imaginer simplement que les procédures stockées soient en mode serverless nativement car on pourrait dire d’exécuter celles-ci dans une Function.

Où la base de données sans serveur (stockage d’objets par exemple) où sont déterminés les capacités de connexions, de requête, etc… avec un modèle d’élasticité à la demande tant dans l’infrastructure et donc le prix.

Aussi le le traitement de flux, les événements, en utilisant des fils d’attente, je pense à Apache Kafka.

On pourrait aussi surement sans service dans les passerelles pour les API.

Mais comme toutes technologies, il existe des inconvénients non négligeables et à prendre en compte le plus en amont avant le choix du serverless.

Contraintes

Jeunesse

Et oui cette technologie n’a environ que deux ans et par voie de conséquences le nombre d’acteurs sur le marché ayant les reins assez solide pour faire du bon serverless ne sont pas légions : Microsoft avec Azure Functions, Amazon avec son service Amazon Lambda et IBM, d’autres en second plan comme Google avec ses Cloud Functions.

De plus, ils doivent être en mesure de faire de déploiement à large échelle, du monitoring, de la sécurité etc…

Migration

A l’heure actuelle chaque CSP à sa vision du servless est donc une migration d’un CSP vers un autre peut s’avérer compliquer et couteux. Car le développement est fonction des langages mises à disposition par le CSP et aussi sur les bonnes pratiques de développement de leur technologie.

Temps d’exécution

Et oui, toujours avoir à l’esprit le temps d’exécution de notre traitement. Je ne parle pas de l’élasticité mais du temps d’exécution, de traitement. Imaginez un process de traitement de longue durée. Nous allons perdre cet avantage qui est le retour sur investissement sur le temps et les ressources utilisées. Là on pourrait se poser la question de revenir vers un traditionnelle traitement sur un serveur.

Couplage

C’est ce que j’ai plus ou moins présenté lors d’un migration. Forcément comme le CSP nous fait des abstractions et donc de tirer partie de l’écosystème du CSP. Nous devons utiliser des modèles d’architectures de développement spécifiques qui pour certains clients finales va à l’encontre de leurs politiques. Ils préféraient s’arrêter au niveau de conteneurisation par exemple.

Démarrage à froid

Et oui, le principe même du FaaS c’est de répondre à l’appel, et de s’arrêter nette après le traitement. Pour certains traitement ce n’est pas primordiale, que lors de l’appel, il faut contextualiser l’exécution de la fonction. Mais dans certains cas, par exemple, dans le monde de la finance ou le temps réels est roi, une latence faible peut être inacceptable.

Monitoring, débogage

Ces impératifs fonctionnels sont déjà difficiles dans une architecture distribuées. Alors imaginez une architecture “sans serveur” et orientés micro-service…

Résumé

Voilà, notre première insertion dans le monde du serverless avec pour cible le FaaS. Dans le prochain billet on va s’orienter sur les Azure Function de Microsoft biensur.

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 :