Les avantages et inconvénients du serverless
1.7 Qu’est-ce qui ne fonctionne pas en Serverless ?
Jusqu’à présent, nous avons définis le terme Serverless pour signifier l’union de 2 principes – « Backend as a Service» et «Functions as a Service».
Avant de commencer à examiner la promesse que peut offrir ce nouveau type d’architecture, nous aimerions d’abord expliquer ce qui n’est pas Serverless.
Actuellement lorsque l’on recherche ce terme, nous pouvons trouver de nombreuses définitions ou assimilations erronées.
1. PaaS (Platform as a Service)
On peut en effet trouver des similitudes entre certains services PaaS comme Heroku et les services FaaS, certaines pensent même que FaaS est une extension de PaaS. Mais comme dit Mike Roberts, co-fondateur de l’entreprise Symphonia.
La plupart des applications PaaS ne sont pas destinées à ramener des applications complètes vers le haut et vers le bas pour chaque demande, alors que les plates-formes FaaS font exactement cela. …
La différence opérationnelle clé entre FaaS et PaaS est la mise à l’échelle.
Avec la plupart des PaaS, vous avez encore besoin de réfléchir à l’échelle, par exemple avec Heroku combien de Dynos vous souhaitez exécuter.
Avec une application FaaS, cela est complètement transparent. Même si vous configurez votre application PaaS à l’échelle automatique, vous ne le feriez pas au niveau des demandes individuelles (sauf si vous avez un profil de trafic très précisément façonné), et donc une application FaaS est beaucoup plus efficace en matière de coûts.
2. Container
La conteneurisation subit une popularité croissante de nos jours, surtout depuis l’arrivée de Docker. Nous pouvons en effet trouver certaines similarités entre FaaS et la conteneurisation.
Mais rappelons-le, FaaS offre une couche d’abstraction telle que nous n’avons plus la notion de processus système au contraire de Docker qui est basé sur du la notion de processus unique.
Parmis ces similitudes, nous retrouvons l’argument de la mise à l’échelle. Fonctionnalité disponible niveau conteneur grâce aux systèmes tels que Kubernetes, Rancher ou Mesos.
Dans ce cas nous pouvons nous poser la question du pourquoi faire du FaaS alors que nous pouvons faire du conteneur ?
Il faut savoir que malgré le buzz autour de cette technologie, elle reste toujours immature et de nombreuses entreprises ont encore du mal à basculer leur infrastructure de conteneur en production.
De plus les systèmes de mise à l’échelle niveau conteneur est encore loin d’arriver au niveau de celle des FaaS même si cet écart tend à se réduire avec l’arrivée de nouvelles fonctions telles que Horizontal Pod Autoscaling pour Kubernetes.
Finalement, le choix de la technologie se fera selon les cas d’utilisations.
1.8 Les avantages et inconvénients du serverless
1.8.1 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 notre 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.
* Nous ne payons que ce que nous utilisons
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 nous faut en période de pic.
Et même mieux, si notre fonction n’est pas utilisée, nous ne payons 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 notre 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.
* 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 nous avons une application Node.js et que nous aimerions utiliser des algorithmes de Machine Learning en Python, il nous suffira que ces algorithmes soient exécutés dans une fonction serverless spécifique.
1.8.2 Inconvénients :
* La dépendance aux Cloud Providers
Pour commencer, chaque Cloud Provider a son propre framework.
Il nous faudra non seulement respecter ses règles (langages, temps limite d’exécution…), mais également adapter notre 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 nous appartient pas
Comme notre code tourne sur un serveur qui n’est pas le nôtre, nous n’avons pas la main dessus et nous dépendons 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 nous 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 notre application sont bien supportées par le Cloud Provider que nous choisirons.
* 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.
1.9 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 nos développeurs sur notre métier.
Que nous souhaitions démarrer un nouveau projet avec une technologie de pointe ou que nous cherchions à réduire les coûts de gestion de notre infrastructure, le serverless est une technologie à envisager sérieusement.
Attention à l’étymologie
Le terme « Serverless» est source de confusion car, dans de telles applications, il existe à la fois du matériel et des processus serveur.
La différence avec les approches basiques est que l’entreprise créant et prenant en charge une application dite Serverless ne s’occupe pas du matériel ou des processus, ils externalisent cela à un fournisseur (AWS, Google, …) et ainsi se concentrent uniquement sur la partie fonctionnelle de l’application.
