- Pour une startup en phase initiale, il peut être plus utile de consacrer son temps à construire le produit et à trouver le product-market fit plutôt qu’à mettre en place dès le premier jour Kubernetes ou l’auto-scaling
- Des fonctions Lambda réparties entre 20 et 30 unités, avec SQS et des logs dispersés dans CloudWatch, ont rendu le débogage, les modifications et les déploiements plus difficiles ; une simplification vers un conteneur NodeJS unique ou une app Flask/FastAPI avec Redis aurait été possible
- Dans un cas où 7 microservices sur EKS séparaient le CRUD et la logique métier, davantage de temps a été consacré à l’exploitation de l’infrastructure qu’au développement des fonctionnalités
- Même un serveur unique peut fournir suffisamment de calcul pour un service naissant en s’appuyant sur des options comme EC2, GCP VM, Hetzner ou latitude.sh, avec un serveur de 40 Go de RAM et plusieurs cœurs
- Même avec une architecture simple, il faut disposer de HTTPS, d’un accès SSH/SSM restreint, de CI/CD, du DNS, de sauvegardes de base de données, d’une VM de secours, d’un plan de reprise après sinistre, de règles de sécurité et d’une politique de rétention des sauvegardes pour une utilisation en production
Comment les startups en phase initiale se retrouvent avec une infrastructure excessive
- Pieter Levels est cité comme exemple d’exploitation de plusieurs micro-SaaS sur un seul serveur, en évitant la complexité de l’infrastructure cloud et en se concentrant sur le product-market fit
- Cette approche n’est pas la bonne réponse pour toutes les équipes, mais elle montre bien comment les déploiements et la gestion d’infrastructure peuvent devenir complexes pour la complexité elle-même
- Après le MVP, une petite équipe de développement peut rencontrer des difficultés sur les déploiements et la gestion de base de données, mais tous les projets n’ont pas besoin dès le premier jour de Kubernetes, de systèmes distribués complexes ou d’auto-scaling
- Une infrastructure simple permet à l’équipe de consacrer plus de temps à créer un bon produit et à trouver son adéquation au marché
- Les entreprises à l’échelle enterprise ont d’autres problèmes, comme la conformité et des effectifs très importants, mais une startup en phase initiale n’a pas besoin de reproduire cette complexité à l’identique
Cas concrets : la complexité comme charge opérationnelle
-
Surcharge de Lambda
- Il existait 20 à 30 fonctions Lambda pour différents services
- SQS et plusieurs tâches d’arrière-plan reposaient aussi sur Lambda
- Les logs étaient dispersés dans CloudWatch, ce qui rendait difficile l’identification de la cause d’un problème
- Le débogage était pénible, les modifications compliquées, et les déploiements devenaient complexes même dans un monorepo
- Il aurait été possible de simplifier avec un conteneur NodeJS unique ou une application Python Flask/FastAPI, avec des tâches d’arrière-plan basées sur Redis
-
Excès de microservices
- 7 petits microservices tournaient sur Kubernetes EKS
- Le CRUD et la logique métier étaient séparés en services distincts
- Kubernetes est puissant, mais cette équipe passait plus de temps sur l’infrastructure que sur le développement produit
- La nécessité d’un tel niveau de séparation des services à cette échelle reste discutable
Pourquoi l’approche du serveur unique est réaliste
- Une architecture sur serveur unique consiste à exploiter pleinement les performances des VM modernes
- On peut obtenir des VM puissantes à prix raisonnable chez Hetzner et latitude.sh
- Les instances GCP VMs et EC2 restent elles aussi à des tarifs raisonnables
- Un serveur avec 40 Go de RAM et plusieurs cœurs peut être un meilleur choix que plusieurs services distribués, plusieurs Lambda ou plusieurs tâches ECS
- Tout étant regroupé au même endroit, l’exploitation et l’administration deviennent plus simples
- La montée à plusieurs millions de QPS pourra être traitée quand ce moment arrivera réellement, et il y aura alors probablement une équipe infra
- Pour exploiter une VM unique de manière fiable, il faut des bases opérationnelles solides
- Une machine robuste comme EC2, GCP VM ou Hetzner
- Pour le web, HTTPS ; pour le déploiement, un accès sécurisé comme SSH avec restriction d’IP ou SSM
- Du CI/CD pour des déploiements sans interruption
- La configuration DNS
- Des sauvegardes régulières de la base de données
- Une VM de secours pour la redondance
- Une stratégie solide de reprise après sinistre et un temps moyen de restauration testé, atteignables avec une VM de secours
Docker Compose et Docker Compose Anywhere
- Docker Compose est pratique en développement local pour gérer plusieurs services avec une seule commande, mais il est moins utilisé en production
- Docker Swarm est mentionné comme deprecated
- Docker Compose peut entraîner du downtime lors des mises à jour
- Il existe un guide de déploiement en production, et il faut trouver un équilibre entre simplicité et préparation à la production
- Docker Compose Anywhere est un projet réalisé sur un week-end pour simplifier davantage une architecture sur VM unique
- Il permet une configuration en un clic d’un serveur Linux avec GitHub Actions
- Il prend en charge le déploiement continu sans interruption avec GitHub Container Registry et Docker Rollout
- Il fournit une gestion des variables d’environnement et des secrets, avec l’idée d’envisager age ou sops pour renforcer la sécurité
- Il propose des sauvegardes automatiques de Postgres basées sur GitHub Actions
- Il prend en charge plusieurs applications sur une seule VM
- Il automatise le SSL avec Traefik et Let’s Encrypt
- Il permet de déployer des applications Next.js, Go, Python, Node.js, etc.
Principes de sécurité et d’exploitation indispensables, même en restant simple
- La sécurité et la protection des données ne peuvent pas être omises, même avec une architecture simple
- Il faut des règles de pare-feu strictes n’ouvrant que les ports nécessaires
- Les clés SSH doivent être gérées de manière sûre, et sur AWS on privilégie SSM, sur GCP la CLI
- Un bastion host peut être utilisé pour renforcer la sécurité
- Il faut protéger les secrets et envisager l’usage d’un WAF ou de Cloudflare
- Les sauvegardes chiffrées de base de données doivent être envoyées vers S3 ou un stockage cloud équivalent et sécurisé
- Des snapshots disque doivent être créés régulièrement pour une redondance supplémentaire
- Une politique de rétention doit être mise en place pour les sauvegardes et les snapshots
- La priorité des ingénieurs est de préserver la simplicité de la configuration et de se concentrer sur le produit cœur
- Il est facile de se laisser distraire par des architectures complexes imitant Google Engineering ou les pratiques des grands groupes, ainsi que par de nouveaux outils
- Qu’il s’agisse d’une startup ou non, le plus important reste de parler aux utilisateurs et de trouver le product-market fit
1 commentaires
Avis sur Hacker News
J’ai souvent sué sang et eau sur plusieurs projets à cause de technos à la mode
Alors que les équipes étaient petites, on finissait parfois par produire des résultats d’une qualité incroyablement faible au motif qu’il fallait une « scalabilité infinie », et il arrivait aussi que des équipes immatures, ne comprenant même pas vraiment ce qu’est une LTS, décident qu’il leur fallait Kubernetes
Aujourd’hui, j’ai un code Puppet concis qui permet de créer, chez n’importe quel fournisseur, une VM durcie à la taille voulue, puis d’y faire tourner des services Docker, un backend Python ou du service de fichiers statiques
Qu’une VM Hetzner ait 2 cœurs ou 48 cœurs, je peux créer le service en moins de 5 minutes, contrôler la configuration via des manifests gérés dans le contrôle de source, et surveiller la conformité de la configuration avec des plugins Naemon personnalisés
C’est un processus entièrement reproductible, mais des équipes de startup créent dans le cloud des configurations uniques comme des flocons de neige, dépensent des milliers d’euros par mois, et obtiennent pourtant des résultats inférieurs à ce que faisaient les pionniers du DevOps en 2017
J’ai aussi écrit un article à ce sujet, intitulé The Emperor's New clouds : https://logical.li/blog/emperors-new-clouds/
Je n’ai jamais compris la question « comment reproduire une configuration sans Docker ni autre technologie »
Les scripts étaient déterministes, les versions des dépendances étaient figées, la configuration, les paramètres d’entrée et l’ordre d’exécution étaient identiques, et le tout tournait sur une machine de calcul déterministe
Il n’y avait aucune raison que ce ne soit pas reproductible
Au lieu de dire qu’il y a Docker sur une VM durcie, il suffit de dire qu’il y a kubelet, et avec un plan de contrôle k8s très peu coûteux, on peut piloter toutes ces VM au lieu d’empiler plusieurs « docker services » bricolés
Je ne vois pas en quoi cette approche serait meilleure, et elle me paraît même pire
Une mauvaise infra cloud, c’est quand on essaie d’utiliser tout ce qu’AWS vend, au point que toute l’infrastructure se retrouve liée à des couches d’abstraction beaucoup trop élevées et qu’il devient impossible de migrer vers une autre plateforme
k8s n’a rien à voir avec ça
Si la réponse à l’un de ces points est « on l’a fait maison » ou « il suffit d’un script », c’est précisément pour cela que k8s a de la valeur
Pour un backend Python, il suffit de reproduire le script de build sur le VPS :
pip install requirements.txt>python main.py>nano /etc/systemd/system/myservice.service>systemd start myservice> terminéPour étendre le nombre d’instances, mettez ces commandes dans un script bash
build_my_app.sh, qui joue alors le rôle d’un nouveau Dockerfile et peut installer l’application sur n’importe quel serveur en quelques dizaines de secondesUtilisé comme IaaS, il permet de prototyper bien plus vite que d’autres approches, y compris des VPS d’autres fournisseurs
Google Cloud, en particulier, crée peu d’enfermement propriétaire et respecte mieux le principe de moindre surprise
Mais une fois le prototype réalisé, il faut se demander s’il vaut mieux le reconstruire ailleurs, moins cher
Le fait de pouvoir étendre les disques presque à l’infini et de disposer de snapshots est appréciable, et le cloud peut permettre de faire monter un prototype jusqu’à une charge de production afin de mesurer l’échelle réellement nécessaire
En revanche, quand on s’appuie sur la « magie du cloud » comme Cloud Run ou Lambda, le temps passé à apprendre et à déboguer finit par être aussi long qu’avec l’ancienne méthode
Dans une petite startup, on fonctionne à peu près comme ça
Il y a bien quelques parties complexes, comme l’autoscaling de files de travaux mêlant des GPU, mais le cœur, c’est nginx, l’appli web, Postgres et Redis sur une seule VM
Comme c’est du B2B, il n’y a presque pas de trafic
Les développeurs peuvent exécuter exactement la même configuration sur leur portable Linux ou dans une VM Linux sur une autre plateforme, et chacun peut aussi avoir sa propre VM cloud s’il le souhaite pour des démos ou des tests
Pour amorcer un nouveau système, il suffit plus ou moins de commiter une clé SSH et de lancer un script shell
C’est facile à déboguer, ni complexe ni coûteux, et on peut pas mal scaler verticalement avant d’avoir besoin de scaler horizontalement
Ça ne convient pas à tout le monde, mais avant la phase seed, je trouve ça tout à fait approprié
C’est un niveau d’indirection par rapport à l’approche consistant à « commiter la clé publique », et l’utilisateur peut remplacer ses clés sans changement Git
Et même si cela s’éloigne pas mal de la description initiale, la location de clés SSH gère bien mieux les situations d’offboarding, ce qui est vraiment appréciable : https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
En cherchant le lien, je suis aussi tombé sur une doc où Vault affirme proposer des mots de passe à usage unique <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
Cela dit, je suis fermement dans le camp « PasswordLogin no », donc à chacun d’être prudent avec cette option
Postgres peut tout faire
Dans une telle configuration, comment suivez-vous la configuration et les mises à jour de la VM ?
La réponse est « non, pas vraiment »
Mon SaaS tournait au départ sur un seul serveur, puis après avoir trouvé son product-market fit, je l’ai déplacé sur plusieurs serveurs
Ce sont des serveurs bare metal chez Hetzner ; il n’y a pas de microservices et je n’ai pas à gérer Kubernetes, mais nous exploitons bien une base de données distribuée
Ces serveurs bare metal sont incroyablement puissants par rapport aux machines virtuelles des fournisseurs cloud
J’avais même fait mes propres mesures il y a quelques années : https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
Dans l’ensemble, cette approche est d’une efficacité presque absurde
On évite d’avoir à gérer la complexité de Kubernetes, on évite aussi les pannes en cascade qui surviennent inévitablement dans les systèmes complexes, et on économise du temps de développement, de la maintenance et des coûts mensuels de serveurs
L’objection habituelle, c’est « mais comment allez-vous scaler ? » ; or on ne sait même pas encore s’il faudra scaler, et avec des machines aussi puissantes et une conception raisonnable, on peut aller très loin avec 3 à 5 serveurs
Bien sûr, je ne suis pas en train de dire qu’il faut faire tourner son business dans un placard chez soi
L’automatisation reste nécessaire pour administrer les serveurs, et j’utilise ansible et terraform
Il nourrit l’optimisme selon lequel le logiciel va connaître un succès fulgurant en très peu de temps, et les gens ont envie d’y croire
Je ne sais pas si vous avez lu l’article ou seulement le titre
Si vous descendez jusqu’à la section A few considerations, plus bas, il y a de quoi moins rire
Ces « quelques considérations » représentent notamment un bon gros bloc de travail de sécurité si vous stockez ou transmettez des informations très sensibles
Dans ce genre de situation, comment gérez-vous des exigences de conformité comme HIPAA ?
Il existe deux types de programmeurs
Ceux qui pensent avoir tout vu, et ceux qui savent qu’ils n’ont presque rien vu
C’est pour cela que ce genre d’affirmation absolue est fatigant
Les 20 % essentiels de Kubernetes, ce sont les déploiements, pods, services, la manière de gérer les déploiements blue-green, les définitions déclaratives, la séparation par namespaces, etc., et c’est vraiment très bien
Si l’on s’en tient à ces bases simples, qu’on utilise un service Kubernetes managé dans le cloud et qu’on garde les bases de données avec état en dehors du cluster, l’expérience est bonne
Les problèmes commencent quand on se fait aspirer dans le terrier du « cloud native » et qu’on commence à utiliser toutes sortes de systèmes open source de niche, d’opérateurs, ambassador, des patterns sidecar, etc.
Ces choses-là sont faites pour des environnements où coexistent plusieurs équipes techniques, indépendantes mais connectées, et différents langages de programmation
J’ai l’impression que, dans ce genre de discussions, les gens parlent souvent de deux choses différentes
Pour moi, ce n’est qu’un mode de déploiement uniforme, meilleur que Docker Compose
On paie très peu pour le plan de contrôle, et les workers sont des VM ordinaires avec kubelet
Mais pour beaucoup de gens, « Kubernetes » semble désigner le deuxième paragraphe ci-dessus
Il n’y a absolument aucune obligation de l’utiliser comme ça
On peut très bien configurer un cluster k3s et n’apprendre que les workloads, services et ingress
C’est tout ce qu’il faut pour remplacer des VM bricolées et des configurations Docker
Dans 99 % des cas, les gens n’ont besoin, ou ne veulent, que quelque chose comme docker-compose++
Si les déploiements sans interruption sont inclus par défaut, avec un système de configuration simple pour les replica sets ou d’autres mécanismes de réplication/distribution, on a presque tout
J’aimerais qu’il existe quelque chose qui ne fasse que ça
Kubernetes embarque beaucoup de bagages, et Docker Compose est un peu trop basique pour des exigences de production importantes
Kubernetes a environ un million de boutons et de molettes ajustables pour tous les usages imaginables, mais on peut tout aussi bien les ignorer et se contenter des fonctionnalités de base pour garder les choses simples
On peut assez vite obtenir une configuration avec des déploiements corrects, des logs et métriques très faciles, et une bonne expérience développeur
Vu sa très mauvaise réputation et le fait que je ne l’avais jamais utilisé auparavant, je m’attendais au pire quand j’ai demandé si je pouvais mettre en place un serveur pour des outils internes
En réalité, la personne qui l’avait configuré m’a fait un tutoriel de 30 minutes, m’a expliqué tous les concepts, puis m’a donné suffisamment d’informations pour déployer le serveur, et je l’ai fait sans aucun problème
Mettre en place un déploiement automatique via
git pusha aussi été très rapideÀ mes yeux, c’était un choix évident
C’est bien plus facile à utiliser dès que votre service n’est pas littéralement le seul
Cela dit, je ne l’ai pas installé moi-même, donc sa mauvaise réputation vient peut-être de là
Sans k8s sur le CV, qui va décrocher un nouveau poste ? :)
Plus sérieusement, je pense que beaucoup de gens choisissent volontairement la voie difficile pour apprendre l’infrastructure à grande échelle
Une autre raison courante est : « ce sera beaucoup plus simple quand on aura énormément de clients » ou « on pourra scaler dynamiquement selon la demande »
C’est tout à fait valable pour la personne qui construit le système, mais beaucoup moins pour un fondateur ou un CTO professionnel
Certaines personnes brûlent de l’argent à construire des gadgets séduisants, sans se soucier des besoins des clients potentiels ni des délais
C’est un peu comme aller au garage pour changer ses pneus, et voir le mécanicien prendre trois semaines parce qu’il veut installer des suspensions hydrauliques de lowrider et des enjoliveurs tournants pour satisfaire son envie de progresser
Le pire, c’est que cela rend les choses fondamentalement ambiguës pour la personne suivante
Impossible de savoir si quelque chose est là parce que c’était réellement nécessaire, ou si ce n’est qu’un ornement brillant
Je ne sais pas si les gens font ça par intérêt, par amour de la technologie, ou, comme dit plus haut, pour monter en compétences de façon technocratique et mettre k8s sur leur CV
Moi, tout ce que je me dis, c’est : « ça a l’air pénible à maintenir »
C’est pourquoi je pense que l’infrastructure k8s devrait plutôt être conçue et opérée par un cercle plus restreint de vrais experts, ou au moins par des personnes expérimentées capables d’encadrer des juniors
Et quand ce n’est pas nécessaire — c’est-à-dire pour la plupart des startups, petites entreprises et entreprises de taille moyenne — il vaut mieux rester sur des paradigmes existants plus faciles à utiliser
Ils sont très satisfaits de ce choix et l’ont détaillé sur leur blog
C’est un cas où « ce sera beaucoup plus simple quand on aura énormément de clients » s’est effectivement vérifié
C’est un vieux débat, souvent fatigant, mais je vais quand même y ajouter mes deux centimes.
Faut-il choisir un framework complexe dès le premier jour ? Probablement pas, sauf si l’équipe a déjà suffisamment d’expérience avec.
Ce à quoi je m’oppose, en revanche, c’est l’idée que gérer l’infrastructure avec des processus sur mesure et des outils maison demandera toujours moins d’effort de maintenance que des outils éprouvés.
C’est cette attitude qui consiste à rejeter obstinément l’épouvantail de la « complexité », alors que le processus fait maison n’est pas du tout simple et prend beaucoup de temps au produit cœur.
Tout le monde aime la simplicité qui consiste à copier un binaire sur un VPS et à redémarrer le service.
Mais très vite, il faut gérer la configuration et les secrets ; puis, quand plusieurs serveurs sont nécessaires pour la disponibilité et la redondance, il faut du déploiement progressif, de la répartition de charge, des rollbacks, etc.
On voudra aussi un environnement de staging, et il faudra pouvoir répliquer facilement ce workflow.
Quand l’équipe grandit, il devient aussi évident qu’on ne peut pas faire tourner en local un environnement ressemblant à la production.
Et les exigences continuent de s’ajouter ainsi.
Au final, pour chaque nouvelle exigence, au lieu de s’appuyer sur une solution standard que d’autres ont déjà trouvée, il faut la résoudre à sa manière, de façon particulière.
Plus tard, cela devient un problème de coûts irrécupérables.
Va-t-on abandonner des outils custom que l’on connaît et comprend pour migrer vers une « complexité » inconnue ?
Plus on investit, plus il devient difficile de migrer ensuite.
Ma suggestion est de suivre dès le départ des pratiques qui faciliteront une transition ultérieure vers des outils standards.
Autrement dit : déployer en conteneurs dès le jour 1, adopter la méthodologie des 12 facteurs, etc.
Et quand on commence à souffrir à cause de fonctionnalités nécessaires, mieux vaut passer tôt que tard à des outils éprouvés.
Il y a de fortes chances que la peur de l’inconnu se révèle infondée, et qu’à long terme on passe moins de temps sur l’infrastructure.
L’approche que j’ai envisagée serait de commencer dès le premier jour avec des outils standards, c’est-à-dire k8s + gitops, tout en continuant à faire tourner le tout sur une seule VM.
Qu’en pensez-vous ?
À l’inverse, on trouve beaucoup d’« ingénieurs cloud » capables de comprendre ce genre de systèmes cloud « complexes » et de les déployer et maintenir avec terraform.
C’est un ensemble de compétences immédiatement exploitable.
VM, stockage bloc/blob, DNS, IdP, registrar de domaine.
Dans le cloud, c’est à peu près tout ce que j’ai utilisé confortablement.
Dès qu’on entre dans le FaaS et tout ce qui va avec, ça devient vraiment bizarre pour moi.
J’ai du mal à accepter de ne pas pouvoir regarder dans la machine sur laquelle tourne l’environnement de production.
L’expérience de débogage via un dashboard cloud est lamentable.
Je pense que l’approche de Microsoft est ce qui se rapproche le plus de quelque chose qui « fonctionne » réellement, mais c’est quand même vraiment affreux et je ne veux plus jamais y toucher.
Dix ans plus tard, mon architecture idéale reste une seule VM où une base de code monolithique communique avec des instances SQLite locales.
L’arrivée du stockage NVMe a beaucoup renforcé cette approche.
Les sauvegardes se font via des snapshots du stockage bloc, et la durabilité transactionnelle, si nécessaire, via la réplication WAL.
C’est simple au point d’en être idiot.
Cela permet de se concentrer sur le business et les clients.
Les clients n’en ont strictement rien à faire, et ne paieront pas pour ça.
Tout le code et toute l’infrastructure sont des facteurs purement négatifs, donc il faut en avoir le moins possible.
Quand les gens disent que le cloud est plus cher que l’on-premise, c’est souvent pour cette raison.
Si vous comptez faire tourner des VM 24 h/24, il existe de meilleures options.
Même les livres sur les microservices disent de commencer par construire un monolithe.
Avant d’avoir des retours de vrais utilisateurs, on ne sait pas comment découper le système, et il est plus facile de découper un monolithe que de réorganiser des services.
Il se peut même qu’on n’ait jamais besoin de découper le monolithe.
Stripe a bien fini par extraire certaines parties de son monolithe Rails, mais un monolithe permet d’aller étonnamment loin.
Difficile de faire plus facile à déboguer qu’un monolithe du type Django/Rails.
Cela dit, il est utile d’anticiper un peu la direction que prendra l’infrastructure.
La première version de notre entreprise était un conteneur Docker Django sur une seule VM, avec un déploiement manuel en
docker pull; docker stop; docker start.Cette configuration a tenu plus longtemps que prévu.
Docker est un bon moyen de contourner les problèmes de packaging des dépendances.
Au début, des choses comme savoir si le serveur a les fichiers d’en-tête C nécessaires après l’installation d’un nouveau driver de DB, ou si sa configuration diffère de celle du Mac, peuvent être pénibles.
Après notre tour d’extension de seed, nous sommes passés à k8s pour des besoins business de fiabilité et de scalabilité, et k8s a bien tenu jusqu’à la série B.
Le fait d’avoir tout dockerisé a facilité la transition, mais au stade initial nous avons réduit agressivement la complexité.
Et il faut utiliser correctement le framework, plutôt que de recréer une version bancale des fonctionnalités qu’il fournit.
Sur ce point, une personne expérimentée obtient de meilleurs résultats que dix personnes inexpérimentées.
L’écart s’accumule avec le temps.
Je pense que la moitié des raisons pour lesquelles les gens se lassent des monolithes vient de monolithes mauvais et mal exploités.
Ils disent que les données doivent être stockées dans leur propre service, et que si une approche multi-paradigme est nécessaire, par exemple relationnel + recherche full-text, cela peut devenir plusieurs services.
L’expérience utilisateur doit aussi utiliser son propre service.
Au minimum, il faut encore un autre service entre les deux, et c’est généralement là que Django et Rails interviennent.
Ils disent qu’il peut aussi, optionnellement, falloir des services supplémentaires pour l’authentification, les transactions financières, etc.
J’ai exploité un projet pendant environ six ans sur un seul VPS à 10 dollars par mois.
Grâce à une remise permanente obtenue sur lowendtalk, je payais en réalité moins que ça, et c’était un fournisseur de VPS surtout orienté serveurs de jeu.
À part une journée complète d’indisponibilité parce que j’avais cassé la configuration et dû faire une réinstallation propre de l’OS, et une autre fois où le fournisseur a changé l’adresse IP après préavis, la stabilité était quasiment au niveau 99,999 %.
La technologie VPS a énormément progressé et elle est très stable.
Les disques des nœuds sont configurés en RAID 1, et lors de la maintenance d’un nœud, la VM elle-même peut facilement être migrée à chaud vers une autre machine.
On peut aussi prendre des snapshots.
Pour moi, si je choisissais une infrastructure cloud, ce ne serait pas pour une meilleure stabilité, mais pour les fonctions de collaboration et de gestion opérationnelle comme IAM, la gestion des secrets et l’infrastructure as code, ou pour des raisons de conformité de datacenter comme HIPAA.
Ça dépend de la situation
Personnellement, j’aime les solutions basées sur le cloud parce qu’elles me font gagner beaucoup de temps
Cela dit, il faut choisir très soigneusement ce qu’on utilise, et certaines solutions sont tellement complexes qu’elles sont clairement contre-productives
Je dirige une petite startup bootstrapée
Nous n’avons même pas assez d’argent pour nous verser des salaires, et je vis grâce à une activité de consulting à côté
Avec un budget et un temps aussi limités, nous devons être très prudents sur ce que nous utilisons
C’est pour ça que j’aime bien des services comme Google Cloud
Notre facture GCP est assez faible, quelques centaines d’euros par mois
Nous pourrions passer chez un fournisseur moins cher, mais il est difficile de justifier l’investissement en temps, et par rapport à AWS que j’ai utilisé auparavant, j’aime aussi l’interface et les outils de Google
Nous n’avons aucune raison d’utiliser Kubernetes
Le simple coût d’un cluster vide serait déjà supérieur à notre facture GCP mensuelle actuelle
Nous n’en avons pas besoin non plus, parce que nous ne sommes pas tombés dans le piège des microservices
En revanche, j’aime Docker
Il rend le déploiement de logiciels d’une simplicité enfantine
Notre site web est un bucket Google Storage servi via un load balancer et Google CDN
Le même load balancer route les appels REST vers deux VM qui exécutent un monolithe
Ces VM communiquent avec une DB managée, Elasticsearch managé et Redis managé
La DB et Elasticsearch coûtent cher, mais les utiliser en managé fait gagner beaucoup de temps et d’efforts
C’est à peu près tout ce que nous avons, c’est simple et pas si cher que ça
En migrant l’ensemble chez un fournisseur comme Hetzner, nous pourrions probablement réduire les coûts d’environ 50 %
Ça pourrait valoir le coup d’essayer, mais ce n’est pas une priorité urgente pour moi
Perdre ces services managés me compliquerait la vie
Et il y a aussi le fait que certains clients semblent préférer AWS, donc nous devrons peut-être y revenir un jour