Le Serverless prêt pour la production ?
Considéré comme l’architecture informatique du futur, le « Serverless » ou « calcul sans serveur » suscite beaucoup d’interrogation. Si les premiers services cloud tiennent leurs promesses, la technologie a aussi des contraintes. Et toutes les application
Dans un discours qui a constitué l’acte fondateur du mouvement Serverless, Werner Vogel, l’emblématique directeur technique d’Amazon Web Services, déclarait lors de l’AWS Summit de 2015 : « No Server is easier to manage than no server » ( 1). Derrière cette citation plutôt énigmatique, le géant américain du Cloud dévoilait son offre Serverless, AWS Lambda. Si le principe de base du Serverless avait déjà été défini près d’une dizaine d’années plus tôt, avec cette offre, Amazon Web Services était le premier gros acteur du Cloud à lancer une offre commerciale de ce type à grande échelle.
Du FaaS et du BaaS
Il est maintenant admis que le Serverless sera l’architecture informatique qui succédera à la conteneurisation. Le principe de base du serverless est d’une simplicité biblique : le développeur charge sa fonction à exécuter sur le service cloud, à charge à l’opérateur d’assurer son exécution sans se soucier du nombre d’appels simultanés. « Les équipes DevOps peuvent se concentrer sur la partie qui a le plus de valeur ajoutée pour l’utilisateur final, c’est- à- dire le code » , résume Laurent Grangeau, Cloud Solution Architect chez Sogeti. « Toute la plomberie d’hébergement, de scalabilité et de résilience est gérée par le Cloud provider, et non plus par une équipe dédiée dans des datacenters en propre. » Ce volet exécution de code dans le Cloud est baptisée FaaS pour « Function as a Service » , mais le Serverless inclut aussi le volet BaaS pour Backend as a Service. Il s’agit d’une série de services qui vont pouvoir être consommés par les applications Serverless. On classe les bases de données parmi ces BaaS, mais aussi les services de gestion d’identité, des buses de messages, des traitements de type ETL ou encore des capacités de Webhook pour déclencher des fonctions selon les événements HTTP, etc. Outre une simplification d’architecture, le Serverless présente un argument clé, son modèle tarifaire : « L’autre atout du Serverless, c’est la consommation en pay- percall » , explique Laurent Grangeau. « Lorsqu’un environnement est provisionné et qu’aucun appel n’est fait sur cet environnement, il n’y a aucun cout supplémentaire, contrairement à une approche IaaS, ou l’environnement est facturé en fonction de son uptime. De ce fait, les coûts peuvent être drastiquement réduits, passant de plusieurs centaines d’euros par mois, à quelques centimes dans certains cas. » Ce nouveau modèle économique est encore plus précis que la location d’une instance de serveur à l’heure ou même à la minute et, comme le souligne Virginie Mathivet de TeamWork, une facturation par incréments de 100 millisecondes est particulièrement adaptée à l’IoT où il faut lancer un traitement à l’arrivée épisodique d’événements générés par les objets connectés. Toutefois, dès que ces événements surviennent en continu, les courbes de coûts peuvent se croiser entre la location d’une instance IaaS en continu et le Serverless.
Le Serverless bien adapté aux spécificités de l’IoT
L’IoT, où l’on doit lancer une fonction au moment de l’arrivée d’une donnée, ou encore le Big Data, se prête bien à ce nouveau mode de consommation de puissance informatique dans le Cloud, il est aussi possible de créer des applications Web sur une architecture Serverless, placer une fonction FaaS derrière une API, lancer une action de manière planifiée via des commandes cron, réalisé un traitement à l’appel d’une url dans une page, lancer une fonction lorsqu’on copie un fichier dans le Cloud ou même lorsqu’on sauve un fichier Excel sur Onedrive.
IBM a même fait la démonstration d’une chaîne de traitement d’analyse d’images vidéo d’un drone en temps réel. Dans cette application baptisée Skylink, une fonction serverless étant chargée d’envoyer les images à analyser à IBM Watson puis de récupérer les résultats, des tags décrivant les objets identifiés dans l’image afin de les afficher en marge du flux vidéo. Si les applications temps réel ou interagissant avec les utilisateurs sont théoriquement possibles en s’appuyant sur une infrastructure Serverless, le support des langages de programmation par les opérateurs de services FaaS est un élément important dans le choix d’une plate- forme. Ce choix est important notamment en termes de performances. En effet, Le Serverless présente la caractéristique d’avoir un temps de latence important lors du premier appel d’une fonction, c’est le phénomène du « Cold Start » . C’est globalement le temps mis par l’infrastructure de l’opérateur cloud de monter en mémoire le conteneur qui contient la fonction appelée, sachant que le conteneur va être effacé au bout de quelques minutes d’inactivité. Pour des traitements IoT ou des batchs destinés à alimenter un Data Lake, ce délai d’exécution n’est pas nécessairement un handicap, en revanche, s’il s’agit de supporter des API RESTful qui doivent être très réactives ou des applications web destinées à des
utilisateurs « humains » , ce phénomène peut être très handicapant. Steve Houel, architecte solution chez Ippon Technologies souligne que « Sur un projet que nous menons actuellement pour un gros industriel, nous n’avons aucun soucis au niveau architecture. Mais si un utilisateur fait un appel à une fonction très peu utilisée, il peut avoir un délai de 15 à 20 secondes avant d’avoir une réponse. » L’expert souligne que le choix du langage influe très directement sur ce délai d’exécution. « AWS offre cinq langages pour son service Lambda et chacun de ces langages à un temps de Cold Start. Mettre en oeuvre le Java et sa JVM implique un temps de chargement qui peut atteindre la minute ! » Un tel temps d’attente peut paraître incompréhensible pour les utilisateurs d’une nouvelle application, surtout si on leur explique que celle- ci met en oeuvre l’architecture la plus novatrice du moment… Pour masquer ce phénomène, les développeurs utilisent des subterfuges et font des appels réguliers à chaque fonction « à blanc » via un fichier « cron » afin que celles- ci restent en permanence en mémoire et
ainsi épargner les utilisateurs de « Cold Start » pendant leur journée de travail.
Du Serverless en on- premise, c’est possible !
L’approche Serverless semble totalement liée à la notion de Cloud public et pourtant des solutions permettent de déployer une architecture Serverless sur des serveurs on- premise et donc sur un Cloud privé. Outre Fn Project et Apache OpenWhisk, les solutions mises en oeuvre par Oracle et IBM, il existe plusieurs frameworks alternatifs. Parmi eux, Kubeless, fission ou OpenFaaS basés sur Kubernetes, ou encore Dispatch, un framework Serverless Open Source qui a été annoncé lors de VMworld 2017. Édité sous licence Apache 2.0, cette solution pourrait intéresser les entreprises dont le Cloud interne est motorisé par les solutions de virtualisation VMware. Enfin, pour les entreprises adeptes des technologies Microsoft, l’éditeur propose un runtime d’Azure Functions pour Windows 10, mais ont aussi été mis à la roadmap une version Linux et Mac de la plateforme Serverless de Microsoft. Ces versions sont actuellement au stade de la préversion. Pour l’heure, les experts estiment les plates- formes Serverless pas assez matures pour supporter de lourdes applications composées de plusieurs dizaines de fonctions. Néanmoins, les offres évoluent rapidement, notamment afin d’industrialiser les déploiements de grand nombre de fonctions et aller vers le Graal du NoOps, c’est- à- dire d’une architecture qui ne nécessite plus aucune opération de maintenance. Laurent Grangeau souligne que « L’un des plus gros inconvénients du Serverless aujourd’hui porte sur le test de telles architectures, que ce soit de manière unitaire, mais aussi de bout en bout. Cela oblige les développeurs à mettre l’accent encore plus sur des méthodes type TDD ( Test Driven Development), découplant le code métier, de la plomberie propre à chaque Cloud provider, afin de pouvoir tester unitairement chaque fonction, ou la bouchonner. » L’expert estime que ces inconvénients vont peu à peu s’estomper grâce à une standardisation de l’architecture serverless, standardisation initiée par la publication du « Serverless Whitepaper 1.0 » par la Cloud Native Computing Foundation. Pour Adrien Blind, l’enjeu pour le futur va être de désenclaver le Serverless. « Les applications de demain ne se limiteront pas à seulement des fonctions Serverless mais seront des hybrides entre du FaaS, des microservices plus traditionnels, des composants exécutés sur du Iaas, etc. Il faudra être capable d’orchestrer le déploiement et administrer des éléments d’infrastructures de natures différentes et être capable de le faire dans des environnements de Continuous delivery et DevOps. » Être capable de gérer de telles applications hétéroclites va être un vrai enjeu pour les années qui viennent. ❍