Cloud icon

Si vous suivez l’actualité IT, en particulier les nouveautés liées au Cloud
 Computing, vous n’avez pas pu rater les multiples références au nouveau buzzword: le Serverless. Que se cache-t-il réellement derrière cette appellation ? Révolution ou poudre aux yeux ?

État des lieux

Jusqu’à il y a encore peu de temps, un service fourni sur Internet se déployait de façon classique : des serveurs, des services sur ces serveurs, du code exécuté ou interprété par ces services sur ces serveurs.

Prenons l’exemple habituel d’un site programmé en PHP : lorsqu’une requête est adressée au serveur Web, ce dernier doit faire interpréter son code par un module PHP dédié. Ce peut être un module de serveur web (mod_php), ou bien un interpréteur à part entière (PHP-fpm, un serveur uniquement dédié à l’interprétation PHP). Une fois interprété, le code est renvoyé au service HTTP (Apache, Nginx, …), qui le transmet au navigateur web.

Ce fonctionnement s’applique à tout type d’hébergement, qu’il s’agisse de machines physiques ou virtuelles. C’est également le cas pour les conteneurs (comme avec docker). bien que dans ce dernier cas on isole les services le plus possible pour ne manipuler que de petites unités ou micro-services.

Mais dans tous les cas, ces services font partie de l’infrastructure du site, et tous les serveurs correspondants doivent donc être maintenus par son hébergeur, au même titre que le serveur web du site en lui-même. Ces éléments doivent nécessairement être pris en compte lors de la création ou de la migration d’un site web.

C’est là que se trouve la faiblesse de ce modèle : il se repose exclusivement sur la présence de ces serveurs. Même si leur création est automatisée, ce sont des entités qu’il faut installer, surveiller, maintenir, faire évoluer… Si, si, même vous, amateurs de docker qui imaginez que vos conteneurs sont exempts d’administration : sans suivi des composants qui sous-tendent nos images, ce sont des zombies en puissance qui peupleront vos architectures si vous n’y prenez pas gare.

Serverless : du code, juste du code

AWS logoLes sociétés piliers du Cloud public, et parmi elles Amazon, ont cependant ouvert une brèche dans l’édifice du service sur Internet. En 2014, lors de la grand-messe Re:Invent, Amazon annonce la disponibilité de Lambda, un service d’exécution de code à la demande. À son lancement, peu sont ceux qui envisagent encore l’incroyable puissance d’un tel service ; en effet, comme souvent chez AWS, le produit vise leur gigantesque client Netflix.

Ce dernier avait besoin de redimensionner un nombre important d’images de bonne qualité pour en faire des vignettes ; or, la location d’instances (machines virtuelles) pour réaliser ces tâches représentait une dépense non négligeable, fussent-elles des instances “spot”. L’utilisation de serveurs prend également du temps, ne serait-ce que pour créer et démarrer une machine… Pour pallier cela, Amazon a proposé à Netflix d’utiliser le service Lambda pour réaliser les redimensionnements.

Serverless service LambdaAlors, comment marche le service Lambda ? Il fonctionne avec deux éléments distincts :

  • La fonction Lambda : c’est un morceau de code (Javascript/node, Java ou Python). Elle est déclarée, avec un nom unique, par un administrateur du site sur l’interface du service Lambda. Reprenons notre exemple : Netflix a déclaré une fonction, que nous appellerons « redimensionnement », contenant du code permettant de transformer une image en vignette.
  • Les événements : un événement se déclenche lors du changement de l’état d’une donnée. Par exemple, sur son espace de stockage Amazon S3, toute modification d’un objet peut déclencher un événement ; c’est ce qui a été utilisé par Netflix, comme on va le voir. Ce sont des éléments qui ne peuvent être mis en place que par AWS, qui l’implémente progressivement sur leurs différents produits.

Pour pouvoir fonctionner en « serverless », reste à lier les deux éléments ! Pour cela, il suffit d’associer un événement à une fonction Lambda : à chaque fois que cet événement surviendra, le code de la fonction s’exécutera. Ainsi, Netflix a utilisé de l’espace de stockage S3, et lié l’événement à leur fonction « redimensionnement ». A chaque image ajoutée sur l’espace, l’événement se déclenche (changement d’état), la fonction est appelée, et le code s’exécute.

Et c’est la toute la force du produit : déclencher cette exécution de code selon le besoin. Bien sûr, ce service et son code sont hébergés sur des serveurs, des instances, des conteneurs, etc… mais c’est au fournisseur (dans ce cas, Amazon) de maintenir ces équipements en marche pour que le service soit toujours disponible et prêt à être utilisé. Finalement, ce n’est plus votre problème (ni celui de Netflix).

Une analogie peut être faite avec, par exemple, une laverie : vous utilisez ce service vous permettant de faire votre lessive, mais n’avez pas à vous occuper de l’installation, de la maintenance ou du remplacement des machines à laver. Si toutes les machines sont cassées, le service le sera également, mais là encore, la seule chose que vous avez à faire c’est d’attendre qu’il soit à nouveau disponible !

Pico service ?

Les bases sont posées pour se passer totalement de l’administration d’un environnement, serveur ou conteneur, et vous l’aurez compris, l’élément clé de cette nouvelle forme de service, c’est l’événement. Dans l’exemple précédent, c’est l’action de manipuler un fichier dans S3 qui déclenche une fonction Lambda, mais d’autres déclencheurs sont aujourd’hui disponibles, en particulier la fameuse API Gateway qui permet d’exposer une API de type REST et d’associer les points d’entrée (endpoints) à des fonctions Lambda. Ce service permet notamment d’utiliser la technologie « serverless » pour des requêtes http.

Serverless serviceExplication : l’API Gateway permet d’exposer (de rendre disponible) des URL. En enregistrant une URL (comme celle-ci https://mon.service.d.enregistrement.com/api/get/rss) dans cette API, vous bénéficiez donc d’un point d’entrée, une URL « vide », . La deuxième étape est d’associer cette URL à une fonction Lambda : ainsi, tout appel de l’URL va entraîner l’exécution du code contenu dans la fonction. Cette fonction pourra être écrite en Javascript (node), Java ou encore Python. Vous disposez ainsi de toutes les capacités de votre langage favori, et avez donc la possibilité d’utiliser les innombrables librairies disponibles avec ce dernier. Ce sont les seuls prérequis pour créer un site dynamique mais sans serveur.

Le serverless, concrètement, ça donne quoi ?

Prenons l’exemple d’un site dynamique. Sa structure, statique, est composée de code HTML. Là où la différence se fait, c’est dans le traitement de la partie dynamique du site.

Scenario 1 : architecture classique

La partie dynamique du site est gérée, pour notre exemple, par le langage Python dans le cadre d’un site avec un ou des serveurs. La partie HTML de la page demandée est envoyée par le serveur web, tandis que la partie Python est transmise à l’interpréteur correspondant avant d’être renvoyée. On compte donc au minimum 2 services (potentiellement 2 serveurs) : un pour le serveur web, un pour l’interpréteur.

Scenario 2 : architecture serverless

Dans un premier temps, il faut bien entendu déclarer une fonction Lambda (par exemple : « RSS », permettant de récupérer et afficher un flux RSS), ainsi qu’un point d’entrée (par exemple : « URL_RSS »). En plus de cela, il suffit d’une page statique stockée sur un espace Amazon S3. Le contenu statique est toujours écrit en HTML, mais la partie dynamique est gérée par l’intermédiaire de code Javascript / jQuery. Vous pouvez déclarer qu’au chargement de la balise « bloc_page » (ou au déclenchement de tout autre événement Javascript), l’URL_RSS soit appelée. La fonction RSS sera alors appelée, et le flux RSS sera affiché dans l’espace encadré par la balise, réservé à cet effet sur votre page.

Serverless vs classic

Les possibilités sont multiples : vous pouvez par exemple déclarer, en tant que fonction Lambda, des modules entiers ! Vous serez ainsi en mesure de produire un site complexe, scalable et performant, entièrement articulé autour de services Amazon qui s’occupera seul de faire monter le service à l’échelle et garantira que les ressources ne sont démarrées que lorsque c’est nécessaire. Vous ne payez ainsi qu’à la statique à maintenir !

“Still day one”

Même si le mot « serverless » a tendance à faire le buzz, nous ne sommes encore qu’au commencement. La démocratisation de cette pratique soulève pourtant des interrogations, en particulier sur la survie de certains types d’entreprises du secteur de l’IT.

Serverless quel futurDans un monde sans serveur, qu’advient-il de l’écosystème des datacenters ? Les hébergeurs ont-ils encore une utilité ? Les constructeurs de matériaux voient-ils leurs commandes diminuer, et leurs clients se limiter à quelques fournisseurs de services ? Le conseil devient-il le fer de lance de l’industrie IT ? En tous cas, les développeurs indépendants devraient être plus sollicités que jamais : en l’absence de sites « monolithiques », ils pourraient se substituer aux agences de développement pour maintenir, ponctuellement et au cas par cas, ces fonctions « décorrélées » les unes des autres.

Plusieurs précurseurs se sont cependant déjà lancé dans la brèche depuis quelques mois. Parmi les solutions les plus en vogue, on peut citer le très sobrement appelé serverless.com, Zappa ou encore chalice, trois projets Open Source ayant pour objectif de simplifier l’intégration de services serverless.

Comme l’exposait clairement le Dr. Werner Vogels, CTO d’Amazon, cette révolution ne fait que commencer, et l’ingéniosité des développeurs nous réserve sans aucun doute des surprises inattendues dans un futur… très proche.

Par Emile Heitor & Lucie Saunois –

Emile Heitor
Après avoir été CTO de NBS System, Émile conseille désormais nos clients sur leurs projets les plus complexes, notamment sur le Cloud public AWS. Expert reconnu dans le milieu informatique, toujours à la pointe des nouvelles technologies, il sait comprendre et faire comprendre les enjeux et les évolutions du marché IT.