Comme 99% des développeurs web de mon âge, j’ai appris à faire des sites grâce au site du zero. Et en 2010, quand il s’agissait d’héberger un site, je partais souvent chez OVH. Avec leurs offres mutualisées, puis leurs VPS.
Et puis j’ai commencé à travailler dans une petite boite de e-commerce en 2015 où le challenge était de poser les bases pour donner plus d’autonomie au fondateur pour évoluer dans le monde des marketplaces. La copie finale reposait sur des petits services nodeJS indépendants.
Pour héberger tout ça, on est parti chez Google Cloud Platform, et on a en grande partie tiré profit du service Cloud RUN .
Si vous ne connaissez pas ce service, il consiste à renseigner une image docker, et le service se charge ensuite de le mettre à l’échelle en fonction du nombre de requêtes qu’il doit traiter en parallèle. Et le gros avantage est qu’il est capable de descendre à 0 instance. Cela veut dire que vous ne payez absolument rien quand certains de vos services sont très peu utilisés.
Notre expérience sur ce service est assez formidable dans le sens où son architecture rend impossible le fameux “down”. Votre application ne peut tout simplement pas crash, et c’est un avantage auquel je n’avais jamais encore goûté. Plutôt sympa pour bien dormir quand on aime partir en vacances.
Comme pour les fonctions lambda de AWS , ou les cloud functions de Google, cette architecture implique un “cold start”. Ce qui veut dire que quand une requête nécessite la création d’une nouvelle instance, le démarrage du conteneur s’ajoute au temps de traitement de la requête de l’utilisateur.
En parallèle de ça, on maintenait également un petit cluster kubernetes pour faire tourner des applications qui avaient besoin de tourner en continu. Mais on essayait le moins possible de dépendre de ce cluster parce que sa maintenance est monstrueusement chronophage. Et je ne vous parle pas de partir en vacances en laissant le bébé à la maison.
Et comme j’aimais énormément ce qu’on faisait au travail, j’ai répliqué sur mes projets perso. Dont ce blog! Qui tournait auparavant sur Cloud RUN. J’avais aussi un CDN chez AWS pour leur service CloudFront qui est aussi de bonne facture 😄. Mon CDN me permet de choisir les dimensions de mes images à la volée, c’est plutôt pratique. J’explique ça dans mon article Comment fonctionne ce blog?
Mais au final, maintenant que je suis plutôt à l’aise avec AWS et GCP, je n’ai plus besoin de ça pour mon blog qui attire à peu près 0 visiteur.
Et je suis donc retourné sur un bon vieux serveur bare metal fourni par Kimsufi , qui me coûte 20 euros par mois, et qui me propose un processeur relativement OK, 32 Go de RAM et 2To de disque.
Pour obtenir ça chez GCP ou Amazon, il faudrait dépenser une fortune pour l’utilisation que j’en fais!
Cette machine me sert donc pour 100% de mes usages. Il héberge mes sites grâce à des conteneurs docker et un petit proxy maison. Il repose sur des certificats let’s encrypt que je devrais renouveler manuellement tous les ans, le fait de relancer mes conteneurs me coûte un downtime de quelques secondes. Mais bon dieu que ça fait plaisir de retrouver un peu ça! Je mets exactement 0 seconde à envoyer en production parce que la plupart de mes apps sont en hot reload. Le cauchemar de tout ce qu’on pourrait lire sur le web.
Mais en réalité, plus je lis de retours d’expériences, et plus j’entends parler de tout ce qui est DORA metrics, plus j’ai envie d’aller explorer à l’extrême l’idée du “partir le plus vite possible en production” ou encore “Move fast break things”. Donc oui je sais mettre en production sans qu’une seule requête parmi des millions ne le sente passer. Mais pour ce blog, j’aurais 5 secondes d’indispo 😄
Je me sers aussi de ce serveur pour développer directement avec VsCode. Grâce à tout un tas de mécanismes, je pourrais vous en parler dans un prochain article si ça vous intéresse. J’ai vu que mon article sur Cloud Workstations avait attiré quelques visiteurs depuis Google, et je crois fermement au remote development.
Je pense que même au sein de grandes entreprises, il y’a énormément de cas d’utilisation pour lesquels on pourrait faire à nouveau usage de serveurs comme ceux-là. Sachant qu’il n’est pas incompatible de prendre du calcul chez OVH, et tout de même tirer profit des services intégrés aux providers cloud. Comme S3 ou les buckets Google. Personnellement, j’ai même choisi de tout de même conserver tout ce qui est stockage des logs et tracing chez Google. Cela ne me coûte absolument rien à mon échelle et les services sont de qualité.
Je vous laisse avec ce pricing imbattable de la gamme ECO d’OVH:
Et je ne suis malheureusement pas affilié à OVH, malgré 2 actions que j’ai acheté il y’a quelques années au plus haut et qui ont perdu 50% de leur valeur 😡
Et vous, vous vous y connaissez en serveurs pas cher? Dîtes moi vos bons plans en commentaire! ⬇️
Et tant qu’on y’est, dîtes moi aussi si vous avez déjà entendu parler du remote development ou si vous en avez déjà fait l’expérience, je suis curieux d’entendre ce que vous avez à dire sur le sujet.
.png?w=80&h=80&f=webp)