Serverless : comparaison des offres d’AWS, Google Cloud et Microsoft Azure

Langages supportés

Comme les bases du serverless consistent à  exécuter une seule fonction de code, les fournisseurs doivent supporter le bon langage dans sa bonne version en fonction des besoins. Vous ne pouvez par exemple pas utiliser un interpréteur Java pour exécuter Go. Si vous avez besoin de NodeJS 11 mais que votre environnement utilise NodeJS 6, des problèmes peuvent survenir. Il convient donc de choisir un fournisseur qui supporte le langage qui vous corresponde.

Azure Functions supporte une grande variété de langages prêts à l'emploi et a été le premier à prendre en charge le C #, en natif. Il supporte également Node.js, Java et Python. Il existe une version ancienne d'Azure Functions, qui supporte plusieurs nouveaux langages de façon expérimentale, mais il n’est pas conseillé de les utiliser en production.

Sur cet aspect, Google Cloud Functions est la plateforme la plus limitée. Le service ne supporte que Node.js, Python et Go. D’une façon générale, Google Cloud Functions tarde à prendre en charge les langages standards. Il ne supporte pas par exemple NodeJS 10, comme le font Azure Functions et AWS Lambda.

De son côté, AWS Lambda prend en charge de manière native NodeJS, Python, Java, Ruby, C #, Go et PowerShell. De plus, AWS offre plus de flexibilité pour ajouter des environnements d'exécution personnalisés. Les développeurs peuvent aujourd’hui importer leurs propres runtimes, ce qui permet de supporter presque toutes les langages. Tout comme avec les images Amazon Machine Images (AMI) for EC2, les runtimes personnalisées de Lambda peuvent être intégrés via les Lambda Layers. Cela permet aux communautés open source d’apporter leur propre support de certains langages. De cette façon, on peut utiliser NodeJS 11, C ++ ou même Bash sur Lambda.

Ces Lambda Layers peuvent aussi être utilisées pour d'autres packages, créés de manière native pour les fonctions Lambda. Cela comprend des compilations binaires telles que FFmpeg, SQLite ou Puppeteer. IO Pipe est un exemple d’utilisation plutôt créative de ces Layers. Cela permet de déboguer et de monitorer les fonctions serverless. Les utilisateurs peuvent donc monitorer leur fonction grâce à l'inclusion d'une Lambda Layer ou d'un fichier de configuration AWS Serverless Application Model.

Les options d'intégration

Sans intégrations, une plateforme serverless n'est pas différente d'un serveur traditionnel. Ces fonctions doivent être intégrées aux systèmes de gestion des événements, qui la déclenche lorsque quelque chose se produit. Par exemple, le type d'événement le plus élémentaire est un événement http. Celui-ci se déclenche lorsqu'un utilisateur visite une URL spécifique.

Dans Azure Functions, ces intégrations sont appelées biddings et triggers. Ils sont intégrés au code de la fonction, dans un fichier function.json. On peut en ajouter en mettant à jour le fichier et en re-téléchargeant la fonction. Azure supporte nombre d'événements, comme par exemple toutes les modifications apportées dans ses bases de données cloud, ainsi qu'un système semblable à celui de cron appelé timer trigger. Azure supporte également les biddings d'entrée et de sortie, ce qui facilite l'exécution de tâches sans avoir à répéter le code – comme l'envoi de messages via Twilio ou d’emails via SendGrid.

Dans Google Cloud Functions, les fonctions sont invoquées avec le célèbre framework Firebase ou à partir d'appels HTTP directs. Les développeurs peuvent aussi appeler des fonctions à partir de leur système Pub / Sub, de leur service de stockage dans le cloud ou des logs de Stackdriver. Cloud Functions ne peut servir que dans un cas d'utilisation spécifique - chaque fonction ne supporte qu'un seul type d'appel à la fois. Pour cette raison, si on veut utiliser Google Cloud Functions à plusieurs fins, il faut penser à l'intégration de topic Pub / Sub et la déclencher à chaque exécution de la fonction.

Contrairement à ses concurrents, AWS Lambda peut ajouter plusieurs sources d'événements à une même fonction. On peut donc découpler le processus de développement des sources d'intégration et ajouter de nouvelles sources d'événements après avoir déjà déployé une fonction.

Prenons l’exemple d’une fonction appelée indexRecordToAlgolia qui prend un élément dans DynamoDB et l’indexe dans la plateforme de recherche Algolia. Cette fonction écoute les flux DynamoDB lorsque de nouveaux éléments sont écrits ou mis à jour, puis les convertit au format approprié avant de les insérer dans Algolia. On peut même configurer les fonctions afin que, lorsque de nouveaux éléments sont ajoutés à DynamoDB, une fonction Lambda puisse être avertie et ajoute des éléments de manière dynamique.
De cette façon, les actions sont exécutées séparément et il n’est pas nécessaire de modifier le code ni de télécharger à nouveau la fonction. C'est un excellent moyen de dissocier le système qui compile les enregistrements, d'un autre qui indexe ces enregistrements dans un environnement de recherche.

Lambda s’intègre également à d’autres services que DynamoDB. On peut citer Kinesis, API Gateway et Amazon Simple Queue Service. Cela permet par exemple aux développeurs d’écrire moins de code bootstrapping et d’accéder directement à la logique métier. Par exemple, via API Gateway, on peut déclencher des fonctions Lambda non seulement via des points de terminaison HTTP, mais également via des points de terminaison WebSocket. API Gateway gère toutes les translations complexes et appelle des fonctions Lambda qui n'ont pas besoin de connaître les détails de l’implémentation.

La difficile comparaison des coûts

Les plateformes Serverless sont réputées pour être bon marché car elles ne facturent que les exécutions réelles de code. Le coût du stockage de code est également faible. Toutefois, il existe des variations dans les modèles de tarification.

Azure Functions a ainsi la tarification la plus complexe. Microsoft Azure facture pour chaque exécution, ainsi que pour la quantité de mémoire utilisée et le temps nécessaire à la fonction. Par conséquent, il n’est pas nécessaire de pré-configurer la mémoire ou le processeur requis avec votre fonction. Mais on peut difficilement prédire le coût de chaque exécution. Comme Lambda, Azure Functions facture une quantité de mémoire et un temps d’exécution minimum de 128 Mo et 100 ms. Chaque invocation ne peut dépasser 10 minutes.

Google Cloud Functions est également facturée à l’exécution et au temps d'exécution. Cependant, contrairement à Azure Functions, Google Cloud Functions nécessite un provisionnement de la fonction et facture en fonction des ressources allouées, plutôt que de la mémoire réelle ou du processeur utilisé. Il existe cinq types de fonctions différentes, avec des tarifs basés sur les niveaux de processeur et de mémoire. Il est également facturé le temps de calcul à 100 ms près. La durée d'exécution maximale pour toutes les fonctions Google Cloud est de 540 secondes par invocation.

AWS Lambda ne facture pas à l’exécution, mais uniquement tous les 100 ms de temps d'exécution. Comme Google Cloud Functions, Lambda permet aux développeurs d’allouer de la mémoire, par incréments de 128 Mo, jusqu’à un maximum de 3008 Mo. Comme Google et Azure, Lambda adapte l'utilisation du processeur à la mémoire. Cependant, AWS demande aux utilisateurs de spécifier la quantité de mémoire à allouer pour leur fonction, qui allouera ensuite le processeur pour l’utilisateur. Les fonctions Lambda peuvent s'exécuter pendant 15 minutes au maximum par invocation.