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 œuvre 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 œuvre 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 œuvre 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. ❍
(1) Lire aussi à ce sujet la Rencontre, parue dans le n°165 de L’Informaticien (p. 20) avec Julien Lepine, patron européen des architectes d’Amazon Web Services.
« Avant tout, bien choisir son cas d’usage » Steve Houel, architecte solution chez Ippon Technologies
« Le Serverless peut être mis à profit dans de très nombreux cas, notamment pour faire de l’analyse de données, des traitements de type Big Data, ou même pour porter des applications web. Dans chaque cas d’usage, le Serverless présente des atouts et des inconvénients. Si on prend une architecture type AWS, il est difficile de faire une application web en Serverless, notamment du fait de la latence liée au « cold start ». Même si une fonction est totalement scalable, cette latence au premier démarrage va potentiellement nuire à l’expérience utilisateur. » « La maturité de cet écosystème, même si AWS a trois ans d’avance sur ses concurrents, tous les outils open source sont encore assez peu matures et les use case rares pour traiter des use case professionnels. AWS a sorti un langage de templetisation d’infrastructure, le langage SAM (Serverless Application Model), c’est très prometteur, mais on si on veut déployer plus de 40 fonctions Lambda, ce qui reste relativement peu, on ne peut pas, il faut revenir à CloudFormation sur AWS. La technologie est véritablement très prometteuse et imbattable sur certains cas d’usage bien déterminés. »
« Avec le Serverless, je suis autonome dans la mise en place de mes architectures » Virginie Mathivet, ingénieur innovation. chargée de R & D chez TeamWork
« Je travaille sur des sujets en IA et en IoT, pour des clients ou dans la recherche, et dans ce cadre, j’ai besoin de mettre en place et de tester rapidement des algorithmes. Avec l’architecture Serverless, je n’ai pas à me soucier de mettre en place des serveurs, d’installer des outils ou d’avoir à solliciter les Ops. Je peux rester autonome, monter l’architecture dont j’ai besoin sur AWS en quelques clics, tout en profitant de l’intégration native des volets scalabilité, sécurité, etc. C’est un énorme gain de temps pour moi. Le Serverless me permet de travailler sans avoir à gérer le moindre serveur, ce n’est pas qu’une promesse. » « L’autre atout, c’est le prix car les ressources ne sont actives que lorsque l’on s’en sert, avec une facturation à l’usage (100 ms pour AWS Lambda par exemple. Lorsque, comme moi, on fait de l’IoT en Serverless, on paie au moment où l’on reçoit et traite le message, mais rien entre deux messages. Il y a cependant un inconvénient financier pour les applications fortement sollicitées (appels d’AWS Lambda en permanence), qui peuvent revenir plus chères qu’une instance EC2 seule. En revanche, les autres avantages sont eux toujours là : la scalabilité – notamment lorsqu’on travaille à très haute échelle et qu’il faut faire face à des pics de production très élevés –, la disponibilité, quelle que soit la charge ou encore la sécurité. »
« Le Serverless tend vers le NoOps » Adrien Blind, évangéliste technologique dans une grande banque française, Docker Captain.
« Le Serverless – et plus précisément le FaaS – va plus loin que le PaaS, qui apportait déjà un niveau d’abstraction sur l’infrastructure. Le FaaS va plus loin en termes de granularité, on passe de l’échelle du microservice à celui de la fonction et, surtout, les développeurs n’ont plus à gérer la scalabilité et l’opérabilité de l’infrastructure. On tend vers le NoOps, même s’il reste encore l’aspect métrologie et supervision du code métier déployé sur le FaaS. » « Le modèle Serverless apporte des bénéfices réels, mais il apporte son lot de contraintes. Il faut faire entrer son code dans le paradigme des plates-formes FaaS. Celui-ci doit respecter un certain nombre de contraintes et les applications qui nécessitent beaucoup d’informations de contexte vont avoir du mal à se plier à ces contraintes. Le code Stateless s’accommode bien du FaaS, mais en règle générale, les applications doivent avoir été pensées pour être déployées dans ces environnements Serverless. »