En fait, c’est un peu comme le PaaS dans l’esprit mais avec un niveau d’abstraction encore plus élevé. L’idée est de dire que vous implémentez du code qui se met à l’échelle automatiquement. Dans une optique Cloud de consommation de technologie dans un mode as-a-service, le serverless est de plus en plus associé à la notion de FaaS, pour Function-as-a-Service.
Dans une approche avec un PaaS, un cycle de vie logiciel est nécessaire pour produire, packager et déployer une application, et la motorisation du PaaS se charge de fournir ou décommissionner les ressources (CPU / Mémoire / Stockage / Réseau) ou l’instanciation de l’application, dans la limite du modèle d’élasticité et des tailles d’instance, bref ce n’est pas totalement transparent, on a toujours un peu de paramétrage d’infrastructure.
Serverless ?
Le Serverless peut s’exprimer sous la forme d’un service de calcul sans serveur qui permet d’exécuter du code à la demande sans explicitement configurer ou gérer l’infrastructure sous-jacente. Il vise donc à aller plus loin que le PaaS, en proposant de créer des services et fonctions exposées sous forme d’URL et qui peuvent être appelés depuis des applications web sous forme d’API, déclenchés par des sources d’évènements (timers, évènements ou données, pour ne citer que ces exemples). S’il permet d’aller plus loin dans le niveau d’abstraction, il ne vise pas non plus à remplacer intégralement le PaaS, mais plus à le compléter en dématérialisant l’exécution de code. Le Serverless vient consommer dans le PaaS des composants prêts à l’emploi comme des data hubs, event hubs, source de données, moteur de workflow ou de logique métier, …
De nombreuses motorisations sont opérationnelles puisqu’Amazon propose AWS Lambda, Microsoft propose Azure Functions ou encore Google propose Google Functions. On peut aussi citer qu’IBM a opensourcé son moteur serverless OpenWhisk qui se retrouve dans la fondation Apache.
Grâce au Serverless Computing, le développement gagne en productivité, et, selon la plate-forme technique sous-jacente, vous pouvez utiliser votre langage de développement préféré : C#, F#, Node.js, Python, Java ou PHP. Le Servlerless répond à un modèle de programmation évènementiel à base de déclencheur dont l’appel entraîne une exécution de code. Les services et fonctions ainsi mis en œuvre sont « sans état » et sans affinité avec l'infrastructure sous-jacente, de manière à pouvoir lancer rapidement autant de copies que nécessaire pour s'adapter au taux d'événements entrants. Il est également possible de s’appuyer sur des APIs et librairies propres que vous pouvez réutiliser pour implémenter le service.
D’un point de vue conceptuel, le Serverless permet de se rapprocher d’une approche microservices promouvant la décomposition en services autonomes, base de la capacité de mise à l’échelle du modèle Cloud.
La sécurité est également intégrée nativement au système dans une double dimension, tout d’abord les services s’exécutent dans le cadre d’un plan de souscription qui en limite l’accès en appel (isolation de l’environnement) et il est possible d’activer des fournisseurs OAuth (Facebook, Google, Twitter et Microsoft) qui apportent un contexte d’authentification à l’exécution. Au final, vous ne payez uniquement que pour le temps d’exécution du code de votre fonction dans le plan d’hébergement de consommation souscrit et l’infrastructure Cloud sous-jacente s’assure de la mise à l’échelle nécessaire. Le niveau de granularité de l'élasticité au niveau de la fonction est ainsi beaucoup plus fin qu'au niveau d'un pod, d'un conteneur ou d'une VM, par exemple.
Les cas d’utilisation sont très larges et nombreux, mais on peut notamment citer le traitement de données pour l’intégration de systèmes, le traitement de fichiers ou flux en temps réel, l’IoT : ou encore la création de microservices et d’API simples à exposer.
Retour d'expérience d'une mise en œuvre
L’approche serverless a notamment été mise en œuvre dans le cadre de la réalisation d’un POC visant à démontrer le fonctionnement du connecteur Live Objects pour Azure, dans l’objectif de pouvoir utiliser les données de capteurs LoRa – disponibles dans Live Objects – depuis le Cloud Azure. Les trames LoRa étant encodées en binaire pour économiser de la bande passante et le connecteur ayant pour vocation de gérer des devices de toutes natures (LoRa ou non), il est important d’exposer dans le Cloud des données structurées dans un format métier facilement exploitable (JSON). Afin de décoder ces données au fur et à mesure qu’elles arrivent dans le Cloud, une Azure Function a été développée. Elle prend comme déclencheur et comme entrée l’arrivée d’un message dans un Event Hub. Elle est chargée de réaliser le travail de conversion de trame, et en sortie alimente à son tour un autre Event Hub.
Cette approche présente beaucoup d’avantages puisqu’il n’y a pas eu à se soucier de nombreuses problématiques, notamment : infrastructure sous-jacente hébergeant le code, gestion de la haute disponibilité, résilience aux pannes. L’utilisation de templates pour la gestion du déclencheur (sélectionnable parmi un large choix) permet également de s’affranchir de toute la rédaction souvent fastidieuse du code relatif à la réception et à l’envoi de données (l’accès aux Event Hub). Ici le développeur se concentre uniquement sur le cœur de la fonction : le décodage de la trame. De plus, le déploiement d’un tel service est particulièrement aisé puisqu’il est entièrement intégré à Azure ARM (le modèle unifié de déploiement de ressources dans le Cloud Azure). Le service est également facilement testable puisque le portail Azure intègre nativement des fonctionnalités de monitoring des entrées/sorties, et des fonctionnalités d’injection de données de test.
Conclusion
On retiendra que le Serverless correspond à une architecture de plate-forme Cloud Native pour des traitements courts et sans états déclenchés par des événements qui passent à l’échelle de façon transparente et facturés à l’usage réel. En guise de conclusion, il parait clair que le Serverless est le prochain « gros sujet » en rupture côté Cloud avec une promesse de valeur intéressante dont quatre éléments me paraissent importants à détourer :
- Hyperscaleurs : On se rend également compte que le Serverless c’est surtout un sujet de rentabilité pour les hyperscaleurs qui leur permet de pouvoir optimiser la consommation des infrastructures de leur Data Centers.
- noOps : Le Serverless, c’est le premier pas officiel vers le noOps dans la mesure où 100% de la pile technique est managée par le fournisseur, la responsabilité de l’équipe est de se concentrer sur le code de la fonction ou du service avant tout et sur le fonctionnel qui va autour. Cela ne veut surtout pas dire la fin des ops, car on sait tous qu’un ops c’est bien plus qu’un sysadmin !
- Attention au coût, c’est nouveauLe côté tarification reste un peu une inconnue, et on doit se rassurer sur les coûts sous-jacents à ce mode de production d’application, ce qui veut dire d’être capable de le vendre. Avec un temps moyen d'exécution d'une fonction de l'ordre de quelques dizaines de ms et une facturation au déclenchement, on peut se dire qu'à comparer avec une VM ou un conteneur, on a une échelle de coût qui doit être compétitive
- N’attendons pas pour essayer : Pour des projets pour lesquels produire une offre sur la base d’un Cloud Public est une cible, il me parait intéressant dès aujourd’hui de commencer à s’intéresser à embarquer un peu de Serverless, de nombreux scenario pourraient en profiter, en complément d’une approche plus classique de production Cloud Native (Caas ou PaaS).
Pour aller plus loin
Chief Technology Officer, je dirige la stratégie technologique pour la transformation d’Orange Business en entreprise de services digitaux née du réseau. Fort de 25 ans d'expérience, je bénéficie d’un point de vue privilégié sur l’évolution des stacks techniques, des outils et des pratiques.