Mis à jours 1 septembre 2022 Une comparaison pas tout à fait juste entre la version alpha de Google Cloud Functions et la version mature d’AWS Lambda : voici un aperçu sur l’avenir des clouds sans serveur.
L’informatique sans serveur débarque sur Google Cloud : Bienvenue dans Google Cloud Functions
Mise à jour : La version bêta et open source de Google Cloud Functions a été lancée en mars 2017. Le tableau de comparaison a été en effet mis à jour.
La version alpha de Google Cloud Functions a été officiellement lancée en février 2016 et faisait partie de la solution Google Cloud Platform. Ce nouveau service cloud vise à soulager la plupart des problèmes de maintenance, de déploiement et d’évolutivité du serveur. Il correspond parfaitement à la révolution sans serveur lancée par AWS Lambda en 2014.
“Sans serveur” signifie que vous pouvez vous concentrer sur la logique de votre application sans vous soucier de tout ce qui concerne (ou presque) de l’infrastructure. Le développement, le déploiement et la maintenance sans complication d’une API web ne sont pas toujours prêts à être exploités, bien que les frameworks d’applications web modernes se soient considérablement améliorés au cours des 5 dernières années. L’informatique sans serveur est définitivement un changeur de jeu. L’approche guidée par l’événement, combinée à l’écosystème de cloud riche en services offert par les principaux fournisseurs de cloud AWS, Microsoft Azure et Google Cloud Platform, offre une infinité de possibilités.
Dans ce post, on va discuter des futures fonctionnalités de Google Cloud Functions et les comparer avec l’état actuel d’AWS Lambda. On va vous fournir quelques exemples de base sur la façon dont vous pourrez migrer, puis tester vos fonctions Lambda sur Google en quelques minutes. On va voir également ce que l’informatique sans serveur peut ressembler en quelques mois.
Google Cloud Functions et AWS Lambda
Tout d’abord, il faut admettre que comparer une version alpha avec un produit stable depuis deux ans n’est pas tout à fait juste. Cela dit que certaines fonctionnalités déjà offertes par Google Cloud Functions feront une différence positive substantielle, surtout du point de vue du développement.
Voici un récapitulatif rapide des principales fonctionnalités des deux produits :
Allons examiner plus soigneusement chacune de ces fonctionnalités.
Évolutivité, disponibilité et limites de ressources
Bien sûr, c’est l’objectif principal des deux services. La fonctionnalité clé promet que vous n’avez plus à vous soucier de la maintenance, des temps d’arrêt ou des goulots d’étranglement.
En ce qui concerne AWS Lambda, l’évolutivité est gérée de manière complète et transparente par le système, ce qui signifie que vous ne connaissez pas le nombre d’instances ou de machines sur lesquelles vos fonctions s’exécutent à un moment donné. Vous pouvez surveiller l’utilisation de vos fonctions Lambda à tout moment, mais votre visibilité de l’architecture sous-jacente est limitée.
À l’autre extrême, Google Cloud Functions crée explicitement un ensemble d’instances dans le cloud. De cette façon, vous pouvez toujours vérifier le nombre de machines créées et surveiller la charge de votre cluster.
En plus de la mise à l’échelle et de la surveillance, AWS Lambda a d’autres limitations. Par exemple, vous pouvez créer un nombre illimité de fonctions, mais chaque exécution ne peut pas dépasser cinq minutes (elle était beaucoup plus courte !) Et vous êtes limité à 100 exécutions parallèles par compte et par région en tant que limitation de sécurité par défaut, qui peut être augmentée à la demande. De plus, vos paquets de déploiement compressés ne peuvent pas dépasser 50 Mo (250 Mo lorsqu’ils ne sont pas compressés). Il y a quelques limites de plus sur AWS Lambda, mais elles n’affectent que des scénarios très spécifiques, donc elles ne sont pas mentionnées ici.
D’un autre côté, Google Cloud Functions ne semble pas imposer de telles limitations (encore une fois ?), malgré une limite stricte de 20 fonctions par projet. Attendons que cette limite finisse par disparaître.
Langages pris en charge et gestion des dépendances
La première version de Lambda ne supportait que JavaScript, et plus tard, elle incluait Java (en Juin 2015) et Python (en Octobre 2015). Actuellement, vous pouvez même écrire vos fonctions dans Ruby (avec JRuby), ou n’importe quelle langue non supportée en exécutant des exécutables arbitraires (c’est-à-dire en engendrant des processus fils).
Google Cloud Functions ne prend actuellement en charge que JavaScript. Bien qu’il semble n’y avoir aucune feuille de route publique, on attend à ce que Python et Java soient supportés plus tard cette année.
En ce qui concerne la gestion et le déploiement des dépendances, la seule véritable faiblesse d’AWS Lambda réside dans ses Packages de Déploiement. En pratique, vous pouvez utiliser des dépendances externes uniquement en les incluant dans votre code source compressé, mais cela représente des inconvénients sur plusieurs raisons. Tout d’abord, vous êtes contraint de compiler et d’installer ces packages externes sur le même système d’exploitation qu’AWS Lambda en interne. Après cela, chaque fois que vous avez besoin de changer quelque chose dans votre propre code, vous devez tout télécharger ensemble. Deuxièmement, ce n’est pas comme ça que fonctionne la gestion moderne des dépendances. Les développeurs Web ont maintenant l’habitude de déclarer et de modifier leurs dépendances de code plutôt que de fournir des bibliothèques compilées locales.
Bien sûr, tout le processus peut être automatisé, et un fichier de configuration ne serait-il pas plus facile et plus sûr à maintenir ? Oui. 🙂
En effet, Google Cloud Functions vous permet de définir un fichier simple package.json pour déclarer et mettre à jour vos dépendances npm. Une fois que Python est également supporté, nous pourrons simplement déployer un fichier pip requirements.txt. Allons voir ce qui se passe.
Déploiements et versionnage
Comme mentionné dans la section précédente, on n’aime pas la façon dont AWS Lambda gère les packages de déploiement et les dépendances. Cela vous oblige à redéployer un package de déploiement (potentiellement énorme) chaque fois que vous modifiez votre code ou mettez à jour une dépendance.
D’autre part, on aime la possibilité d’avoir plusieurs versions de la même fonction Lambda. Cela facilite le déploiement et le test d’une nouvelle version, même à partir de l’interface utilisateur AWS Console. La vraie astuce consiste à lier les versions aux alias afin que vous puissiez passer facilement aux nouvelles versions (ou revenir aux anciennes) en quelques clics. Lier des versions stables de vos fonctions à des étapes API Gateway telles que dev, stage, prod, etc. nécessite un peu de configuration manuelle, mais cela en vaut vraiment la peine. Il est recommandé de configurer une variable d’étape API Gateway et de l’utiliser pour appeler des alias AWS Lambda donnés.
Sur ce plan, Google Cloud Functions a choisi de ne pas réinventer ce qui existe déjà et a conçu une solution conviviale pour les développeurs qui vous permet d’obtenir des versions avec git (par exemple, une branche ou un tag donné), même si vous devez héberger votre repo sur les référentiels Cloud Source. On attend impatiemment une solution plus générale qui inclut d’autres solutions git grand public telles que GitHub, BitBucket, etc.
Invocations, événements et journalisation
AWS Lambda et Google Cloud Functions prennent tous les deux en charge l’approche guidée par l’événement. Cela signifie que vous pouvez déclencher une fonction chaque fois que quelque chose d’intéressant se produit dans l’environnement cloud. Ils prennent également en charge une approche HTTP simple.
AWS Lambda peut être appelé par presque tous les autres services AWS dont S3, SNS, SES, DynamoDB, Kinesis, Cognito, CloudWatch, etc. Vous pouvez configurer API Gateway pour appeler une fonction Lambda donnée et obtenir une interface RESTful gratuitement (ou presque), y compris l’authentification, la mise en cache, le mappage des paramètres, etc.
Google Cloud Functions ne prend actuellement en charge que les événements internes de Google Cloud Storage (par exemple, les notifications de modification d’objet) et de Google Cloud Pub/Subtopics (le bus de messages distribué globalement par Google qui est automatiquement mis à l’échelle lorsque vous en avez besoin). Les invocations HTTP sont déjà supportées nativement. Vous avez simplement besoin de déployer votre fonction avec un drapeau trigger-http. Actuellement, vous devez configurer et déployer explicitement votre solution Google Cloud Functions pour chaque différent type de déclencheur.
En ce qui concerne la journalisation, les deux services sont bien intégrés avec les services de gestion de journalisation correspondants : Amazon CloudWatch et Google Cloud Logging. CloudWatch est mieux intégré, mieux documenté et avec des graphiques faciles à configurer (en quelque sorte).
Chargement des tests et des statistiques
On a pris le temps d’effectuer des tests de chargement sur JavaScript arbitraire impliquant un calcul pur (c’est-à-dire générer des hachages de 1000 md5 pour chaque invocation). Cela nous a donné l’opportunité de jouer avec les deux différents systèmes de gestion des dépendances car on avait besoin d’inclure le module md5 npm.
On a configuré une charge linéaire incrémentielle de cinq minutes, jusqu’à environ 70 demandes par seconde. Les deux graphiques représentent le temps de réponse moyen et le nombre moyen de requêtes par seconde.
Notons que ces graphiques utilisent la même échelle pour les deux dimensions. On a également déployé et testé les deux fonctions dans la région UE-Ouest correspondante (Irlande).
Comme vous pouvez le voir, il y a une différence notable dans le temps de réponse moyen : Google Cloud Functions le maintient constamment entre 130 et 200ms, avec une augmentation étrange pendant les dernières minutes de notre test (peut-être en raison de la charge décroissante ?).
D’autre part, le temps de réponse d’AWS Lambda est beaucoup plus élevé et révèle un motif rectangulaire intéressant. Le service est mis à l’échelle en interne après que la charge a atteint 20 req/s. Quand la charge se stabilise autour de 30 req/s, il diminue (c’est-à-dire que le temps de réponse est porté à 600 ms), puis il augmente à nouveau avec une charge de +40 req/s.
Comme chaque invocation de fonction renvoie une réponse JSON relativement lourde (près de 50 Ko), on a supposé que les performances du réseau avaient un impact sur le temps de réponse obtenu, indépendamment du calcul réel. On a rapidement vérifié cette hypothèse et modifié les deux fonctions pour retourner un simple message “OK”. On a remarqué une amélioration constante dans la nouvelle fonction AWS Lambda, dont le temps de réponse a chuté entre 200 et 300 ms. Le nouveau Google Cloud Functions n’a pas été sérieusement affecté, mais son temps de réponse a chuté à seulement 100 ms.
Compte tenu de ces résultats, on peut dire que la différence de calcul est toujours pertinente, mais le réseau a probablement un plus grand impact si votre application implique des réponses HTTP lourdes. Apparemment, la mise en réseau de Google fonctionne mieux, et supposons que l’intégration HTTP native est également plus rapide que celle d’Amazon API Gateway. Bien que le réseau de Google soit génial, il lui manque encore des fonctionnalités essentielles telles que l’authentification et la mise en cache.
Compatibilité du code de fonction entre AWS et Google
Malheureusement, AWS Lambda et Google Cloud Functions ne sont pas directement compatibles entre eux. Google Cloud Functions est toujours en alpha et les choses peuvent changer, mais supposons que Google ne fera pas l’effort d’être compatible avec AWS Lambda sans aucune raison impérieuse.
Si vous avez déjà quelques fonctions Lambda, dans la plupart des cas, elles interagissent avec au moins un autre service AWS. Vos fonctions Lambda utilisent probablement certains rôles d’IAM et beaucoup de détails AWS, de sorte que vous ne migrez pas facilement vers un autre fournisseur de cloud de toute façon. Cependant, dans de nombreux autres cas, vos fonctions Lambda impliquent un calcul pur ou une logique simple d’entrée/sortie (c’est-à-dire lire depuis une file d’attente, écrire dans une base de données, traiter une image, etc.). Dans ces cas, vous seriez tenté d’essayer également vos fonctions Lambda sur Google Cloud Functions, même si ce n’est que pour évaluer le service ou réduire vos coûts. Vous pouvez demander à ce que votre compte soit ajouté à la liste blanche ici.
Qu’en est-il d’un outil de conversion automatisé ?
Heureusement, on a pris le temps de développer un outil de conversion simple qui va certainement accélérer le processus de portage de vos fonctions JavaScript Lambda. Il gère correctement le mappage des fonctionnalités d’événement/contexte et commente automatiquement les attributs et les méthodes incompatibles. Comme la plupart d’entre nous n’aiment pas vraiment les tâches de refactoring ou de portage manuel, donc on espère que cela nous sera beaucoup utile.
Par exemple, une fonction très simple comme celle-ci :
deviendrait quelque chose de très similaire à ceci :
Comme vous pouvez l’imaginer, la conversion est assez intuitive et ne devrait pas vous prendre plus de quelques minutes. Cependant, les choses commencent à devenir beaucoup plus compliquées et à prendre beaucoup de temps si vous avez une fonction très complexe (surtout si vous avez défini des fonctions utilitaires supplémentaires qui nécessitent à la fois les objets d’événement et de contexte d’origine).
Conclusions des tests alpha
Google Cloud Functions est très prometteur et nous attendons avec impatience la longue liste de fonctionnalités à venir. Toutefois, il faut exécuter des tests et surveiller les groupes de testeurs Cloud Functions fiables, qui contiennent déjà de nombreuses suggestions, améliorations et commentaires. Sinon, on espère voir beaucoup d’autres outils qui permettront le développement multiplateforme sans serveur.
