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 donc 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.
En savoir plusApplications 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 populaires sans vous soucier de la gestion de l'infrastructure.
En savoir plusConteneurs 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.
En savoir plusComment 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 dans Node.js, Python, PHP, Java et 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 matière 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 puissants services de backend s'intégrant 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 cela 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 for 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 GKE Anthos 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 for 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 for Anthos | |
---|---|---|---|---|
Artefact de déploiement | Application | Fonction | Conteneur | Conteneur |
Scaling à zéro instance | Pods1 | |||
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 minute2 | 15 minutes | 60 minutes | 15 minutes |
GPU et TPU | ||||
Connectivité VPC |
1. 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.
2. 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.