Serverless ou FASS (Function as a service), une révolution ?

Ces dernières années, les architectures en microservices ont permis de diminuer le coût de développement. Mais cette migration vient avec son lot de contraintes, parmi lesquelles la gestion lourde et coûteuse de l’infrastructure.

Un nouveau paradigme, celui du serverless vient avec la promesse de diminuer ce coût de gestion de l’infrastructure.

Serverless, qu’est-ce que c’est ?

Initié par AWS en 2014 avec son service Lambda, le serverless est un modèle de cloud-computing où le développeur n’a plus qu’à fournir son code, sous forme de fonctions, au provider de service serverless ou FAAS (pour Function As A Service). Afin d’exécuter la logique métier contenue dans cette fonction, il suffit à l’application de requêter le Cloud Provider chez lequel la fonction est hébergée. Résultat : c’est le Cloud Provider qui va se charger de maintenir les serveurs, et de garantir que la fonction continue de répondre chaque fois qu’elle est interrogée.

Aujourd’hui les principaux Cloud Provider du secteur du serverless sont :

Les prérequis pour introduire le serverless dans votre organisation

Un découpage en fonctions

Il est conseillé de repenser l’application – au moins partiellement – pour la découper en fonctions qui détiennent chacune une responsabilité précise. Ce découpage est comparable au passage d’une architecture monolithique à une architecture en microservices. Par conséquent, si votre produit est déjà basé sur une architecture microservices, passer au moins partiellement au serverless sera bien plus facile.

La compatibilité du code

Étant donné que la fonction sera hébergée et déployée sur un Cloud Provider serverless, elle doit respecter les règles mises en place par le Cloud Provider choisi.

Les deux règles principales sont :

• les langages : AWS Lambda n’accepte par exemple nativement que des fonctions écrites en C#, Java, Node.js, Go, Ruby ou Python. Des solutions existent néanmoins afin de pouvoir faire fonctionner n’importe quel autre langage, comme PHP par exemple, sur Lambda.

• le respect du temps limite d’exécution de la fonction (15 minutes sur AWS Lambda mais ce temps limite est abaissé à 30 secondes si l’événement qui invoke la fonction est une requête HTTP)

Screenshot de la console AWS

Les avantages et inconvénients du serverless

Avantages :

• Scaling automatique

C’est le Cloud Provider qui s’assure que la fonction réponde systématiquement chaque fois qu’elle est appelée. Par conséquent, si votre application est deux fois plus utilisée en journée que la nuit, le Cloud Provider doublera automatiquement le nombre d’instances de la fonction.

• Vous ne payez que ce que vous utilisez

Les Cloud Providers serverless facturent en se basant sur la mesure en millisecondes du temps de calcul réel effectué par leurs serveurs. Plus besoin de payer constamment pour le nombre de serveurs qu’il vous faut en période de pic. Et même mieux, si votre fonction n’est pas utilisée, vous ne payez pas.

Quand on sait que la plupart des organisations n’utilisent en moyenne que 10% du temps de calcul réel de leurs serveurs, on voit que le gain potentiel est important. Et quand on pense que ces serveurs tournent bien souvent pour ne rien faire, on voit également l’intérêt sur le plan écologique : si votre code ne fait tourner des serveurs que lorsqu’il est exécuté, c’est autant d’économie d’énergie pour la planète.

Enfin, cela incite à entretenir et améliorer la performance du code, car plus le code est performant, moins son exécution est coûteuse et moins vous êtes facturés.

Source : serverless.com

• Diminution du coût de la gestion de l’infrastructure

Une architecture serverless permet au développeur de se concentrer sur le code qu’il produit en faisant abstraction des contraintes d’infrastructure (supervision, load balancing, puissance, problèmes de stockage).

• Une architecture agnostique

Grâce au serverless, chaque portion du code détenant une partie spécifique de la logique métier est agnostique de la technologie utilisée pour implémenter d’autres parties de l’application. Imaginez que vous avez une application Node.js et que vous aimeriez utiliser des algorithmes de Machine Learning en Python, il vous suffira que ces algorithmes soient exécutés dans une fonction serverless spécifique.

Inconvénients :

• La dépendance aux Cloud Providers

Pour commencer, chaque Cloud Provider a son propre framework. Il vous faudra non seulement respecter ses règles (langages, temps limite d’exécution…), mais également adapter votre application dans le cas où celles-ci évolueraient.

Par ailleurs, comme les règles peuvent être différentes d’un Cloud Provider à un autre, migrer de l’un à l’autre peut s’avérer difficile et coûteux.

• Un serveur qui ne vous appartient pas

Comme votre code tourne sur un serveur qui n’est pas le vôtre, vous n’avez pas la main dessus et vous dépendez des outils du Cloud Provider pour le monitoring par exemple. Bien que les Cloud Providers les améliorent, ces outils sont encore loin d’être parfaits.

Par ailleurs, comme le code tourne sur un serveur qui ne vous appartient pas, cela introduit un risque en cas de perte catastrophique de données. Cela peut également introduire des contraintes de type RGPD, bien qu’il semble que cette question ne soit pas encore définitivement actée dans le cas du serverless.

• Des limitations techniques

Le serverless est une technologie encore en cours de développement. Jusque récemment, il n’était par exemple pas possible d’utiliser des WebSockets sur Lambda de AWS. Il faut donc vérifier que les technologies sur lesquelles s’appuient votre application sont bien supportées par le Cloud Provider que vous choisirez.

• Une technologie encore jeune

Les technologies serverless évoluent très vite. Par conséquent, certains outils ne sont pas encore totalement matures (comme c’est le cas des outils de monitoring par exemple). Par ailleurs, il n’y a toujours pas de bonnes pratiques connues sur certains sujets, comme le niveau de granularité attendu dans le découpage des fonctions.

Est-ce que le serverless est adapté pour mon projet ?

Use cases

Actuellement, le serverless est utilisé dans les domaines où l’exécution du code est déclenchée par un événement métier comme dans les applications IoT et les applications mobiles. Plus généralement, le serverless est très adapté chaque fois qu'on rencontre un fonctionnement event-driven comme c'est le cas pour l'authentification, ainsi que pour des systèmes experts et des algorithmes de Machine Learning.

Par ailleurs, depuis sa naissance en 2014, la technologie serverless a beaucoup évolué. Elle devient un choix de moins en moins limitant sur le plan technique. Il est tout à fait possible de s'en servir à présent pour exposer des APIs ou servir des sites internet, mais aussi faire du traitement d’information qu’il soit en temps réel ou par batch.

Parmi les entreprises qui utilisent le serverless :

• Netflix : encodage automatique des fichiers médias ; automatisation de la gestion du backup, monitoring d’autres services AWS.
• Codepen : réduction du coût de la gestion de l’infrastructure. Un unique SRE gère une infrastructure serverless capable de répondre à plus de 200000 requêtes en période de forte demande.
• Transdev : traitement de données de transport en temps-réel.
• 20 minutes : les dernières applications mobile de 20 minutes sont entièrement basées sur le serverless.

Contre-indications

Le serverless est plein de promesses mais il n’est pas adapté pour tous les cas d’usages.

Du fait de la limitation du temps d’exécution, il est inadapté aux tâches lourdes et complexes comme du traitement vidéo, ou aux tâches qui nécessitent de maintenir une connexion active avec ses clients.

D’autre part, si votre code est exécuté à intensité constante, le serverless coûtera plus cher à votre organisation qu’un hébergement classique.

Néanmoins, ces contraintes s’appliquent peut-être uniquement à une partie de votre application.  Dans le cas où d'autres parties, comme l’authentification par exemple, ne nécessitent pas de ressources allouées en permanence, il est possible de les externaliser dans une fonction serverless.

Une alternative aux Cloud Providers, le serverless in house

Depuis 2016, différents frameworks prennent de l’ampleur notamment OpenFaas et Knative. Ils permettent de construire des applications serverless en se basant sur Kubernetes et les héberger soi-même.

Cette solution permet de ne plus dépendre des Cloud Providers comme AWS ou Azure, et évite donc les inconvénients qui leurs sont liés. Plus besoin de soumettre votre application aux règles des Cloud Providers pour faire du serverless et bénéficier d’un scaling automatique ou d’une architecture agnostique. Néanmoins, votre organisation est de nouveau responsable des serveurs sur lesquels votre code est exécuté.

Conclusion

Le serverless permet d'accélérer le passage d'une idée à sa mise en production. Dans les nombreux cas où il est adapté, il est donc une excellente solution pour diminuer le coût de gestion de l’infrastructure et augmenter l’impact de vos développeurs sur votre métier.

Que vous souhaitiez démarrer un nouveau projet avec une technologie de pointe ou que vous cherchiez à réduire les coûts de gestion de votre infrastructure, le serverless est une technologie à envisager sérieusement.