Sortie en 2019, Cloud Run est un service serverless spécialisé dans la mise en place de workloads de serveurs Web scalables de zéro à l’infini. L’idée principale est de rester concentré sur la valeur du code plutôt que les problématiques sous-jacentes à son hébergement. Avec Cloud Run Jobs, Google nous propose une offre qui reste la même sur le fond mais change de cible de workload en nous faisant sortir du paradigme web serveur. Il est désormais possible de faire tourner des batchs, ce qui ouvre l’audience de Cloud Run à d’autres types de profils que les seuls développeurs Web.
Sorti en 2019, Cloud Run s’est imposé comme LE service GCP représentatif d’une certaine approche du serverless. Beaucoup a été écrit sur le sujet et l’on retiendra les points suivants :
Cloud Run est précédé par AppEngine et Cloud Function dans l’ordre chronologique de sortie. Il est cependant celui qui a émergé comme le service sur lequel mise la GCP au point que la nouvelle version des Cloud Function n’est en réalité qu’une version déguisée de Cloud Run.
Cloud Run expose ses traitements à travers des instances de services versionnés.
Ce que vous déployez sont donc des services dont la logique est portée par des images Docker. Vous pouvez les faire communiquer de manière synchrone via des appels direct à leur FQDN (fourni par Google ou custom) ou de manière asynchrone en utilisant par exemple Cloud Tasks ou Google Pub/Sub.
En tant que service serverless phare de la GCP, il est important d’en faciliter l’intégration avec les autres services. Par exemple avec EventArc qui accepte des services Cloud Run en tant que cible d'événements se produisant sur votre projet GCP.
Nous restons cependant fondamentalement dans le même paradigme de request/response HTTP pour déclencher un processus, qui doit donc en adopter les codes en passant par exemple par des framework type Flask ou SpringBoot.
C’est sur le point des contraintes runtime que Cloud Run Jobs s’inscrit comme une évolution majeure de Cloud Run.
Note: Pour aller plus loin dans la compréhension de Cloud Run nous vous dirigeons vers cet excellent FAQ issu de la communauté GCP.
Cloud Run Jobs permet de s’affranchir d’une runtime orientée web server. Le Job vient remplacer le service. Il n’est plus question d’exposer un point d'entrée HTTP particulier pour traiter une requête et il y est possible de lancer le code suivant :
if __name__ == "__main__":
print("Hello World")plutôt que
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello_world():
return "Hello World!"
if __name__ == "__main__":
app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080)))Pour autant, nous gardons les mêmes promesses de scalabilité que Cloud Run Services. Cloud Run Jobs concurrencera directement des approches de lancement de scripts sur une VM, non scalable et dont l'opérationnel est à votre charge.
Les jobs seront, de la même manière que les services, packagés dans des images Docker dont la création pourra opportunément passer par l’outil BuildPack et vous soulager de l’écriture d’un Dockerfile valide.
Les besoins auxquels répond Cloud Run Jobs sont nombreux mais ce dernier ne les invente pas. Il les facilite en donnant la possibilité de les migrer dans un paradigme serverless voire Cloud Native.
Nous pouvons penser aux points suivants :
Cloud Run Jobs est un service en bêta et ne bénéficie à ce titre ni de SLA ni de SLO. On en interdira donc l’usage en environnement de production.
Pour l’instant les possibilités en termes d’appel restent limitées avec une intégration minimaliste au CLI gcloud.
Le minimum est tout de même bien là avec une intégration à Cloud Operations et une capacité acceptable à configurer ses jobs (politique de retry, parallélisme, politique de timeout, …).
Côté facturation, le modèle diffère de Cloud Run Service et vous facture la mémoire et le CPU sur le temps d’existence de l’instance portant un job plutôt que le temps d'exécution effectif de ce dernier. La facturation sera au minimum d’une minute.
Pour voir en œuvre quelques exemples concrets, Google met à disposition un dépôt Github non mentionné dans la documentation officielle de Cloud Run (jusqu’à preuve du contraire).
Cela reste basique pour le moment. Il va être intéressant de regarder du côté des patterns et bonnes pratiques qui émergeront à l’usage de Cloud Run Jobs.
Parmi les sujets d’intérêt se trouvent les points non exhaustifs suivants :
Cloud Run Jobs apporte une brique très appréciable au paradigme serverless existant. Cantonné aux workloads de serveurs web, il fallait détourner l’usage premier de Cloud Run pour sortir de ce paradigme et lancer des processus qui relèvent plus du traitement de données ou du scripting. Quel que soit le traitement envisagé, il fallait passer par une requête POST et se plier aux contraintes de Runtime imposées par Cloud Run Services.
Cloud Run Jobs modifie ces contraintes pour permettre d’exposer des jobs dont l’usage premier n’est pas de répondre à une requête mais de lancer des workloads arbitraires.
Cloud Run devient donc envisageable pour des opérations essentiellement pensées pour des VMs et qui, cette fois, deviennent possibles dans un paradigme serverless. Au-delà du classique développeur full-stack, c’est désormais des data engineer, ops et autres profils qui peuvent tirer profit de Cloud Run.
Bien que ce service ne soit qu’en bêta, c’est une perspective intéressante et une facilitation supplémentaire dans le cadre d’une migration vers le cloud, et plus précisément vers le paradigme cloud natif.
Aller plus loin: