Quiconque a déjà été réveillé à 3 heures du matin à cause d’un serveur qui s’est détraqué comprend tout l'intérêt que suscite en ce moment le serverless. Après avoir configuré des machines pendant des heures, des jours et quelquefois des semaines, il faut ensuite les mettre à jour constamment pour corriger des bugs et réparer des failles de sécurité. Des mises à jour qui, de surcroît, apportent elles-mêmes leur lot de problèmes et d’incompatibilités diverses qui semblent ne jamais devoir s’arrêter. C’est l’une des raisons  pour laquelle les grands fournisseurs du cloud public ont adopté l’architecture serverless, littéralement « sans serveur ». C’est un excellent argument de vente, à ceci près qu’il n’est pas strictement exact. Les applications sont serverless au même titre que les restaurants nous dispensent d’avoir à cuisiner. Si ce que l’on veut manger est au menu et que l’on apprécie la façon dont on nous le sert, tout va bien. Mais si l’on veut un autre plat, accommodé différemment, autant le cuisiner soi-même.

Amazon, Google et Microsoft s’affrontent pour héberger les applications de demain, celles qui, ils l’espèrent, seront écrites pour leurs API serverless et gérées sur leurs infrastructures avec leurs couches d’automatisation. Si les plateformes font ce que l’on veut – et les nouveaux modèles sont assez généraux – elles peuvent représenter la façon la plus simple et la plus rapide pour créer une application propre à devenir la prochaine licorne multimilliardaire. Il suffit d’écrire la poignée de bits cruciale et la plateforme se charge de tous les autres détails.

Un langage de script qui relie les fonctions cloud

Les solutions serverless sont en train de devenir la colle ou le langage de script qui réunit ensemble toutes les fonctions cloud. Les outils de cartographie ou d’intelligence artificielle qui étaient jusque-là relativement indépendants sont maintenant reliés à travers des plateformes serverless basées sur des événements. Actuellement, la plupart des tâches peuvent être traitées à travers des requêtes qui passent d’un cloud à l’autre, en déclenchant au passage un flux d’événements et l’inverse. Si l’on veut recourir à l’apprentissage machine et l’utiliser pour analyser ses données, l’une des façons les plus rapides pour le faire est de créer une application serverless et de commencer à envoyer des événements dans l’espace machine learning du cloud. La promesse implicite est qu’en découpant tout en tâches plus petites, on facilite le partage de ressources dans le cloud. Auparavant, tout le monde créait frénétiquement de nouvelles instances, par exemple avec Ubuntu Server tournant sur sa propre machine virtuelle. Chacun utilisait le même OS et tout cela était dupliqué des millions de fois sur le même serveur physique qui supportait, dans ce cas, des dizaines ou plus de machines virtuelles Ubuntu.

Les opérations serverless permettent d’éviter toute cette duplication, réduisant considérablement le coût des traitements dans le cloud, en particulier pour les tâches qui s’exécutent de manière intermittente et qui n’ont jamais perturbé les machines installées dans les salles climatisées des serveurs. Mais bien sûr, l’avantage procuré a un coût caché. Si d’aventure, il fallait migrer son code vers un autre site, il faudrait probablement réécrire l’essentiel de la pile logicielle. Les API sont différentes et même s’il y a un minimum de standardisation autour de langages très utilisés comme JavaScript, elles sont assez proches d'un modèle propriétaire. Les possibilités de verrouillage sont nombreuses. Pour comprendre l’intérêt des options serverless, il est intéressant de développer quelques fonctions et d'examiner les stacks. Il n’y a pas beaucoup de code à écrire. Il s’agit davantage de cliquer sur des boutons et de compléter des formulaires web. On se souvient qu'avec XML, puis JSON, il fallait tout configurer. Maintenant, on remplit un formulaire et le cloud fait les choses pour nous. Mais il faut malgré tout penser comme un programmeur pour comprendre ce qui se passe derrière la scène et au-delà du contrôle que l’on exerce.

Exécuter du code sans serveur avec AWS Lambda

AWS Lambda prend ses quartiers dans la couche d’interprétation de commandes pour l’ensemble du cloud d’Amazon. C’est un système basique qui permet d’embarquer des fonctions répondant à des événements susceptibles d’être générés par à peu près n’importe quelle composante de la vaste infrastructure d’Amazon. Si un nouveau fichier est chargé sur S3, il peut déclencher une fonction qui va exécuter quelque chose d'intéressant en lien avec ce fichier. Si une vidéo est transcodée par Amazon Elastic Transcoder, il peut y avoir une fonction Lambda qui attend d’être déclenchée lorsque cette tâche sera terminée. Ces fonctions, en retour, peuvent déclencher d’autres opérations Lambda ou simplement prévenir un utilisateur. On peut écrire des fonctions Lambda en JavaScript (Node.js), Python, Java, C# et Go. Dans la mesure où ces langages peuvent en embarquer d’autres, il est tout à fait possible de faire tourner aussi du code Haskell, Lisp ou même C++.  (cf le récit de la compilation de code C++ vers une bibliothèque pour l’utiliser avec AWS Lambda).

Ecrire des fonctions Lambda peut souvent sembler plus complexe que ce à quoi on s’attendrait parce qu’Amazon propose tellement d’options de configuration et d’optimisation. S’il est techniquement exact que l’on peut écrire simplement quelques lignes de code et réaliser des choses intéressantes, on peut avoir l’impression de devoir allouer davantage de temps pour configurer la façon dont le code s’exécute. L’essentiel de cela se fait en remplissant des formulaires dans le navigateur plutôt que de saisir des fichiers texte. A certains moments, on dirait juste que l’on est passé de l’éditeur de texte au formulaire web, mais c’est le prix à payer pour conserver toute la flexibilité qu’Amazon apporte à l’utilisateur de Lambda. Quelques-unes des étapes complémentaires sont dues au fait qu’Amazon propose plus d’options à l’utilisateur et attend davantage de celui qui écrit une fonction pour la première fois. Après avoir écrit une fonction sur Google ou Microsoft, on peut indiquer la bonne URL dans son navigateur et la tester immédiatement. Alors qu’Amazon demande de configurer la passerelle API et d’ouvrir le bon port dans le firewall.

La page de configuration d’AWS Lambda permet de cliquer sur la source des événements qui déclenchent une fonction et sur la destination pour obtenir davantage d’événements. (Crédit : IDG)

A la fin, toutes ces sélections ajoutent une couche de manipulation qui se contente de simplifier un peu la tâche par rapport à un fichier texte. Lors de la création d’une fonction, le navigateur peut avertir que cette fonction comporte des bibliothèques externes. Il y a quelques temps, ce sont des informations que le développeur était censé connaître ou qu’il recherchait. Désormais, le cloud l’assiste en la matière. Amazon dispose d’un certain nombre d’autres options qui sont tout autant serverless que Lambda, si serverless signifie que l’on se voit relevé des corvées liées au management de serveur. Le cloud public fournit des outils élastiques tels qu’EC2 Auto Scaling et Fargate pour démarrer et arrêter les serveurs, ou encore Elastic Beanstalk qui prend le code que l’on charge dans le cloud, le déploie sur des serveurs web et s’occupe de l’équilibrage de charge et de la mise à l’échelle. A côté de tous ces outils d’automatisation, la création de l’image serveur relève bien entendu toujours de la responsabilité de l'entreprise cliente.

L’une des offres les plus utiles est AWS Step Functions, une sorte d’outil d’organigramme sans écriture de code pour créer des « state machines » afin de modéliser des workflows. Une partie du problème est que toutes les fonctions serverless sont supposées être entièrement libres de tout état (free of state). Cela fonctionne bien quand on applique des logiques métiers de base mais peut se transformer en cauchemar quand on cherche un client dans une checklist ou un diagramme. Il faut constamment aller dans la base de données locale pour recharger l’information sur le client. Step Functions assemble les fonctions Lambda comportant un état.

Google combine Cloud Functions et Firebase

Si l’objectif est de ne plus avoir à configurer les serveurs, Google Cloud fournit différents services qui apportent différents degrés de liberté, par rapport à la nécessité d’avoir un mot de passe racine ou, même, d'utiliser une ligne de commande. En commençant avec App Engine en 2008, Google a tranquillement ajouté différentes options serverless avec diverses combinaisons de messagerie interapplicative et de transparence sur les données. Ainsi, la messagerie temps réel Pub/Sub cache la file d’attente de messages de façon à ce qu’on ait simplement à écrire le code pour le producteur de données et pour le consommateur. Le service Cloud Functions offre un traitement event-driven pour de nombreuses applications et API. Quant à Firebase, il s’agit d’une base de données gonflée aux stéroïdes qui permet de mixer du code JavaScript dans une couche de stockage qui délivre les données au client.

Parmi ces outils, Firebase est le plus fascinant. Certains suggèrent que les bases de données étaient les premières applications serverless, faisant abstraction des tâches de structure de données et de stockage disque pour délivrer toute l’information à travers un port TCP/IP. Firebase porte cette abstraction à l’extrême en ajoutant aussi du code JavaScript et de la messagerie pour faire à peu près tout ce qu’on pourrait vouloir faire avec l’infrastructure côté serveur, incluant l’authentification. Techniquement, c’est juste une base de données mais c’en est une qui peut manipuler la plupart de la logique métier et de la messagerie pour votre stack. On peut vraiment s’en sortir avec un peu de client HTML, CSS, JavaScript et Firebase.

Synchronisation via Firebase

On pourrait être tenté de considérer que les couches JavaScript de Firebase sont des procédures stockées, à la manière de ce que fait Oracle avec sa Database, mais ce serait manquer de recul. Le code Firebase est écrit en JavaScript donc il s’exécutera dans une version locale de Node.js. On peut embarquer la plupart de la logique métier dans cette couche parce que le monde de Node est rempli de bibliothèques pour prendre en charge ce workflow. De surcroît, on appréciera ce code isomorphique qui s’exécute à la fois sur le client et le serveur et, maintenant, sur la base de données. Ce qui retient l’attention, c’est la couche de synchronisation construite dans Firebase. Elle synchronisera des copies des objets depuis la base de données à travers le réseau. L’astuce, c’est qu’on peut installer l’application cliente comme un autre nœud de base de données qui s’abonne à tous les changements pour les données pertinentes (et seulement pour celles-là). Si les données sont modifiées à un endroit, elles seront modifiées partout. On peut s’affranchir de tout le tracas lié à la messagerie et se concentrer sur l’écriture de l’information vers Firebase parce que ce dernier va la répliquer où elle devra se trouver.

Le service Firebase de Google fournit une console d’erreurs qui montre la chronologie des événements, bons et mauvais, au fur et à mesure de leur survenue. (IDG)

Il n’est pas nécessaire de se focaliser uniquement sur Firebase. Le service Cloud Functions, plus basique, fournit une approche plus simple pour embarquer du code personnalisé au sein du cloud de Google. Pour l’instant, Cloud Functions est principalement une option pour écrire du code Node.js qui s’exécutera sur un environnement Node pré-configuré. Alors que la Cloud Platform de Google supporte une grande variété de langages – depuis Java et C# jusqu’à G, Python et PHP – Cloud Functions est strictement limité à JavaScript et Node. Certains indices laissent supposer que d’autres langages pourraient bientôt s’y ajouter. Cloud Functions ne pénètre pas aussi profondément dans le cloud de Google qu’AWS Lambda ne le fait dans celui d’Amazon, en tout cas, pour l’instant. Lorsque notre confrère d’Infoworld a cherché à bâtir une fonction pour interagir avec Google Docs, il s’est aperçu qu’il lui faudrait probablement utiliser l’API REST et écrire le code dans Apps Script. En d’autres termes, le monde de Google Docs a sa propre API REST qui était serverless bien avant que ce buzzword commence à circuler.

Il convient de noter qu'App Engine continue à progresser en offrant un cadre solide. Au début, le service proposait seulement de faire tourner des applications Python afin de répondre aux demandes sur le site web, mais avec les années, il s’est étendu à d’autres runtimes de langages. Une fois que le code est associé à un exécutable, App Engine prend en charge le processus consistant à lancer suffisamment de nœuds pour gérer le trafic, en les augmentant ou en les réduisant au fil des requêtes utilisateurs. Il reste encore quelques obstacles qu’il convient de connaître. Avec Cloud Functions, le code doit être écrit de manière relativement stateless (« sans état ») et il doit terminer chaque requête dans un délai défini. Mais App Engine n’oublie pas tout entre chaque requête. Ce service a pris une part importante dans la révolution serverless et il reste le plus accessible à ceux qui continuent à utiliser les méthodes classiques pour construire leur propre pile en Python, PHP, Java, C# ou Go.

Microsoft couple Azure Functions à Office

Microsoft, bien sûr, travaille tout autant que les autres pour s’assurer que l’on puisse également accéder au serverless sur Azure. Le fournisseur de Redmond a créé ses propres fonctions de base pour jongler avec les événements, Azure Functions. Et il a conçu quelques outils sophistiqués qui sont encore plus accessibles à ceux qui ne sont pas rompus à la programmation. Le plus grand avantage de Microsoft réside peut-être dans ses applications Office, anciens exécutables desktop qui migrent lentement mais sûrement dans le cloud. L’un des meilleurs exemples de la documentation Azure Functions montre comment une fonction cloud peut être déclenchée lorsque quelqu’un sauvegarde une feuille de calcul sur OneDrive. Les petits elfes du cloud se mettent en œuvre et c’est une aubaine pour les départements IT qui supportent des équipes travaillant avec Excel ou d’autres logiciels Office. Ils peuvent écrire des Azure Functions pour faire pratiquement n’importe quoi.

On pense souvent que HTML et le web sont les seules interfaces au cloud mais il n’y a aucun raison pour que cela ne puisse pas se faire à travers des formats de documents comme Word ou Excel. Parmi les outils d’Azure, Logic Apps est notamment intéressant. Il permet de remplir des formulaires au lieu de s’embêter avec la sémantique et la syntaxe. Il convient toujours néanmoins de penser comme un développeur et de prendre des décisions judicieuses sur les abstractions et les données, mais on peut se convaincre que l’on remplit un formulaire au lieu d’écrire du code.

L’IDE web d’Azure permet d’écrire des fonctions Azure, de l’exécuter et de la débugger en insérant des appels de connexion. (Crédit : IDG)

De même que Step Functions d’Amazon, Logic Apps est destiné à encoder des workflows, ce qui est nettement plus complexe qu’une fonction « moyenne » (normale, habituelle, classique) en raison de la possibilité d’accéder à certains états. On peut de la même façon décrire une logique qui rattache différentes fonctions et connecteurs à la manière comme dans un organigramme, mais on ne l’énonce pas dans un langage informatique officiel. Le grand avantage de Logic Apps, ce sont les connecteurs pré-construits qui plongent dans certaines des grandes applications de Microsoft et d’éditeurs tiers. Il est effectivement possible d’aller chercher ou de pousser des données depuis et vers Logic Apps, de même qu’avec Salesforce, Twitter et Office 365. Ces connexions seront très utiles aux départements IT qui peuvent maintenant relier des outils externes en écrivant des Logic Apps de la même façon qu’ils créaient des scripts shell auparavant.

Un autre service d’Azure mérite d’être mieux connu, c’est Cosmos DB. Cette base de données est à la fois NoSQL et SQL. Microsoft a dupliqué les API pour Cassandra et MongoDB de façon à ce qu’on puisse y récupérer et en pousser des données sans avoir à réécrire son code Cassandra ou MongoDB. Si l’on veut écrire en SQL, on peut aussi le faire. Cosmos DB garde les choses telles quelles et bâtit des index pour tout pour continuer à s’exécuter rapidement. En cela, elle constitue une jonction centrale fort intéressante lorsque l’on a beaucoup de code SQL et NoSQL à faire cohabiter. Ou encore si l’on veut se laisser des portes ouvertes pour faciliter d’autres approches dans le futur.

Avantages et inconvénients comparés des offres serverless

Alors, quelle est la plateforme serverless qu’il convient de retenir ? L’écriture de fonctions basiques représente sensiblement la même chose sur les trois clouds publics, mais il y a des différences. La plus évidente porte sur les langages disponibles parce que chacun d’eux présente ses avantages après le support de Node.js et JavaScript. Il n’est pas surprenant de pouvoir écrire en C# sur Azure, mais son support de F# et de TypeScript est unique. De son côté, Amazon propose Java, C# et Python. Google se limite strictement à JavaScript pour ses fonctions de base pour l’instant, même s’il accepte bien d’autres langages dans App Engine. La comparaison entre les offres est encore plus difficile lorsqu’on en vient aux taris et aux performances offertes parce que beaucoup de choses se trouvent sous le capot. On a pu avoir l’impression de dépenser beaucoup lorsqu’on mettait en route des instances de VM facturés quelques centimes par heure. Désormais, les fournisseurs de cloud découpent leurs offres si finement que l’on peut avoir des invocations de centaines de milliers de fonctions pour moins d’un dollar. Bien sûr, cette apparente accessibilité en termes de prix déboussole la partie comptable de notre cerveau, un peu comme lorsqu’on se retrouve en vacances dans un pays dont on comprend mal la monnaie. Pour un peu, on pourrait se retrouver à lancer un million d’appels de base de données.

Lorsque l’on achetait une machine virtuelle brute sur le cloud, on pouvait estimer ce qu’on obtenait en considérant la puissance CPU et la RAM, mais dans le monde du serverless, on n’a pas vraiment d’indices sur ce qui se passe. Il est important de noter que le modèle serverless oblige quasiment à conserver des données dans son SGBD parce que l'on n'est pas vraiment autorisé à conserver des informations d'état dans son code. Il faudra donc faire confiance aux options back ends des clouds. Les fonctions devront s’exécuter sans aucun cache local ou configuration parce que d’autres versions sont toujours en train d’être créées et détruites. De façon imagée, le code glue de la database remplit votre code à la manière des plantes grimpantes de l’Upside Down dans la série Stranger Things.

Tester chaque cloud pour comparer les coûts

La seule véritable façon de comparer les coûts est de bâtir votre application sur chacune des plateformes cloud considérées, mais c’est un défi qui peut s’avérer intimidant à relever. Il est possible de déplacer certaines parties de code entre les trois clouds parce qu’ils acceptent tous les trois Node.js, mais même là, on va rencontrer des différences dont il faudra s'accommoder. Par exemple, on gère les requêtes http directement dans Microsoft et Google mais à travers la passerelle API sur AWS.

La bonne nouvelle, c’est qu’il n’est pas nécessaire d’être aussi paranoïaque que cela. De nombreuses apps basiques n’utilisent pratiquement pas de ressources et on peut fonctionner longtemps sur les couches gratuites que les trois fournisseurs proposent aux développeurs peu fortunés. A moins d’exploiter ses serveurs à pleine charge en permanence en disposant de l’air conditionné gratuit, il semble bien qu’une approche serverless permette de faire de sérieuses économies. Suffisamment pour que l’on ne cherche pas à discuter le prix du million d’appels, facturé 1,5$ ou 1$.

Il sera difficile de quitter le cloud choisi

Il y a un problème plus sérieux. Si d’aventure, on souhaite quitter l’un de ses clouds, on se retrouve coincé. Ce n’est pas comme s’il était facile de reprendre son code pour l’installer sur un serveur quelconque, comme on pourrait le faire avec un conteneur Docker dans lequel on aurait installé son code. Avec un peu de chance, on peut dupliquer la même architecture brute et les fonctions JavaScript de base, mais ensuite, il faudra réécrire un peu partout le code glue de la base de données. Les trois fournisseurs de cloud ont leurs propres couches de stockage de données propriétaires. On ne sait pas non plus vraiment ce qui peut se passer si les choses tournent mal. Si l’on gère ses propres serveurs, on ne peut s’en prendre qu’à soi-même si quelque chose se détraque. Mais qu’en est-il dans le cloud ? L’une des pages Google comporte ce message d’avertissement : « C’est une version bêta de Google Cloud Functions. Cette API peut être changée d’une façon qui rende impossible la compatibilité ascendante et elle ne fait pas l’objet d’un SLA ni d’une politique de dépréciation ».

Les termes du service d’Amazon se sont améliorés par rapport à ce qu'ils étaient lorsque le fournisseur a lancé son offre serverless, mais ils comportent toujours des avertissements à garder en tête comme « Nous pouvons supprimer, dans un délai de 30 jours après notification, tout contenu chargé sur AWS Lambda s'il n'a pas été exécuté pendant plus de trois mois ». Il faut donc s'assurer de faire tourner son code si on veut le garder. Des avertissements de cette nature sont assurément corrects, mais cela montre bien que l'on est entouré de contrôles. Microsoft propose de son côté un SLA pour les services Azure en promettant une compensation financière à travers des crédits de services en cas d'indisponibilité. Est-ce que cela s'applique à vos fonctions serverless lorsqu'elles tombent ? Peut-être, aussi longtemps que les services utilisés ne sont pas en version bêta. Cela vaut la peine de se pencher sur ces détails si l'on veut construire une application critique pour une entreprise.

Ce sont les API et autres services qui imposeront le choix

Dans la plupart des cas, la véritable comparaison à faire porte sur autres fonctionnalités et services cloud offerts par Amazon, Google et Microsoft et pas sur la couche serverless. La possibilité de déclencher Azure Functions avec des fichiers Office sur OneDrive aura un fort pouvoir d'attraction dans les entreprises qui apprécient particulièrement leurs applications Office. Firebase de Google simplifie l'utilisation de ces fonctions pour fournir des services de support tels que la messagerie et l'authentification aux applications web. Quant à Lambda d'AWS, il peut exploiter tant que de services Amazon que les possibilités semblent illimitées. Il est techniquement possible de mixer ces différentes fonctions cloud entre elles parce qu'elles parlent toutes le même langage PUT et GET des appels HTTP des API. Il n'y a pas de raison pour qu'on ne puisse pas monter rapidement une application utilisant des micro-services qui réunisse le meilleur des trois clouds.

Mais en bout de course, on risque d'augmenter la latence lorsque les paquets vont transiter entre les plateformes. Et cela entraînera de légères différences dans la structure et le parsing qui montreront qu'il est plus simple de rester uniquement dans un seul cloud, au moins pour les applications qui ont été interconnectées dans les règles de l'art. Alors, comment choisir ? Si on souhaite vraiment utiliser Google Maps, par exemple, autant utiliser Google Cloud Functions, même si on préférerait se servir de F# avec Azure Functions. Le même raisonnement vaut pour les fonctions de reconnaissance vocale d'Amazon ou pour l'API d'analyse d'image de Google ou pour l'une des dizaines d'API ou services d'apprentissage machine de l'un ou l'autre cloud. Ce ne sont pas tant les fonctions serverless qui sont importantes, c'est ce qu'elles relient ensemble qui importe vraiment.

AWS, Azure et GCP ne sont pas les seuls à proposer des solutions serverless. On trouve aussi IBM Cloud Functions, Oracle Fn et OVH Functions as a Service qui devrait arriver en 2019. Comme nous l'a précisé l'attachée de presse d'OVH : « Les travaux sur le serverless débuteront sur l'année fiscale 2019 lorsque la maturité du marché le permettra. Il est donc trop tôt pour OVH pour prendre la parole sur cette question ».