En quelques années, le Serverless – ou informatique sans serveur – est devenu une nouvelle corde à l’arc des architectes logiciels et développeurs afin de créer des applications. La technologie est mature et l’offre de services Cloud est au rendez-vous. Encore faut-il tenir compte des limites de l’approche.
FaunaDB, l’archétype d’une base de données taillée pour le Serverless, avec une API GraphQL, des transactions 100% ACID et un pricing à géométrie variable qui fluctue en fonction de l’utilisation de la base.
Si le concept de Serverless computing n’est pas totalement nouveau, puisque la start-up américaine PiCloud a lancé un premier service de ce type dès 2010, c’est bien évidemment avec la commercialisation de Lambda par AWS que le marché a réellement commencé à décoller. Depuis, l’Américain a été rejoint par Microsoft avec Azure Serverless, Google, Oracle, Alibaba, etc. Tout fournisseur de Cloud se doit d’avoir une offre Serverless à son catalogue et les analystes estiment que la technologie va cartonner dans les prochaines années. Markets&Markets annonce un gâteau de plus de 21 milliards de dollars à se partager par les acteurs du Cloud dès 2025… pas mal pour des services facturés quelques dizaines de cents le million d’appels!
Toutes les offres Serverless ne sont pas égales : attention au vendor lock-in
Tous les fournisseurs de Cloud publics majeurs ont désormais des offres FaaS (Function as a Service) à leur catalogue mais avec des différences marquées quant aux langages supportés, aux frameworks proposés et surtout aux briques d’infrastructures complémentaires. L’entreprise qui veut se lancer doit choisir son camp et s’y tenir car, à la différence d’un conteneur, il ne faut pas espérer migrer instantanément une fonction d’un fournisseur à un autre explique Thomas Ruiz, chef d’équipe de développement Javascript/Typescript et architecte cloud de Neoxia : « Il est relativement facile de migrer une fonction Serverless d’un fournisseur cloud à un autre, mais cela demande un travail d’adaptation. On ne peut migrer instantanément des fonctions d’un Cloud à un autre. Si on veut créer une application qui soit déployable sur s’importe quel Cloud, Kubernetes reste clairement la solution la plus indiquée.» En outre, il est techniquement possible de mettre en place une infrastructure Serverless en on-premise via des frameworks opensource comme OpenFaas, Kubeless, Knative, Fission et OpenWhisk ou Fn Project qui viennent se placer au-dessus d’une infrastructure Kubernetes on-premise. L’objectif est de limiter le vendor lock-in, mais s’embarquer dans cette voie semble être contre nature ; l’essence même du Serverless est de s’affranchir de toute problématique serveur. « Vouloir déployer une architecture Serverless en on-premise, c’est un non-sens pour moi », explique Jean-Pierre Chamarande, fondateur de Skale-5, société de services spécialisée en DevOps. « Le Serverless est avant tout une solution portée par les fournisseurs de Cloud public et je ne vois pas de cas d’usage où une telle infrastructure serait pertinente.»
L’architecture de référence préconisée par Microsoft afin de traiter les messages envoyés par un objet connecté. La fonction Serverless Azure traite les messages afin de les insérer en base de données.
Que peut-on vraiment faire en Serverless ?
De plus en plus d’entreprises vont donc vers le Serverless Cloud, de Air France, qui a intégré des fonctions Lambda dans son application de maintenance prédictive, jusqu’à Euler Hermes, qui a fait le choix de transformer son infrastructure legacy en une architecture Serverless sur AWS. « Rien que chez Ippon Technologies, nous accompagnons au moins une vingtaine de clients sur des architectures Serverless critiques dans la banque, l’assurance ou l’énergie. La demande est croissante à mesure que le catalogue de fonctions se développe », souligne Fabien Roussel. Les entreprises prennent le train Serverless mais le degré d’utilisation de la technologie est très variable d’un projet à un autre. Certains font du Serverless un avantage compétitif et cherchent à exploiter au maximum la technologie. Thomas Ruiz souligne : « Nous avons travaillé sur un projet de portail pour Pernod Ricard entièrement écrit en Serverless. C’est une solution technique qui fonctionne très bien, qui ne coûte pas cher et qui ne pose aucun problème d’infrastructure.» D’autres entreprises ne distillent le Serverless qu’à faible dose, pour développer une API ou une fonction annexe à une application bien plus large, comme l’explique JeanPierre Chamarande : « Le Serverless présente le plus d’intérêt lorsqu’il s’agit de réaliser rapidement un développement pour faire un calcul, réaliser un petit traitement en parallèle à une application ou un poc. La vraie utilité du Serverless c’est sa rapidité de mise en œuvre, vouloir développer une application d’e-commerce ou même un ERP sur du Serverless n’a pas vraiment de sens aujourd’hui.»Qui dit Serverless ne dit pas forcément NoOps
Ce spécialiste de l’infogérance et de DevOps souligne les enjeux du Serverless en termes d’exploitation, mais aussi de gestion financière de l’infrastructure, les Finops : « Le Serverless est clairement en train de modifier le métier des Ops et ne signifie pas la fin des Ops, le NoOps. Pour prendre un exemple, nous avons des clients qui exécutent toute une chaîne de traitements sur les données à partir d’un fichier. Celles-ci doivent passer plusieurs étapes avant de finir dans une base de données, des traitements Serverless successifs développés généralement en Python. Pour nous, les Ops, mettre en place le type de chaînes susceptibles de fonctionner en 24/7 nécessite un travail préparatoire sur la sécurité. Il faut s’assurer que la donnée ne va pas être exposée et c’est le travail d’Ops. De même, le Serverless implique une ingénierie sur la supervision qui est propre au métier de l’Ops.» Enfin, Jean-Pierre Chamarande souligne que le Serverless présente une vraie problématique FinOps, un service Serverless dont le nombre d’appels grimpe de manière exponentielle et c’est la facture cloud qui s’envole. Les plates-formes FaaS délivrent aujourd’hui toutes les données requises par les Ops pour effectuer un suivi de la production, ainsi que les données de facturation. Les solutions FinOps permettent de définir des seuils de dépenses au-delà desquels une alerte est générée et il est possible de tagguer les ressources afin de les regrouper et délivrer des dashboards spécifiques à tel ou tel projet.Quel avenir pour le Serverless ?
Avec la maturité des offres Serverless, on peut s’attendre à voir certaines applications développées essentiellement en Serverless, mais l’architecture applicative la plus courante sera certainement mixte, avec des services classiques délivrés par des conteneurs logiciels complétés par des fonctions Serverless. Chaque chef de projet devra fixer le curseur entre ces deux modes de déploiements en fonction de ses contraintes techniques et en fonction des priorités de son entreprise en termes de mode de déploiement. Fabien Roussel, chez Ippon Technologies, espère voir les offres évoluer vers plus d’abstraction et moins de vendor lock-in, et l’apparition de standards qui permettrait de migrer facilement d’un fournisseur cloud à un autre. Porté par le W3C (World Wide Web Consortium), WebAssembly apporte un élément de réponse en offrant la possibilité de compiler des programmes écrits en différents langages puis d’exécuter les binaires sur AWS Lambda, Google Function ou Azure Function. En outre, on assiste aujourd’hui à la constitution de véritables écosystèmes de solutions compatibles Serverless. C’est notamment le cas des bases de données managées comme Amazon Aurora Serverless, Google Cloud Store ou MongoDB Atlas et encore FaunaDB, une start-up dont le président n’est autre que Bob Muglia ex-président de Snowflake, mais aussi un vétéran de la division Servers and Tools de Microsoft. FaunaDB s’adresse directement aux développeurs Serverless avec une base de données GraphQL qui offre à la fois la haute disponibilité, des temps de latence réduits et une scalabilité sans limite. Fabien Roussel précise : « Il s’agit de la première base de données inspirée du principe des transactions distribuées Calvin, ce qui lui permet de garantir des transactions ACID de manière globale (inter-regions).» Si, pour l’instant, les développeurs privilégient généralement les ressources des mêmes fournisseurs cloud qui exécutent leurs fonctions Serverless, l’architecture des applications de demain pourra être éclatée en de multiples microservices à base de conteneurs mais aussi de fonctions Serverless offertes par divers fournisseurs FaaS, en fonction des qualités de chacun.
Jean-Pierre Chamarande, fondateur et CEO de Skale-5
«Le coût de développement d’une fonction pour Lambda est en moyenne supérieur de 20% au coût de la même fonction pour une architecture classique. L’environnement d’exécution Serverless est beaucoup moins permissif et le code doit être beaucoup plus propre. Je n’ai jamais vu d’application critique ou d’applications complexes portées par du Serverless. Il s’agit bien souvent d’un morceau d’application pour effectuer un traitement bien précis. Il peut s’agir d’un traitement critique pour l’application globale, mais jamais d’applications très complexes.»
Thomas Ruiz, chef d’équipe de développement Javascript/Typescript et architecte cloud de Neoxia
«Tous les fournisseurs de services cloud publics proposent, à quelques nuances près, une même offre Serverless. Ces solutions sont beaucoup plus simples à faire monter en charge et à gérer sur la durée puisqu’il n’est plus nécessaire de maintenir une infrastructure. C’est une solution qui est très pratique pour créer des prototypes ou développer des applications peu complexes. Si on compare le Serverless aux offres Kubernetes managées, il y a un besoin pour les deux solutions. Il est bien évidemment possible de faire tourner l’intégralité d’une application sur Kubernetes, mais c’est une architecture qui demande un investissement non négligeable car c’est une plate-forme très riche. A côté de cela, le Serverless va permettre de démarrer beaucoup plus rapidement le développement d’un prototype ou d’applications peu complexes mais lorsqu’on atteint les limites de la solution, il faut passer à Kubernetes. »