Le Serverless apporte des promesses de liberté et de flexibilité, et il les tient. Mais cette liberté a un coût, celui de se retrouver enchaîné à l’innovation perpétuelle et à un environnement mouvant. Un moyen efficace de garder la maîtrise sur cette fuite en avant serait de penser l’industrialisation du provisionnement, du packaging et du déploiement de ses applications suffisamment tôt dans le cycle de vie du produit.
En préambule, voici quelques explications sur ce qui se cache derrière le terme Serverless. Le Serverless regroupe des solutions telles que des Platform as a service, Backend as a service, Function as a service. Autrement dit, cela regroupe une pléthore de services managés qui ont pour objectif de proposer aux développeurs un moyen de déployer leurs applications avec un minimum de configuration, sans avoir connaissance de l'infrastructure sous-jacente. Le tout en profitant d’une facturation à l’usage.
Ces services managés Serverless sont majoritairement proposés par des cloud provider (AWS, Azure, GCP, Scaleway, …) et apportent tout un pan de possibilités comme l'élasticité, la résilience, la réduction du time to market ou encore des innovations technologiques qui seraient onéreuses et chronophages à mettre en place.
Ceci étant dit, il est intéressant de se demander à quels besoins répondent ces services managés et s'ils sont adaptés à toutes les typologies d’applications.
Petit détour dans le temps, revenons en 2015, AWS lambda voit le jour et le terme Serverless commence à faire son apparition dans le jargon IT. Outre les premiers débats sur le mauvais message envoyé par le terme Serverless - parce que oui il y a toujours des serveurs en dessous - ce qui était novateur était le concept de “pay as you go”.
Dit comme de cette manière, cela paraît simple, mais la complexité technique permettant de porter le Serverless est bien présente. Elle est masquée à l’utilisateur et portée par les providers. Ce que le Serverless apporte réellement est donc une optimisation des ressources physiques et technologiques permettant l’allocation de ces ressources à la volée selon la demande. Mais ce n’est pas l’objet de cet article que d’exposer les dessous du Serverless, alors recentrons-nous sur les apports du Serverless et les types d’applications qui peuvent bénéficier de ce paradigme.
Le premier type d’applications qui tire parti du Serverless est celui des applications qui passent à l'échelle. Les startups illustrent bien cet usage, avec une volumétrie qui augmente rapidement de quelques utilisateurs du service à parfois plus d’un million en moins de 2 ans. En effet, les coûts granulaires et l’automatisation de la mise à l'échelle permettent de se concentrer sur la valeur métier et non plus les tâches annexes comme le fait de devoir prévoir le provisionnement de l’infrastructure à l’avance. A Cloud Guru est un bon exemple de startup qui a bénéficié du Serverless pour se développer.
Le deuxième type d’application qui profite du Serverless est celui des applications événementielles, au sens où l’application répond à des événements temporels, par exemple les soldes pour un site e-commerce. Les sites e-commerce voient la fréquentation de leurs sites/applications augmenter drastiquement pendant certaines périodes (soldes, fêtes de fin d’année...). L'élasticité du Serverless répond parfaitement à ces cycles de montée en charge limités dans le temps.
Le troisième type d’application adapté au Serverless est celui des applications en constante évolution. Alors effectivement, l'écrasante majorité des applications a pour objectif d’évoluer constamment, il faut donc préciser ici qu’il s’agit d'évolutions techniques fortement corrélées au design de l’application et non au code.
Voici un exemple d'application en constante évolution: une application de messagerie instantanée qui permet d’envoyer des messages textuels. Quelques itérations plus tard, il est possible d’envoyer des vidéos. Le design de l’application repose en grande partie sur des services managés de computing, puis un nouveau service managé Serverless arrive et permet de répondre au besoin de traitement des fichiers vidéos . Alors, l’application peut être repensée pour tirer parti de ce nouveau service et c’est là que le Serverless est très intéressant puisqu’il permet de refondre des parties de l’application de manière rapide et peu coûteuse.
Dans cet exemple, le choix d’un service managé pour remplacer la gestion des vidéo est judicieux, mais ce n’est pas nécessairement le cas à chaque fois qu’un service managé semble répondre à un besoin d’une application.
Cette liste d’applications n’est pas exhaustive, ce que cela démontre, c’est que certains types d’applications s'adaptent très bien au paradigme Serverless. Ce qui induit que d’autres types d’applications ne sont pas compatibles avec les principes du Serverless.
Comme cela a été dit dans la partie précédente, il y a des types d’applications propices à maximiser les profits d’une architecture Serverless et d’autres moins. En effet, certaines applications ont vocation à ne pas passer à l'échelle, voire à ne pas évoluer dans le temps. Leur design fait qu’elles peuvent répondre à une charge connue qui ne sera jamais dépassée, et leur très faible dépendance à d’autres librairies fait qu’elles n’ont pas besoin d'évoluer au cours du temps. Il est vrai que les applications qui peuvent tourner pendant des décennies sans avoir à évoluer ne sont pas légion.
Ainsi, pour la grande majorité des applications, le Serverless et ses promesses de scalabilité, de disponibilité, de coût et de performances sont de fait très attrayantes et plus qu’une promesse, une réalité. Pour ce qui est des coûts, il est important de préciser que le Serverless ne promet pas des réductions de coûts mais des coûts granulaires qui peuvent entraîner une réduction des coûts.
Quand il s’agit de s’appuyer sur le Serverless, et donc a fortiori des services managés proposés par un cloud provider, il est nécessaire d’avoir préalablement étudié les différents services, des différents cloud provider pour pouvoir faire des choix stratégiques cohérents avec la vision du produit et les compétences des équipes qui vont opérer le produit.
Concrètement, cela signifie que le choix du Serverless doit se faire en connaissance de cause et prendre en compte la capacité des équipes, sur les plans technique, organisationnel et humain, à naviguer dans le cloud à l’aide des services managés. Les contraintes sur l’adoption du Serverless ne sont donc pas tant techniques qu’ organisationnelles et humaines.
En d'autres mots, le Serverless n’est pas fait pour tout le monde.
Les services managés sont un facteur différenciant pour les cloud providers, c’est pourquoi chaque année les services sont améliorés, créés ou dépréciés. Cette course à l’innovation a pour avantage de pouvoir s’appuyer sur la capacité de recherche et développement des équipes des cloud provider et ainsi profiter d’innovations techniques pointues en réduisant les coûts liés à l’exploration et la R&D.
L’expression “Standing on the shoulders of giants” prend ici tout son sens, puisque qu’importe les moyens d’une équipe produit, cette équipe peut compter sur la puissance des services proposés par les cloud provider pour développer son produit. Mais pour pouvoir s’appuyer sur ces innovations et ne pas les subir, il faut avoir préparé les équipes à travailler dans des environnements en perpétuelle évolution.
La valeur de l’innovation est portée par les personnes plus que par la technologie. Il est donc nécessaire de pouvoir évaluer les capacités de remise en question, la flexibilité et l’appétence pour se maintenir à l’état de l’art chez les équipes techniques.
Car si les équipes ne sont pas accoutumées au fait de développer et maintenir un projet dans un écosystème mouvant, alors le Serverless peut très vite devenir un poids et ses principaux avantages se voir transformés en inconvénients.
Cela rejoint le point vue dans la partie précédente, qui est de dire que le Serverless n’est pas pour tout le monde. En effet, maintenir une architecture applicative Serverless est compliqué et dans le cas d’une application qui n’évolue plus ou peu dans le temps cela peut justifier d'évincer le paradigme Serverless.
Sur ce point, le Serverless est assez insidieux de par le fait qu’être astreint à l’innovation est souvent perçu comme un avantage. En effet, un SI qui évolue en suivant les dernières innovations en termes de sécurité, de résilience et de scalabilité sera globalement plus pérenne. Le coût lié à l’évolution du système autour des sujets tels que les montées de version, la maintenabilité du code et la réutilisation de librairies n’apparaît que plus tardivement. Ce n’est que lorsqu’une migration ou une montée de version prend des itérations complètes et que la roadmap produit en est impactée que la vitesse d’évolution du Serverless est perçue comme un inconvénient. Cela ne veut pas dire pour autant qu’il est inévitable de subir l’innovation plutôt que d’en profiter.
Le Serverless a beau être un paradigme récent d’architecture d’application dans le cloud, il ne dispense pas de continuer à mettre en place les bonnes pratiques qui ont fait leurs preuves dans l’IT au cours des dernières décennies. Les principes comme clean code, clean archi, avoir une stratégie de versionning sont applicables et le Serverless implique d’en tirer parti au maximum.
Dans la réalité, le Serverless masque une grande partie de la complexité sous-jacente et permet d'accélérer à tel point le passage du développement à la mise en production que parfois cela se fait au détriment de la mise en place de l’outillage nécessaire à l’industrialisation.
C’est précisément ce qui fait la différence entre un POC ou MVP et un produit en production. Les POCs et les MVPs démontrent la capacité technique à répondre à un besoin, mais ne sont pas destinés à se retrouver en production sans passer par l’étape de l’industrialisation. L’industrialisation est essentielle pour permettre de suivre, opérer et maintenir un produit en production, et dans le cas du Serverless de pouvoir profiter des innovations sereinement.
L’industrialisation du Serverless n’est pas triviale et doit être considérée et mise en place très tôt dans le développement d’un projet ou d’un produit. Pour mieux cerner ce que cela implique, voici quelques bonnes pratiques d’industrialisation pour un projet utilisant les Function as a service (FaaS).
1/ exemple de déploiement sans industrialisation
2/ exemple de déploiement industrialisé
Sur les illustrations ci-dessus, le coût supplémentaire que demande l’industrialisation est visible mais permet de gagner en contrôle ainsi qu’en stabilité sur les déploiements ultérieurs. De plus, les éventuelles refontes de code n’en seront que plus aisées.
La stratégie de collecte des logs et des traces doit être définie et mise en place avec les outils du cloud provider ou des outils spécifiques. Les procédés de packaging et de déploiement doivent être décorrélés du code métier et dans la mesure du possible abstrait du cloud provider. En lisant ces recommandations, il est naturel de se dire que c’est superflu de mettre tous ces outils en place à un stade précoce du projet.
C’est là que se situe le plus grand piège du Serverless. Car le Serverless permet d’accélérer la mise en service, et l'évolution d’un produit à une telle vitesse que lorsque les besoins d'industrialisation se font sentir il est trop tard. À ce moment, le temps nécessaire à la mise en place des outils et procédés d’industrialisation impacte très fortement le cycle des features releases.
Pour ce qui est du Serverless et de l’innovation incessante poussée par les évolutions ou l'apparition de nouveaux services, l’industrialisation permet de pouvoir intégrer ces nouveautés dans les roadmap. Et ainsi d’en profiter pour proposer un produit toujours plus performant pour les utilisateurs.
Le Serverless comporte de nombreux avantages qui doivent être nuancés selon les cas d’usages. Il est aussi important de prendre en compte ce que le Serverless nécessite en termes de mise en place et de fonctionnement pour les équipes qui opèrent avec ces types de services.
La réussite ou le déclin d’un produit conçu avec le paradigme Serverless dépend donc de la capacité des équipes techniques à éviter les écueils. Il n’existe pas de guide du Serverless, au sens où il n’existe pas de vérité unique sur la manière de piloter un business, mais les bonnes pratiques et un outillage bien pensé peuvent aider à tirer parti de l'écosystème Serverless pour développer un produit.
Le Serverless est un paradigme récent et même s’il peut lui être reproché un manque de standardisation, son adoption est de plus en plus courante dans le paysage des SI. Le Serverless n’en reste pas moins un outil, et comme tous les outils, il n’est performant que lorsqu'il est utilisé correctement et dans le bon contexte.