Clever Cloud, vous connaissez ? Ca vend un produit PaaS. Ca peut même remplacer Kubernetes il paraît, trop bien ! Testons et analysons donc la plateforme en situation réelle, comme d’habitude sur ce blog, sans bullshit.
Le projet
Je bosse depuis quelques mois sur un SaaS de monitoring. Projet bien fun à faire, sur lequel j’avance à mon rythme et qui permet de s’occuper pendant les longues nuits d’hiver.
Le projet tourne chez Scaleway, sur des machines virtuelles classiques. Il utilise également une base de données PostgreSQL (gérée par Scaleway).
Dans cet article, je vais tenter le déploiement de l’API de mon projet chez Clever Cloud. Cette API est écrite en Go (et est donc un simple binaire statique) et a juste besoin en dépendance dans le cadre de cette article d’une base de données PostgreSQL pour démarrer.
On est donc sur un besoin très simple qui semble donc parfait pour du PaaS. J’en profiterai pour faire une analyse de la plateforme sur l’à côté. Allons y !
Base de données
Pour plus de facilité, je ferai tout en clic dans l’interface dans cet article. Une CLI est aussi disponible si vous le souhaitez (écrite en javascript mais passons).
Je commence donc par créer ma base de données dans l’interface: en quelques clics c’est fait, aucun problème. J’obtiens les informations de connexion de ma base de données: host, user, password.
Premier soucis (ouais j’ai mon Linux en Français): psql: erreur : n’a pas pu traduire le nom d’hôte « <id>-postgresql.services.clever-cloud.com » en adresse : Nom ou service inconnu
Impossible de me connecter à la base de données.
Après un peu d’attente, ça passe. Bon c’est du cloud mais faut pas trop être pressé sur la propagation DNS.
Seconde surprise: ma base de données est exposée sur internet. Ca pose bien sûr un énorme soucis de sécurité. Idéalement je voudrais que seule mon application puisse se connecter sur la base, et pouvoir éventuellement ouvrir mon IP temporairement pour un accès administrateur (dans la vraie vie faudrait du VPN ou autre mais on va pas pousser mémé dans les orties, on va rester dans le mindset "utilisateur de base qui fait le strict minimum pour que ce soit plus ou moins sécurité").
Rien dans l’interface pour le firewalling. Je cherche dans la doc, et je trouve finalement: c’est pas possible.
Bon là j’ai quand même regardé mon calendrier pour vérifier: oui on est bien en 2023 et on doit encore faire des mails au support pour des features basiques de sécurité. J’espère d’ailleurs que vous êtes pas pressé si vous devez accéder à la DB en urgence, et que vous n’êtes pas en IP dynamique chez vous.
Ce premier critère exclut déjà l’utilisation de la plateforme pour tous les projets un peu sérieux mais bon, continuons.
Déploiement de l’application
Création de l’application
Je commence à créer l’application depuis l’interface. Déjà ça commence mal: je dois probablement choisir un truc sur cette page mais rien ne s’affiche (ce problème existe depuis plusieurs mois, je l’ai déjà rencontré avant):
Bon, je vais cliquer sur Next et on verra plus tard. je choisis mon datacenter (je garde celui par défaut), et mon application est créée. Je dois maintenant pousser mon code pour déclencher un déploiement.
Lisons un peu la documentation:
Your application listens to the wild network 0.0.0.0,: aucun soucis.
Your application listens on port 8080: wut ? Je peux pas choisir mon port ? Pourquoi ?
You put your main code in a file named main.go aucun soucis.
Je passe à la section Build the application: j’utilise bien sûr les go modules (avec un go.mod etc, bref le standard Go depuis des années).
Bon allez, on teste. n’oubliez pas la variable CC_GO_PKG et CC_GO_BUILD_TOOL=gomod (qui est le standard depuis 150 ans donc pourquoi devoir le préciser) car sinon ça explose direct avec des erreurs (du genre no required module provides package).
Problème: ça continue de péter avec des erreurs bizarres (http/root.go:11:2: cannot query module due to -mod=vendor). Je décide de ne plus faire de vendoring pour tester un build encore plus "classique".
Surprise: je reviens dans la situation initiale d’avant la définition des variables CC_GO_PKG et CC_GO_BUILD_TOOL: des erreurs du type no required module provides package. Je rappelle que je n’utilise aucune lib privée en dehors de mon projet.
Le temps passé à tenter de déployer un simple binaire Go se compte maintenant en heure. Je décide d’abandonner et de juste écrire un "main.go" sans aucun autre fichier et aucune dépendance, juste pour voir si j’arrive au moins à déployer une application.
Je recrée donc une application from scratch; go mod init clever et un main.go contenant:
package main
import (
"fmt"
"io"
"net/http"
)
func lol(w http.ResponseWriter, _ *http.Request) {
io.WriteString(w, "Srsly ?n")
}
func main() {
fmt.Println("I'm starting")
http.HandleFunc("/", lol)
http.ListenAndServe(":8080", nil)
}
Ca fonctionne (et ça semble d’ailleurs utiliser go install ⊙﹏⊙) !
Aller plus loin
On peut déjà voir que c’est la galère lorsqu’il s’agit de déployer un vrai projet. Mais continuons de creuser un peu la plateforme.
Gestion de configuration
Je n’ai pas trouvé comment injecter des fichiers de configuration dans les applications. C’est pourtant un besoin commun. Seulement des configurations via variables d’environnements semblent disponibles.
J’avais fait il y a longtemps un email au support Clever Cloud quand je testais pour un autre besoin la plateforme et il n’y avait pas de solutions. C’est toujours le cas aujourd’hui.
Réseau
Clever Cloud n’offre quasiment aucune fonctionnalité réseau, par exemple des réseaux privés ni de règles de firewalling (type security groups, qui seraient une solution éventuelle même en exposant les applications sur des IP publiques).
Si vous avez plus de deux applications à déployer et à faire communiquer de manière sécurisée (donc sans passer par internet), vous ne pourrez pas utiliser la plateforme.
On rappelle que les VPC AWS sont sortis en… 2009.
Secrets
Je ne vois aucune façon sécurisée de stocker et injecter aux applications des secrets autres que d’utiliser des variables d’environnements. Mélanger configuration et mots de passe est une très mauvaise idée qui semble ici encouragée.
Sur de L’IaaS classique il est toujours possible de gérer soit même les secrets (Hashicorp Vault, Ansible Vault). Sur des cloud comme AWS il y a des outils comme secret manager. Ici, vos secrets ne seront pas plus secret que l’hostname de votre base postgreSQL.
Ici aussi on m’a dit que c’était "dans la roadmap" (probablement dans la même roadmap que le FaaS en alpha présenté à Devoxx il y a 4 ans).
IAM
Inexistant ?
Couplage build and run
Un sujet dont je parlais déjà dans cet article. Il y a dans clever cloud un fort couplage entre le build de votre application et son déploiement.
Cela est probablement une tentative de créer une expérience utilisateur unifiée, mais le résultat est un lock-in fort qui force à tout faire en passant par Clever Cloud, là où de nombreux utilisateurs (dont moi) ont déjà toutes leurs CI (et stockage des artefacts de build) dans Github, Gitlab… et nos images Docker sur Harbor, Docker hub etc.
Une approche sans avenir pour moi. Le fait d’être forcé de lier une application à un dépôt Git (confirmé par le support) est également dommage. Dans la vrai vie on veut juste fournir l’adresse d’une image Docker et c’est tout.
Stockage
Il y a du S3, mais aucun stockage local (les limitations de FS bucket le rendent pas vraiment utilisables). Donc vous ne pourrez déployer aucune application ayant besoin d’un stockage local non partagé.
Health checks
Il est commun aujourd’hui d’avoir plusieurs types de health checks pour monitorer la santé d’une application. Vous avez accès par exemple sur Kubernetes aux startup probes, readiness probes, et liveness probes, chacune répondant à un besoin précis et permettant de contrôler comment, au niveau réseau, et quand l’application recevra ou non du traffic.
Il est aussi souvent possible de configurer plusieurs types de checks: HTTP, TCP, gRPC, commandes, avec choix des ports, path, timeouts, intervalles, delais avant de commencer le check…
Clever Cloud ne semble avoir qu’un type de healthcheck (HTTP) et avec peu de paramètres. Vous serez donc rapidement limités pour gérer des cas un peu pénibles (slow start, services TCP et gRPC…).
On va s’arrêter là.
TL:DR
Clever Cloud vous conviendra très bien si vous voulez héberger le site de votre PME ou le CFP de votre conférence (une application HTTP et une base de données, un VPS avec de l’autoscaling pour résumer), et si n’êtes pas regardant sur la sécurité.
Les applications avec des architectures un peu plus complexes (plusieurs services, protocoles non HTTP voir non TCP, briques sortant du cadre web ou demandant du stockage local…) ne pourront pas être déployées.
Mais au final, comme on l’a vu avec mon exemple en Golang ici que je n’ai réussi à faire marcher, vous allez devoir quand même devoir vous battre avec le PaaS. Un Netlify ou un fly.io (ou un Heroku, qui même en étant en mode maintenance depuis 10 ans vous fournira plus de features) vous posera moins de problèmes, ou même 2 VMs chez Scaleway avec un load balancer devant.
Les autres besoins devront aller voir ailleurs: IaaS classique (qui ont souvent aussi des services de base de données, métriques, messages bus… en mode PaaS, c’est ce que je fais aujourd’hui pour certains projets), offres Kubernetes as a service…
Vous aurez également beaucoup moins de lock-in sur votre infrastructure et votre vous du futur vous remerciera.
Peut être qu’il serait temps pour certains de passer moins de temps en conf ou à taper sur Docker et Kubernetes (et leurs utilisateurs), non ?
On a compris que c’était une stratégie marketing (certains se rappelleront de l’épisode Traefik dans la même veine) mais j’ai personnellement du mal à cautionner la diffusion volontaire d’informations fausses pour tenter de gagner quelques clients.
Se concentrer un peu plus sur les produits et délivrer une plateforme pouvant répondre aux besoins du monde tech d’aujourd’hui est sûrement une bonne idée.
Spider DevOps
