[Post IT] Architectures “Serverless” : Des applications sans serveurs ?

 La fin des serveurs ?

Une architecture “Serverless” est une architecture où, à aucun moment, on ne verra apparaître un serveur ou une VM sur un schéma.

Comment cela est-il possible ? Avec l’utilisation de composants “clé en main” uniquement, disponibles sur le cloud. Par exemple on stockera ses fichiers sur AWS S3, ou ses documents dans DynamoDB, pour ne citer que ces 2 services Amazon Web Services (AWS).

 

Et la logique métier ?

Celle-ci est traditionnellement implémentée sous forme de code, quel que soit le langage choisi, qui s’exécute sur un serveur. Dans le modèle serverless, la logique métier va être implémentée sous forme de fonctions (d’où la terminologie “Function as a Service” ou “FaaS”) et c’est le fournisseur Cloud qui portera la responsabilité d’exécuter la fonction “au moment opportun” (souvent suite à un événement particulier).

Il y a donc évidemment toujours, quelque part, un ou des serveurs dans une architecture “Serverless”. Toutefois, le fournisseur Cloud fournit d’une part une abstraction des serveurs qui vont exécuter le code (on ne configure pas le serveur, on ne déploie pas le code dessus, on ne le manage pas non plus) et d’autre part la garantie de la bonne exécution des fonctions.

 

Bénéfices

Les architectures Serverless ont plusieurs qualités qui le rendent très attractif pour la conception d’applications.

Facteurs économiques :

  • On réduit les coûts de façon importante car on ne paye plus une VM dont le taux d’utilisation sera variable en fonction de l’activité métier (heure de la journée, mois, soldes, etc). L’auto-scaling permet dans une certaine mesure d’accomplir la même chose, mais quand on sait qu’AWS Lambda est facturé par tranche de 100ms d’exécution, on réalise que la granularité est d’un tout autre ordre de grandeur.
  • Réduction du coût d’exploitation également : pas de VM à superviser, à patcher, sauvegarder etc

Facteurs techniques :

  • Le scaling est automatique, c’est le fournisseur Cloud qui se chargera d’orchestrer le cycle de vie des VMs / conteneurs et autres de façon à adresser la charge
  • Tolérance à la panne : les fonctions sont lancées en multiples instances
  • Sécurité : Pas de VM à sécuriser, pas de comptes génériques. Les fonctions disposent de permissions aussi granulaires que le permet le fournisseur de Cloud (par exemple une Lambda pourra accéder à une table dans DynamoDB en lecture, et n’aura aucune autre permission)
  • Comme dans le cas des conteneurs on est dans une approche micro-services. Une fonction réalise une et une seule tâche. Toutefois, là où les conteneurs embarquent tout le runtime nécessaire à son exécution (librairies, middleware, code, …), la fonction ne contient que le code à exécuter. L’environnement et son runtime nécessaires à l’exécution de la fonction sont standardisés, fournis et maintenus par le fournisseur Cloud. On a donc une granularité bien plus fine que dans le cas d’un conteneur.
  • La facturation se faisant en temps de compute consommé par la fonction, on a un lien direct entre la performance du code et la facturation : Plus le code est efficace, moins il coûtera cher.

Les années passées ont vu se dérouler les transitions suivantes : serveurs physiques => machines virtuelles => conteneurs. Dans un certain sens on peut considérer que le FaaS est l’évolution la plus récente de ce processus de rentabilisation des cycles CPU.

Le Serverless facilite l’innovation dans la mesure où il permet de se concentrer sur l’application, la logique business, le service rendu sans se préoccuper de la maintenance des serveurs.

Inconvénients

Le Serverless semble avoir de nombreux atouts. Pour autant, peut-on l’utiliser systématiquement ? Toute nouvelle architecture doit-elle être serverless ?

Clairement, la réponse est non.

Si le Serverless semble parfait pour des applications qui sont asynchrones et événementielles (“event-based”), il convient moins bien dans les cas ci-dessous :

  • Quand on a besoin de faible latences : Les fonctions sont souvent exécutées au sein de conteneurs. Si une fonction est rarement sollicitée, le fournisseur Cloud sera amené à arrêter le conteneur pour optimiser les ressources. On peut donc occasionnellement rencontrer un temps de “warm up” le temps que le conteneur soit redémarré.
  • Quand la fonction nécessite un temps d’exécution important : Les fonctions sont plutôt dédiées à des tâches simples et rapides (d’où la facturation par tranche de 100ms de Lambda). Dans le cas d’AWS, on a une limite de 5 minutes d’exécution par invocation d’une fonction. On peut toutefois contourner cette limitation en revoyant le fonctionnement applicatif afin de couper une tâche en fonctions plus petites.
  • Quand on a des tâches qui sont synchrones par nature : Le modèle Serverless est événementiel par nature, donc asynchrone. On peut éventuellement revoir l’architecture de l’application pour rentrer dans un modèle asynchrone.
  • Les appels des fonctions sont indépendants (“stateless”) : Si l’application demande à avoir un suivi de session, il faudra gérer soi-même la conservation de l’état entre les appels. On pourra avoir recours à un système de cache où à une BDD orientée documents pour stocker les données de session si besoin.

Pertinence de ce type d’architectures

Si on devait retenir 2 caractéristiques des architectures Serverless, ce serait :

  • Scalabilité de zéro à l’infini de micro-services
  • Particulièrement adapté à des applications asynchrones et à l’event-driven programming

Il se trouve que ces 2 caractéristiques sont particulièrement utiles à 2 uses cases : les applications mobiles et l’IoT.

Dans le cas des développements mobiles, on peut voir l’intérêt de ne payer que le strict minimum lors du lancement d’une application encore peu connue, mais de bénéficier d’une scalabilité infinie dans le cas idéal où l’application deviendrait virale et ainsi éviter que les blackouts et les ralentissements ne viennent entacher le succès tant espéré.

L’exemple récent du jeu Pokemon Go montre à quel point le capacity planning sur une nouvelle application est un exercice difficile :

mobile

Les objets connectés quant à eux suivent de façon inhérente un modèle événementiel : les senseurs mesurent, détectent, analysent et, le cas échéant, reportent une situation jugée intéressante. Ici on peut imaginer un objet connecté du type traqueur d’activité (FitBit et autres), qui pourrait être un cadeau à l’approche des fêtes de Noël, et un taux d’utilisation qui augmente brutalement avec les bonnes résolutions de début d’année… On veut définitivement une capacité à absorber la charge, et le modèle événementiel permet de traiter au fil de l’eau la remontée des informations des senseurs.

Ou encore l’aspirateur Roomba d’iRobot, dont l’infrastructure sera sans doute à terme entièrement serverless.

cloud

Les serveurs, indésirables ? D’après Ben Kehoe, “Cloud robotics research scientist” chez iRobot, après avoir autrefois traité les serveurs comme des animaux de compagnie, puis comme du bétail lors du passage au Cloud, il faut maintenant les considérer comme des cafards à l’ère du Serverless.

L’intérêt est cumulé car la plupart des objets connectés sont également contrôlables au travers d’une application sur mobile.

Toutes les applications ne se prêtent pas à l’utilisation d’une architecture Serverless. Toutefois il ne faut pas voir le Serverless comme une approche “tout ou rien”. Même dans une application fonctionnant sur une architecture “classique”, il peut être bénéfique de transformer certaines fonctions pour profiter des avantages offerts par le Serverless, un modèle hybride en quelque sorte.

L’offre commerciale

Il est intéressant de noter les volumes de recherche dans Google pour les différentes solutions de FaaS des Cloud providers sur les 2 dernières années :

graph1

graph2

Ces courbes représentent assez bien l’état actuel du marché.

En Novembre 2014, AWS annonce la disponibilité de Lambda, son service de FaaS. Ils ont littéralement initié la notion de Serverless, la courbe du mot clé Serverless ne commençant à décoller qu’à partir du début de 2016.

On note aussi que les alternatives existent chez la compétition, mais peinent à susciter l’intérêt car elles sont toutes très jeunes (les Azures functions ne sont disponibles que depuis Mars 2016, les Google Cloud functions sont en Alpha release, et IBM OpenWhisk est en statut Beta).

AWS a donc un statut de leader bien assis, même si la compétition est à présent lancée.

Conclusion

Serveurs physiques, machines virtuelles, conteneurs, et maintenant « Function as a Service » (FaaS) : A peine les conteneurs arrivent-ils à maturité qu’une nouvelle évolution du compute apparaît sous la forme du FaaS.

Cette technologie a certainement de l’avenir car elle répond à un besoin réel : Les applications mobiles et l’IoT sont des réalités en plein boom qu’on ne peut ignorer et qui sont particulièrement adaptées au FaaS.

Amazon a certainement pris de l’avance sur ce sujet, avec une offre solide, en lançant Lambda il y a 2 ans, mais la compétition a bien saisi l’importance de l’enjeu, et sont en train d’étoffer leurs catalogues pour fournir des services équivalents, même si ceux-ci manquent encore de maturité.

Références

 

Laisser un commentaire