Qu'est-ce que l'informatique sans serveur ?

L'informatique sans serveur constitue une évolution radicale dans le domaine du développement d'applications, qui permet aux développeurs de se concentrer sur l'écriture de code sans se soucier de l'infrastructure. Elle offre divers avantages par rapport à l'informatique traditionnelle, par exemple l'absence de gestion de serveurs et de provisionnement initial, l'autoscaling et une tarification basée sur les ressources utilisées. C'est une solution idéale pour des cas d'utilisation tels que les applications HTTP sans état, les applications Web et mobiles, les backends IoT, le traitement de données par lot et par flux, les chatbots, etc.

Portefeuille de plates-formes de calcul sans serveur GCP

Fonctions et événements liés à l'informatique sans serveur

Cloud Functions

Plate-forme de calcul basé sur les événements permettant de connecter et d'étendre facilement les services cloud, Google ou tiers, et de développer des applications qui évoluent de manière fulgurante.

Applications HTTP sans serveur

Environnement standard App Engine

Plate-forme d'applications sans serveur entièrement gérée pour les backends d'API et Web. Utilisez les langages de développement courants sans vous soucier de la gestion de l'infrastructure.

Conteneurs sans serveur

Cloud Run

Plate-forme de calcul sans serveur qui permet d'exécuter des conteneurs sans état pouvant être appelés via des requêtes HTTP. Cloud Run est disponible en tant que plate-forme entièrement gérée, facturée à l'utilisation, mais également au sein d'Anthos.

Comment choisir la plate-forme de calcul sans serveur qui vous convient le mieux ?

* L'environnement standard App Engine est compatible avec Node.js, Python, Java, Go et PHP.

* Cloud Functions est compatible avec Node.js, Python et Go.

Cas d'utilisation

Applications Web

L'environnement standard App Engine convient aux applications Web nécessitant des opérations minimales et s'exécutant en Node.js, Python, PHP, Java ou Go. Écrivez vos applications de manière idiomatique et standard en utilisant la bibliothèque de n'importe quel langage. Sa rapidité de déploiement et sa réactivité en termes de scaling rendent l'environnement standard App Engine particulièrement adapté en cas de pics de charge de travail.

Traitement backend asynchrone

Avec Cloud Functions, vous pouvez répondre aux événements de données dans le cloud et effectuer un traitement léger, tel que le redimensionnement d'une image importée dans Cloud Storage ou la validation des données lorsqu'une valeur est modifiée dans la base de données Firestore.

Backends mobiles

Dans le cas des backends d'API REST traditionnels pour applications mobiles, l'environnement standard App Engine est une plate-forme d'applications qui surveille, met à jour et fait évoluer l'environnement d'hébergement. Vous pouvez donc vous concentrer sur l'écriture du code de votre service de backend mobile. Firebase fournit une suite de services de backend ultra-performants, qui s'intègrent directement à votre application mobile : bases de données NoSQL en temps réel, authentification, hébergement, stockage de fichiers, et bien plus encore. Firebase s'intègre à Cloud Functions pour assurer une connexion facile à vos autres services Google Cloud Platform.

API

Si vous créez une API simple (un petit ensemble de fonctions accessibles via HTTP ou Cloud Pub/Sub), nous vous recommandons d'utiliser Cloud Functions. Il s'agit d'un environnement conçu pour les charges de travail intensives, dont le paradigme de programmation (les fonctions) aide à maintenir l'organisation du code de backend à petite échelle. Dans le cas d'une API plus complexe (telle qu'une API REST avec de nombreuses routes), nous vous recommandons d'utiliser l'environnement standard App Engine, car il peut faciliter l'organisation de vos nombreuses fonctions. Si la gestion de vos API repose sur Cloud Endpoints, nous vous recommandons d'utiliser l'environnement standard App Engine avec Python 2.7 et Java 8, car il accepte Cloud Endpoints.

Opérations périodiques

Cloud Scheduler peut envoyer des requêtes HTTP programmées pour déclencher des opérations selon un calendrier défini. Il peut également cibler spécifiquement App Engine ou les points de terminaison HTTP tels que Cloud Functions et Cloud Run.

Prototypage rapide et assemblage d'API

Pour les projets à petite échelle ou de type "hackathon" qui impliquent un prototypage rapide et/ou l'assemblage de plusieurs API et services, nous vous recommandons d'utiliser Cloud Functions. Son paradigme de programmation vous permet de développer rapidement à la fois des applications à petite échelle et/ou un "code de collage" qui assemble les API et services existants.

Exécuter des conteneurs indépendants du fournisseur

Les conteneurs Docker sont un standard dans l'industrie et peuvent s'exécuter dans n'importe quel cloud ou sur site. Cloud Run peut exécuter des conteneurs en mode requête-réponse sans serveur. Nous vous recommandons d'utiliser Cloud Run, sauf si vous avez besoin de matériel personnalisé (par exemple, des GPU) ou d'un cluster Kubernetes, auquel cas vous pouvez exécuter Cloud Run sur GKE dans votre cluster Google Kubernetes Engine.

Combiner des charges de travail sans serveur et avec état

Cloud Run pour Anthos vous permet d'exécuter ensemble vos charges de travail sans serveur et avec état en toute simplicité. Par exemple, vous pouvez déployer MongoDB à partir de Marketplace dans votre cluster Anthos GKE afin de l'utiliser comme magasin de documents pour vos charges de travail sans serveur. Anthos vous donne la liberté d'exécuter tout ce que vous souhaitez dans votre cluster Kubernetes, et Cloud Run pour Anthos vous permet de déployer en même temps des charges de travail sans serveur.

Comparaison de produits

	Environnement standard App Engine	Cloud Functions	Cloud Run	Cloud Run pour Anthos
Artefact de déploiement	Application	Fonction	Conteneur	Conteneur
Scaling à zéro instance				Pods²
Version gratuite
WebSockets
Langages	Java, Node.js, Python, Go, PHP	Node.js, Python, Go	Tous	Tous
Contrôle des accès	OAuth 2.0, CICP, Firebase Authentication, Google Sign-In, API Users	Autorisation IAM "Demandeur"	Autorisation IAM "Demandeur", CICP, Google Sign-In, Firebase Authentication	Cluster uniquement, VPC uniquement
HTTP/2 et gRPC
Domaine personnalisé
Délai avant expiration de la requête	1 minute³	9 minutes	15 minutes	15 minutes
GPU et TPU
Connectivité VPC		bêta¹	Prévue

1. La version bêta du logiciel ne propose aucun contrat de niveau de service.

2. Cloud Run sur GKE réduit le nombre de pods à zéro. En revanche, le nombre de nœuds par cluster ne peut pas être réduit à zéro, et ces nœuds sont facturés en l'absence de requêtes.

3. Scaling automatique : délai de 60 secondes pour les requêtes HTTP.

Conseils avancés et bonnes pratiques

Voici des facteurs supplémentaires que vous voudrez peut-être prendre en compte.

Architectures à autoscaling partiel

Si votre architecture contient des composants sans autoscaling ou avec serveur, ceux avec autoscaling peuvent entraîner leur surcharge. Vous pouvez utiliser un sujet Cloud Pub/Sub et définir la propriété "max_instances" dans Cloud Functions pour mettre en file d'attente les appels de composants sans autoscaling.

Utilisation gratuite + limites de facturation

De nombreux produits GCP proposent une version gratuite qui couvre une grande partie, voire la totalité, de l'utilisation des ressources pour les applications légères à faible trafic. À l'aide de Cloud Functions, vous pouvez facilement configurer des limites de facturation.

Pour en savoir plus, consultez ce tutoriel.

Requêtes simultanées

Cloud Functions est conçu pour ne gérer qu'une requête par instance, ce qui garantit que chaque requête dispose de la totalité des ressources de calcul et de mémoire qui lui sont allouées. Ce fonctionnement peut limiter la capacité de scaling rapide avec Cloud Functions, mais l'environnement standard App Engine, Cloud Run et Cloud Run pour Anthos peuvent gérer plusieurs requêtes simultanées par instance. Ces services peuvent ainsi évoluer plus rapidement en traitant plus de trafic par instance, mais toutes les requêtes d'une instance doivent partager des ressources.

Portabilité des charges de travail

Cloud Run est compatible avec l'environnement d'exécution et l'API Open Source Knative. Cette compatibilité vous permet de déplacer des charges de travail sans serveur entre Cloud Run et Cloud Run pour Anthos. Vous pouvez commencer à exécuter vos charges de travail sur Cloud Run, puis passer à Cloud Run pour Anthos si vous avez besoin de fonctionnalités Anthos spécifiques, telles que des types de machines personnalisés ou un accès à un VPC.