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.
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 :
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.
É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 :
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.
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
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).
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.
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.
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.
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.
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.
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 :
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.
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é.
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.