Cloud serverless : Google et Microsoft s'attaquent à Amazon
Via les offres cloud dites serverless, le développeur n'a plus à se préoccuper de la configuration et de la gestion des serveurs ou machines virtuelles. Ces offres sont également appelées "Function as a Service", ou FaaS, car le code de l'application s'exécute au déclenchement d'une "fonction" appelée par un événement (tel une requête HTTP). Le service est facturé au regard du temps d'exécution du code et des ressources consommées, à la milliseconde près.
Au vu de ce cahier des charges, tous les développements ne sont pas éligibles. Nativement conçu pour les architectures en microservices, le serverless se prête davantage aux applications de type web, backend ou IoT qui ont une composante événementielle. A contrario, les systèmes monolithiques sortent du cadre, de même pour ceux qui sollicitent en permanence des ressources cloud engendrant des surcoûts rédhibitoires. Amazon Web Services (AWS), Google (via Google Cloud Platform) et Microsoft (avec son cloud Azure) commercialisent désormais tous des services cloud orientés serverless.
| Nom | Amazon Lambda | Azure Functions | Google Cloud Functions |
|---|---|---|---|
| Année de lancement | 2014 | 2016 | 2016, en version bêta |
| Contenu de l'offre | Pionnier du serverless, AWS assoit sa domination en élargissant le concept aux bases de données, aux containers, à l'IoT. | Microsoft joue la carte de la simplicité en multipliant les scenarii d'usage. Il mise aussi sur le nombre de langages supportés. | Encore en version bêta, Cloud Functions capitalise sur l'application du serverless aux données temps réel (via la plateforme mobile Firebase et l'offre Apigee). |
| Langages supportés | Java, Python, JavaScript, Node.js, C#, Go et .Net Core 2.0. | C#, F#, JavaScript, Python, PHP, Bash, Batch, PowerShell, .Net Core 2.0 et Java. | JavaScript et Node.js. |
| Tarifs | L'offre d'entrée de gamme (gratuite) permet de réaliser un million de requêtes et 400 000 Go-secondes de temps de calcul par mois. Ensuite 0,20 dollar par million de requêtes supplémentaires et 0,00001667 dollar par Go-seconde utilisé. | L'offre d'entrée de gamme (gratuite) permet de réaliser un million d'exécutions et 400 000 Go-secondes de temps de calcul par mois. Ensuite 0,169 euro par million d'exécutions et 0,000014 euro par Go-secondes. | Coût d'appel d'une fonction : gratuit jusqu'à 2 millions d'appels puis 0,0000004 dollar par invocation. Coût de la puissance de calcul par Go-seconde : 0,0000025 dollar. |
Amazon Web Services a ouvert le marché du serverless en mode cloud avec Lambda fin 2014. En s'appuyant sur cette brique de base qu'est la fonction de calcul Lambda, le prestataire a depuis considérablement enrichi son offre. AWS a apposé le label serverless sur un grand nombre de services allant jusqu'à proposer des infrastructures 100% serverless.
AWS, le pionnier conforte son avance
Avec API Gateway, AWS a tout d'abord proposé un service managé de proxy d'APIs, qui permet de créer, gérer et monitorer des APIs (donnant accès à des données, à des applications ou à des services AWS tels que EC2). En termes de bases de données, le provider a commencé à passer sa solution NoSQL, DynamoDB, en mode serverless. En novembre dernier, il a élargi le spectre aux bases relationnelles en dévoilant Aurora Serveless, une version "sans serveur" de sa solution compatible MySQL et PostgreSQL.
En parallèle, AWS a lancé Fargate. Conçu pour Amazon ECS (Elastic Container Service) et EKS (Elastic Container Service for Kubernetes), ce service propose d'exécuter des containers sans avoir à gérer de serveurs ou clusters. Pour lancer une application via Fargate, il suffit de l'empaqueter dans une couche de containeurs, spécifier ses exigences en matière de CPU et de mémoire, puis définir la politique réseau et d'identification. Pour finir, Amazon commercialise Greengrass, un service taillé pour exécuter des fonctions Lambda au plus proche des objets connectés.
Pour accélérer l'adoption du serverless, AWS a dévoilé, en février dernier, un Serverless Application Repository (SAM) sur GitHub, via lequel ses clients peuvent partager leurs applications serverless. AWS a par ailleurs élargi le nombre de langages supportés par son offre Lambda. Après Java, Python, JavaScript, Node.js et C#, c'est au tour de Go et de .Net Core 2.0 d'être pris en charge par l'environnement. A cela vient s'ajouter une série d'outils de développement. Cloud9 fournit par exemple un environnement pour tester et déboguer des fonctions Lambda. Quant à CodeDeploy, il permet, via un système d'alias, de comparer les performances des différentes versions d'une fonction Lambda. Et X-Ray gère le débogage des applications distribuées, reposant sur une architecture de micro-services. Au final, pour Steve Houël, solution architect au sein du cabinet de conseil Ippon, la conclusion est sans appel : "AWS a deux à trois ans d'avance sur ses concurrents".
Microsoft joue la carte de la simplicité
En version stable depuis novembre 2016, Azure Functions propose une approche comparable à celle d'Amazon Lambda, y compris en matière de tarification. Le service de FaaS de Microsoft permet de déclencher des fonctions liées à des services Azure (Cosmos DB, Storage, Event Grid, Mobile Apps, Notification Hubs…) ou à des services tiers (les webhooks de GitHub, les messages SMS de Twilio). Il fournit toute une panoplie de modèles pour mettre en œuvre différents scénarii. HTTPTrigger déclenche, par exemple, l'exécution du code suite à une requête HTTP. QueueTrigger répond aux messages qui arrivent dans la file d'attente du service de stockage d'Azure tandis qu'EventHubTrigger réagit aux événements émis par Azure Event Hub depuis un site web, une application ou un objet connecté.
Azure Functions supporte les langages C#, F# et JavaScript mais aussi Python, PHP, Bash, Batch et PowerShell. Microsoft a annoncé en septembre prendre en charge .Net Core 2.0 et, le mois suivant, Java. Par le biais d'un plugin Maven, un développeur peut coder et déboguer ses fonctions Azure localement à partir des environnements de développement (IDE) Eclipse, IntelliJ ou Visual Studio Code. Dans sa dernière version (15.6), sortie début mars, Visual Studio 2017 supporte également Azure Functions.
La gestion des droits d'accès est prise en charge par Active Directory d'Azure ou le service managé d'identification OAuth. Azure Application Insights assure, lui, l'analyse et la supervision des fonctions. Enfin, Azure Stack offre la possibilité d'un hébergement mixte cloud public, privé ou hybride. "Un point différenciant", pour Luc Germain, directeur des offres cloud, devops et digital workplace au sein de l'ESN Devoteam.
Google, l'atout mobile de Firebase
Lancé discrètement par Google en version alpha en février 2016, Cloud Functions est passé un an plus tard en version bêta... et l'est toujours. Une habitude, presque une tradition chez le géant du web. Rappelons que son service de webmail, Gmail, est resté dix ans en bêta. Sur le principe du FaaS, l'offre serverless de Google permet de déclencher des fonctions en réaction à des événements enregistrés sur son cloud (Google Cloud Platform), tels que l'importation de fichiers sur Cloud Storage, un message entrant, une donnée remontée par un objet connecté sur Cloud Pub/Sub, ou encore une modification apportée à un journal dans Stackdriver Logging.
Via une requête HTTP, Cloud Functions peut répondre à des événements provenant de systèmes tiers comme GitHub, Slack ou Stripe. Les développeurs d'applications mobiles peuvent aussi utiliser Cloud Functions directement depuis Firebase, la plateforme mobile de Google Cloud Platform. Cloud Functions réagit notamment à des événements issus des données de Firebase Analytics.
Le codage des fonctions Cloud Functions est réalisé en JavaScript. L'exécution de ces dernières est prise en charge par un environnement Node.js standard. Depuis le rachat d'Apigee par Google en septembre 2016, Google Cloud Functions est équipé d'un service similaire à l'API Gateway d'Amazon pour déclarer des ressources REST et les fonctions associées. Le grand nombre d'offres d'emploi publiées autour d'Apigee illustre l'intérêt que porte Google à cette technologie. Enfin, le géant de Mountain View propose un outil (baptisé Cloud Functions Emulator) pour tester en local les fonctions serverless avant leur déploiement.