Cloud Run : des conteneurs sans la douleur de Kubernetes

Cloud Run est un service de conteneur à la demande similaire à Instances de conteneur Azure et AWS Fargate. Contrairement à Google Kubernetes Engine (GKE), Cloud Run est conçu pour les applications Web sans état accessibles via des requêtes ou des flux HTTP, WebSockets ou gRPC. Ainsi, Cloud Run ne fonctionnera pas pour les applications nécessitant un système de fichiers persistant.

L’environnement Cloud Run peut gérer n’importe quel code et n’importe quelle bibliothèque empaquetée dans un conteneur personnalisé. Il inclut nativement des environnements d’exécution pour Go, Java, Node.js, Python ou .NET Core. Il est particulièrement intéressant pour les développeurs utilisant ces langages de script, qui comptent parmi les langues les plus populaires utilisé pour les applications Web.

Cloud Run s’appuie sur environnement Knative open sourcequi permet aux développeurs de transférer des applications vers des systèmes sur site ou d’autres services cloud compatibles avec Knative.

Knative permet également de déployer du code Cloud Run en quelques secondes, ainsi que de travailler avec des frameworks tels que Django, Ruby on Rails, Spring et autres. Cloud Run peut arrêter toutes les instances s’il n’y a pas de demande. Cela rend le service efficace pour les applications Web sans état avec des charges de travail très variables.

Les autres fonctionnalités incluent :

• la possibilité de répartir le trafic entre les versions de l’application pour introduire progressivement des versions bêta ou test bleu/vert;
• redondance automatique avec des instances automatiquement répliquées sur plusieurs zones ; et
• prise en charge des domaines personnalisés, mappage de Cloud Run et utilisation d’un certificat TLS privé à la place du certificat fourni automatiquement lors de l’utilisation du mappage de domaine Cloud Run.

Les applications et cas d’utilisation idéaux pour Cloud Run incluent :

• des sites web dynamiques qui utilisent un framework comme Django ou Ruby on Rails ;
• services Web back-end avec API REST ;
• transformations de données événementielles telles que la conversion d’un fichier CSV en un tableau structuré pour les entrepôts de données comme BigQuery; et
• des tâches par lots planifiées pour des tâches telles que la conversion de documents, qui peuvent inclure la conversion de documents Word ou de formulaires Excel en PDF.

App Engine : le choix centré sur le code

App Engine est antérieur à Compute Engine et aux autres services d’infrastructure Google Cloud qui fournissaient un environnement de développement et d’exécution standardisé pour les applications Web. App Engine a depuis été étendu via App Engine environnement flexible pour prendre en charge les runtimes conteneurisés personnalisés. L’environnement flexible est une sorte d’hybride entre l’App Engine standard, centré sur le code, et Cloud Run et GKE basés sur des conteneurs.

Google cible App Engine pour les applications conçues comme des microservices. C’est particulièrement le cas lors de l’utilisation de l’environnement standard, car il exécute le code dans un bac à sable sécurisé et peut déployer et faire évoluer automatiquement les applications en quelques secondes. App Engine utilise des instances de conteneur pour chaque déploiement. Lors de l’utilisation de l’environnement standard, ils sont préconfigurés avec l’un des runtimes de support suivants :

• Python (les versions 2.7, 3.7, 3.8 et 3.9 sont actuellement supportées)
• Java 8 et Java 11
• js (versions 10, 12, 14 et 16)
• PHP (5.5, 7.2, 7.3 et 7.4)
• Rubis (2.5, 2.6 et 2.7)
• Aller (1.11-1.16)

Les développeurs spécifient la configuration d’exécution et de déploiement d’App Engine dans un fichier YAML. Vous pouvez déployer avec une simple commande :

déploiement de l’application gcloud

La configuration identifie également une classe d’instance qui détermine les ressources CPU et mémoire disponibles pour chaque application. Par exemple, la plus petite instance par défaut, F1, fournit un vCPU de 0,6 GHz avec 256 Mo de mémoire. La plus grande instance B8 offre un processeur équivalent à 4,8 GHz avec 2048 Mo de RAM.

Les développeurs configurent les environnements flexibles App Engine via un fichier YAML similaire, mais le fichier nécessite un environnement d’exécution fourni par l’utilisateur. Il est possible d’utiliser n’importe quelle combinaison de processeurs, de un à 80 en puissances de deux ; RAM, qui est soumise à des exigences minimales par application ; et disque, de 10 Go à 10 To.

Comme Cloud Run, les environnements standards App Engine sont facturés en fonction du nombre d’heures d’instance utilisées. Les tarifs sont fixés en fonction de la taille de l’instance. Par exemple, les instances App Engine B1 et F1 standard coûtent 0,05 $ de l’heure, tandis que les instances B8 exécutent 0,40 $ de l’heure. Tarifs Google environnements flexibles comme une combinaison d’heures vCPU, d’heures RAM Go, de taille de disque persistant et de trafic réseau sortant.

Cloud Run et App Engine ciblent tous deux les applications Web sans état (à moins d’utiliser des environnements Flex), en particulier celles développées à l’aide de l’un des environnements d’exécution standard, ou les back-ends REST avec des charges de travail très variables. Ceux-ci inclus:

• sites Web statiques et services Web dynamiques
• back-ends mobiles
• workflows de journalisation et de traitement des données

Cloud Run vs App Engine : choisissez le meilleur service pour la tâche

Les applications cloud natives sont idéalement décomposées en plusieurs composants ou microservices. Ces composants reposent sur plus qu’un simple code encapsulé dans un environnement d’exécution ou de conteneur unique. L’un des principaux avantages du cloud est l’accès à une gamme de services de gestion de données, d’analyse et d’IA sans serveur. Ainsi, qu’il utilise App Engine ou Cloud Run, le travail d’un développeur se connectera invariablement à d’autres services Google Cloud. Certains exemples seraient BigQuery, Bigtable, Pub/Sub, Cloud Storage et l’API Vision.

Les développeurs ne doivent pas considérer la sélection de Cloud Run contre App Engine pour le code personnalisé comme un choix qu’ils font une fois. Au lieu de cela, choisissez le service qui convient le mieux à un microservice ou à un sous-système d’application particulier.

Note de l’éditeur: Cet article est l’un des derniers articles que Kurt Marko, contributeur de longue date de TechTarget, a écrit pour nous avant son décès en janvier 2022. Kurt était un analyste et consultant informatique expérimenté, un rôle dans lequel il a appliqué sa connaissance large et approfondie des architectures informatiques d’entreprise. Vous pouvez explorer tous les articles qu’il a écrits pour TechTarget sur son page contributeur.