Container Serverless avec Google Cloud Run

Le 11 février dernier, j’ai eu le plaisir de participer aux Human Talks à Angers. C’était l’occasion pour moi de partager nos retours d’expériences sur nos pratiques en matière d’hébergement chez Playmoweb, et de présenter brièvement le nouveau service de Google Cloud : Cloud Run.

Pour ceux qui n’ont pas pu être présents, ou pour ceux qui veulent en savoir davantage, je vais essayer de revenir sur ces sujets ici.

6 années d’expérience

Au fil des années, Playmoweb a su bâtir sa réputation de spécialiste de l’application mobile. Ce n’est que la partie émergée de l’iceberg, celle qui sera utilisée par les utilisateurs.
Mais derrière l’application et sa simplicité d’utilisation, se cachent la complexité de l’échange et du traitement de l’information. Cette tâche est très souvent déléguée à un ou plusieurs services web (aussi appelés API) qui sont hébergés sur des serveurs ou dans le cloud.
Certains de ces services tournent depuis des années et continuent, aujourd’hui, à délivrer les informations dont ont besoin nos utilisateurs.
On va maintenant entrer dans la partie plus technique et comparer deux solutions d’hébergement aujourd’hui utilisées chez Playmoweb.

Conteneurisation, la souplesse des technos

Depuis ses tout débuts, Playmoweb a principalement choisi la technologie Docker pour déployer ses applications. La conteneurisation permet aux développeurs de choisir, avec une grande souplesse, les langages, les versions et les binaires qui seront utilisés pour développer leurs services web.
Le fichier Dockerfile, qui accompagne le code du service, permet de décrire précisément la manière dont doit être lancé le service web sur le serveur distant.
Lorsqu’une version est fixée sur notre outil de gestion de version, notre système d’intégration et déploiement continu va utiliser ce fichier Dockerfile pour construire une image Docker du service et va ensuite déployer une instance de cette image sur nos serveurs.
Instance qui sera fidèle à celle voulue par le développeur, c’est un point important pour la fiabilité du service déployé.
N’importe quel fournisseur de serveur permet aujourd’hui d’installer Docker sur leur machine. C’est, là aussi, un gage de souplesse pour nous.

Les contraintes des serveurs

Un serveur est une machine physique souvent entourée de milliers d’autres dans un datacenter localisé à un endroit précis sur la planète. 
Les temps de réponse peuvent donc varier suivant la distance séparant l’utilisateur du service web.
Pour répondre à cette problématique, il est parfois nécessaire de déployer un conteneur sur plusieurs régions du monde.

S’assurer que ces serveurs restent utilisables dans de bonnes conditions est aussi un travail non négligeable, et c’est celui de l’administrateur système. 
Sauvegarde de données, disponibilité et exploitabilité des fichiers de logs, gestion des mises à jour, etc. Tous ces points sont à assurer au quotidien.

Kubernetes, associé à d’autres services, permet de répondre à la plupart des contraintes évoquées ci-dessus, ainsi qu’aux nécessités de scalabilité. Cette technologie demande malgré tout de solides connaissances supplémentaires.

Le colosse qui attend son heure

Ces serveurs tournent 24h/24 et 7j/7, et il arrive que certains services web, qui ne sont utilisés que quelques fois par jour, passent une très grande majorité de leur temps à tourner dans le vide.
Un autre point important pour assurer une fiabilité et des temps de réponse optimaux : ces serveurs sont choisis et dimensionnés dans une logique du moindre risque. C’est-à-dire que l’on va imaginer le pire des scénarios en matière de charge de travail afin de pouvoir s’assurer que le serveur répondra toujours sans impacter les utilisateurs.

Si on doit résumer et imager ces contraintes : imaginez un colosse capable d’assurer sa mission dans les pires conditions pendant un mauvais quart d’heure, mais qui, pendant 99% de son temps, semble travailler bien trop tranquillement.
Au-delà de l’aspect financier sur lequel une optimisation semble nécessaire, on ne peut ignorer l’impact écologique de ces machines dont les ressources sont majoritairement sous-exploitées.

Le cloud, un paradis ?

Si des solutions semblent répondre aux problématiques précédemment évoquées, le cloud a su nous convaincre sur ces points.
Reprenons les étapes du cycle de vie d’un service web destiné au cloud :
lorsqu’une version est fixée sur notre outil de gestion de version, notre système d’intégration continue va utiliser l’outil fourni par le fournisseur du service cloud pour envoyer, non plus une image Docker, mais directement le code lui-même.
Celui-ci sera ensuite automatiquement déployé en quelques secondes par le fournisseur lui-même.

Lorsqu’en utilisant une application mobile, l’utilisateur fera appel à un service web hébergé dans le cloud, ce dernier sortira de son état de veille pour répondre à la requête et s’éteindra aussitôt après, libérant ainsi des ressources pour d’autres.
Ainsi, seules les ressources nécessaires sont utilisées, optimisant l’impact énergétique et écologique du service. Et seules ces ressources utilisées seront facturées, par tranche de 100ms, de quoi alléger la facture de nos clients.

La scalabilité est aussi un atout important des clouds functions. Si 1000 utilisateurs utilisent en même temps des services web, le fournisseur saura déclencher 1000 cloud functions indépendantes sans aucune conséquence sur les temps de réponse.
Il est aussi possible de déployer facilement ces fonctions sur plusieurs régions du monde.

La réponse à tout ?

Playmoweb utilise aujourd’hui majoritairement les cloud functions pour ses services web… dans la mesure où c’est possible.
Car il arrive parfois que les contraintes techniques nous rappellent à l’ordre.
Les fournisseurs de cloud imposent en effet l’utilisation de certains langages uniquement, et ce, limités à quelques versions seulement. 
Héberger 100% de nos services sur le cloud devient impossible quand il faut utiliser des binaires spécifiques au traitement des informations de nos clients.
Dans ces rares cas particuliers, on revient à une méthode plus conventionnelle, celle des conteneurs avec tout ce que cela implique.

Google Cloud Run

Chez tous les fournisseurs de services cloud, il existe un service d’hébergement managé de conteneur. Mais, jusque-là, aucun n’offrait un des avantages des clouds functions : la scalabilité zéro qui permet à un service de s’éteindre complètement lorsqu’il n’est pas utilisé.

En 2019, Google Cloud a lancé son nouveau service Cloud Run offrant cette possibilité.

Un de nos services permet à notre client de traiter une banque d’images hébergées sur Google Cloud Storage afin de les compresser, de les compiler dans des fichiers PDFs et de combiner ces fichiers PDFs dans une archive zip qui est ensuite redéployée sur Google Cloud Storage.
Le service assurant cette lourde tâche nécessite des binaires spécifiques et ne peut donc pas être hébergé dans une cloud function, alors qu’il n’est utilisé que lorsque notre client en a besoin : de 1 à 5 fois par jour, 6j/7.
Ce service était hébergé sur un serveur dans un conteneur Docker.

Il y a quelques mois, nous avons choisi de migrer ce micro-service sur Cloud Run afin d’en optimiser l’utilisation.
Nous n’avons effectué aucune modification sur le fichier Dockerfile décrivant notre image Docker.
Google Cloud Run nous a permis d’utiliser à l’identique notre image Docker anciennement déployée sur l’un de nos serveurs.
Le service qui tournait 24h/24 et 7j/7 est désormais lancé automatiquement à la demande, optimisant ainsi son cout et son impact énergétique, tout en restant 100% fidèle à ce qu’il était quand il était déployé sur un serveur, que ce soit sur le code utilisé ou son utilisation au quotidien.
D’autres avantages s’offrent aussi : les logs sont centralisés et exploitables facilement dans la console de Google Cloud, et Cloud Run assure la scalabilité du service automatiquement. Pourquoi s’en priver ?

Nous pouvons aussi définir un pourcentage des appels qui seront dirigés vers une version différente de notre service, ce qui est très pratique pour tester la robustesse d’une nouvelle fonctionnalité avant d’en faire profiter tout le monde. Cette possibilité de déploiement partiel n’est, par exemple, pas disponible avec les cloud functions.

Pour terminer brièvement et techniquement sur Cloud Run, sachez que ce service utilise une implémentation de knative service.
Knative qui est une solution Open Source permettant de répliquer le comportement d’une cloud function sur un conteneur déployé dans un cluster kubernetes.

Si vous voulez plus d’informations, voici quelques liens intéressants :
– Cloud Run : https://cloud.google.com/run
– Knative : https://knative.dev
– FAQ très complète sur Cloud Run : https://github.com/ahmetb/cloud-run-faq

Concluons

Depuis quelques années, notre conviction est que le cloud répond à une grande partie des problématiques que nous rencontrons lorsqu’il s’agit de choisir une solution technique pour nos clients. Cloud Run est une nouvelle solution qui vient combler les lacunes des Cloud Functions et, après plusieurs mois d’utilisation, nous sommes enthousiastes sur cette technologie.

Ci-dessous, vous pouvez retrouver ma présentation lors des Human Talks d’Angers le 11 février dernier.