Impossible d’être passé à côté de ce terme ces dernières années : « serverless ». Tout le monde en parle, toutes les sociétés veulent y passer (Twitter qui déplace 300PB de données vers GCP, SNCF chez Azure pour du BigData, Airbnb qui migre ses bases de données chez AWS) et pourtant, sans pratique le terme et tout ce qu’il englobe restent flou.
Qu’est-ce que le serverless
Démystifions tout de suite le terme, puisque littéralement « serverless » se traduit par « sans serveur » : ce n’est pas le cas. Il n’est ici pas question de magie, des machines physiques sont biens évidemment requises. Cela signifie plutôt qu’il n’y a pas à gérer de serveurs, mais pas seulement.
Le serverless désigne un ensemble de services qui sont proposés par les fournisseurs de cloud et qui nous permettent de s’abstenir de la gestion des machines. Les services varient en fonction des fournisseurs mais l’on retrouve toujours une base commune :
- Function as a Service (FaaS) ;
- Stockage de fichiers ;
- Base de données ;
- APIs ;
- Etc.
Le service le plus utilisé étant le FaaS. Celui-ci permet de mettre en ligne une fonction, en une ligne de commande ou quelques clics dans une interface graphique.
Parmi les fournisseurs de cloud les plus connus on citera AWS (Amazon), Azure (Microsoft) et GCP (Google).
L’informatique sans serveur ou “serverless computing” est un paradigme de cloud computing dans lequel le fournisseur de serveur gère dynamiquement les ressources allouées au service client. Le prix dépend des ressources effectivement consommées et non des capacités d’un serveur acheté à l’avance.
https://fr.wikipedia.org/wiki/Informatique_sans_serveur
Le mot important dans cette définition est « paradigme ». Le serverless nécessite de complètement revoir sa façon de penser et de concevoir des applications. Plus de gestion d’environnements mais surtout plus de monolithes applicatifs, il faut penser en services !
Les avantages du serverless
Pas de gestion des machines
La section précédente évoque rapidement le premier (et peut-être le plus gros) avantage du serverless : plus de gestion de machines, qu’elles soient physiques ou non (VM, conteneurs…). Il est important d’insister sur ce point et de comprendre ce qu’il implique.
Habituellement la phase de conception d’une application (ou d’un site web) comprend l’infrastructure à mettre en place. Cette infrastructure doit répondre aux contraintes métier, aux futures évolutions et à la volumétrie attendue. Vient ensuite l’étape d’installation et de configuration des machines, qui peut aller de plusieurs heures à plusieurs jours en fonction des applicatifs et des intermédiaires. Si votre application elle doit être hautement disponible : il faut dédoubler toutes vos machines pour avoir de la redondance, ce qui rajoute un load balancer et la mise en place de VPC. Une fois en production, il faut maintenant monitorer le trafic afin de constater si l’infrastructure en place répond à la charge, etc.
Mettre en place une infrastructure système est coûteuse et ce n’est que sa mise en place ! Une infrastructure vit, avec le temps elle a besoin de maintenance : mises à jour des systèmes d’exploitation, des runtimes, correction d’éventuelles failles de sécurité sont autant de tâches qui prennent du temps, et donc de l’argent.
Pas de gestion de la scalabilité
Avantage directement lié au précédent, la scalabilité. S’il n’y a pas de serveurs à manager il n’y a pas non plus de scalabilité à gérer, tout se fait (presque) de manière automatique !
Par exemple lorsqu’une lambda AWS ne tient plus la charge, une nouvelle instance de celle-ci apparaît. Une fois le pic de charge terminé, la ou les instance(s) supplémentaire(s) sont supprimées et ce de manière complètement transparente.
Résilience des services
Dans le même ordre d’idée que la scalabilité, la résilience des services. Il est très rare qu’un des trois plus gros fournisseurs de cloud subisse des problèmes sur son infrastructure. En plus de ne pas tomber, ces services peuvent être mis à jour en quelques clics sans aucun redémarrage. Plus besoin de planifier des opérations de maintenance avec coupure de services à la clé.
Une facturation au plus proche de la consommation
Si l’infrastructure répond à la charge automatiquement et est capable de multiplier le nombre de services disponibles pour répondre à ce besoin, il est évident que la facturation n’est pas fixe. Contrairement aux architectures système classiques où celle-ci est établie d’avance, avec le serverless vous ne payez que ce que vous consommez.
Les deux graphiques ci-dessous démontrent la différence de facturation entre des serveurs et des services serverless. En vert, le coût. En bleu l’utilisation.
Dans le premier cas, le coût ne varie pas en fonction de son usage. Dans le second le coût est directement liés à l’usage des services.
La tarification des différents services est faible, et celle-ci se fait au millième de seconde près.
Les désavantages du serverless
Nouveau paradigme
Utiliser le serverless plutôt qu’une infrastructure classique c’est changer de paradigme de développement, penser de manière différente la conception des applications afin de tirer profit de la multitude de services à disposition. C’est passer d’un monolithe à de multiples applicatifs, chacun ne faisant qu’une seule chose.
Changer la façon dont nous architecturons nos applications n’est pas chose aisée. Pour arriver à quelque chose de cohérent cela nécessite une connaissance de tout l’écosystème serverless afin d’identifier les services requis.
Les limitations techniques
Avec les années, le serverless devient de plus en plus mature et nous impose de moins en moins de limitations : il existe quasiment un service pour tout ce que nous faisions avant dans notre architecture monolithe. La majorité des limitations techniques se retrouve sur les services FaaS (AWS Lambda, Google Cloud Functions, Azure Functions, etc.) qui, en fonction du fournisseur cloud, varient.
La gestion de la facturation
Un des avantages du serverless en est aussi sa faiblesse : la facturation en fonction de la consommation.
Chaque service a une facturation différente qu’il faut comprendre mais surtout, qu’il faut estimer. Vous devez avoir une idée précise de votre consommation, service par service, de manière à déterminer son coût. Ne pas savoir exactement combien vous aller payer fait peur à de nombreuses sociétés quand bien même le coût total est fortement inférieur à celui d’une infrastructure classique.
Le coût d’entrée
Outre le changement de paradigme, le coût d’entrée technique est élevé : il faut connaitre tout l’écosystème disponible afin d’en tirer profit, comprendre comment chaque service fonctionne, comment les faire communiquer entre eux, comment leur appliquer les bonnes autorisations et les bons droits, etc.
Qui dit nouveaux services dit nouvelles librairies. Vous allez passer un certain temps à éplucher les documentations des SDK qui seront utilisés, SDK plus ou moins buggés en fonction du service, du langage et du fournisseur cloud. Il en va de même pour les documentations : plus ou moins claires, à jours ou complètes.
Tester localement
Ne pas avoir à gérer son infrastructure offre de nombreux avantages mais cela signifie qu’il est très difficile, voire impossible, de la reproduire localement pour tester. Un workflow classique consiste à développer sur votre machine, mettre en ligne votre code et la configuration des divers services utilisés.
Conclusion
Il est indéniable que passer au serverless offre de nombreux avantages, le principal étant une forte réduction des coûts d’infrastructure et de sa maintenance associée. Bien évidemment il existe des désavantages mais avec un peu d’expérience ceux-ci s’effacent vite et laissent place à une productivité accrue et à des applications plus performantes et réactives.
Cependant, migrer des applicatifs existants vers les solutions serverless n’est en rien comparable à un changement d’infogéreur. Cela requiert de repenser complètement la façon dont votre application est conçue et d’adapter les processus et méthodologies de développement.
Le serverless ne convient pas à toutes les typologies de projets ou d’entreprises, comme pour tout il faut évaluer les pour et les contre avant d’y foncer tête baissée, mais si vous sautez le pas vous risquez d’être agréablement surpris.
