Votre startup a-t-elle vraiment besoin d’une infrastructure cloud complexe ?

 (hadijaveed.me)
4 points par GN⁺ 2024-09-15 | 1 commentaires | Partager sur WhatsApp

A-t-on vraiment besoin d’une infrastructure cloud complexe ?

  • En écoutant Pieter Levels parler dans le podcast de Lex Fridman, j’ai eu beaucoup de déclics
  • Pieter exploite ses applications sur un serveur unique et a construit avec succès une activité de micro-SaaS rentable
  • Il est important d’éviter la complexité de l’infrastructure cloud et de se concentrer sur l’adéquation produit-marché
  • Cela ne convient peut-être pas à toutes les startups, mais il faut éviter la complexité pour la complexité

Observations récentes

Projet 1 : surcharge de Lambda

  • Exploitation de divers services avec 20 à 30 fonctions Lambda
  • Tâches en arrière-plan avec SQS et Lambda
  • Logs dispersés dans CloudWatch

Résultat : le débogage est difficile, les changements sont compliqués et le déploiement est complexe. Il aurait été possible de simplifier cela avec un conteneur NodeJS unique ou une application Python Flask/FastAPI et Redis.

Projet 2 : confusion autour des microservices

  • Exploitation de 7 petits microservices sur Kubernetes (EKS)
  • Services séparés pour le CRUD et la logique métier

Résultat : davantage de temps passé à gérer l’infrastructure. On peut se demander si ce niveau de séparation était réellement nécessaire.

La force d’une configuration sur serveur unique

  • Les serveurs modernes sont puissants. Hetzner et latitude.sh proposent des VM puissantes à bas prix
  • Les VM GCP et les instances EC2 sont elles aussi proposées à des tarifs raisonnables
  • Une puissance de calcul importante avec 40 Go de RAM et plusieurs cœurs
  • Tout est centralisé, donc plus facile à administrer
  • Les problèmes de montée en charge à plusieurs millions de QPS pourront être traités plus tard

Ce qu’il faut pour une configuration sur une VM unique :

  1. Une machine puissante (EC2, VM GCP, Hetzner, etc.)
  2. Un accès sécurisé (HTTPS, SSH restreint par IP ou SSM)
  3. Du CI/CD pour des déploiements sans interruption
  4. Une configuration DNS
  5. Des sauvegardes régulières de la base de données
  6. De la redondance avec une VM de secours

Docker Compose

  • Docker Compose est excellent pour le développement local
  • Il permet de gérer plusieurs services avec une seule commande
  • Il est moins utilisé en production
  • Il peut entraîner un temps d’arrêt pendant les mises à jour

Docker Compose Anywhere : un projet de week-end

  • Docker Compose Anywhere a été développé sur un week-end
  • Il offre les fonctionnalités suivantes :
    • Configuration en un clic d’un serveur Linux via GitHub Actions
    • Déploiements sans interruption avec GitHub Container Registry et Docker Rollout
    • Gestion des variables d’environnement et des secrets (avec réflexion autour de l’usage de age ou sops)
    • Sauvegardes Postgres automatisées via GitHub Actions
    • Prise en charge de plusieurs applications sur une VM unique
    • SSL automatique avec Traefik et Let's Encrypt

Quelques points à considérer

Pour la sécurité :

  • Définir des règles de pare-feu strictes (n’ouvrir que les ports nécessaires)
  • Sécuriser les clés SSH (sur AWS, préférence pour SSM ; sur GCP, préférence pour le CLI)
  • Utiliser un bastion host pour renforcer la sécurité
  • Protéger les secrets et envisager l’usage d’un WAF ou de Cloudflare

Protection des données :

  • Envoyer des sauvegardes chiffrées de la base de données vers un stockage cloud sécurisé (par exemple S3)
  • Créer régulièrement des snapshots disque pour une redondance supplémentaire
  • Mettre en place des politiques de rétention pour les sauvegardes et les snapshots

Récapitulatif GN⁺

  • Cet article souligne que les startups devraient éviter les infrastructures cloud complexes et se concentrer sur l’adéquation produit-marché avec une configuration simple
  • Il présente les avantages d’une configuration sur serveur unique et une méthode de déploiement simple avec Docker Compose
  • Il est important de ne pas gaspiller du temps dans la gestion d’une infrastructure complexe et de se concentrer sur le développement du produit principal
  • Des projets proposant des fonctionnalités similaires incluent Heroku et DigitalOcean

À lire aussi

1 commentaires

 
GN⁺ 2024-09-15
Commentaires sur Hacker News

  • Dans de nombreux projets, des équipes qui veulent utiliser les technologies les plus récentes produisent souvent des livrables de mauvaise qualité

    • Il existe des équipes encore peu mûres qui veulent utiliser Kubernetes sans le comprendre
    • Elles mettent en place des processus automatisés avec Puppet pour exécuter des services Docker sur différentes VM ou faire tourner un backend Python
    • Les startups dépensent beaucoup dans le cloud tout en produisant des résultats pires que ceux des pionniers du DevOps en 2017
    • Article de blog connexe : The Emperor's New clouds

  • Dans une petite startup, on fait tourner nginx, une webapp, postgres, redis, etc. sur une seule VM

    • Les développeurs peuvent travailler en local avec la même configuration, ce qui facilite le débogage
    • La montée en charge verticale est possible, ce qui convient bien aux premières phases

  • Un SaaS démarre sur un seul serveur puis s'étend à plusieurs serveurs

    • Une base de données distribuée est exploitée sans utiliser Kubernetes
    • Des serveurs bare metal plus puissants que les machines virtuelles des fournisseurs cloud sont utilisés
    • Les serveurs sont gérés avec ansible et terraform comme outils d'automatisation

  • Les fonctions clés de Kubernetes, comme les déploiements, les services de pods et les déploiements blue-green, sont utiles

    • Dans un environnement cloud native, l'utilisation de divers systèmes open source peut devenir complexe

  • Beaucoup de gens construisent une infrastructure complexe pour apprendre Kubernetes

    • Cela peut être utile lorsqu'il faut passer à l'échelle pour de gros clients
    • Cela peut être moins utile pour un fondateur ou un CTO

  • Même les livres sur les microservices recommandent de « construire d'abord un monolithe »

    • Au début, utiliser un monolithe facilite le débogage
    • Docker permet de simplifier les premières étapes
    • On passe à Kubernetes selon les besoins du business

  • Il n'est pas recommandé de choisir dès le départ un framework complexe

    • Utiliser ses propres outils n'est pas toujours plus efficace
    • Utiliser des outils standards peut être plus efficace à long terme

  • Dans le cloud, on n'utilise que des VM, du stockage bloc et blob, le DNS, un IdP et un registraire de domaines

    • Les services comme le FaaS sont complexes et difficiles à déboguer
    • Une seule VM et une base de code monolithique sont idéales

  • Un projet a tourné pendant 6 ans sur un seul VPS à 10 $/mois

    • La technologie des VPS a énormément progressé et offre une grande fiabilité
    • L'infrastructure cloud est utilisée pour les fonctions de collaboration et de gestion des opérations

  • Les solutions cloud sont préférées, mais de manière sélective

    • Google Cloud Platform (GCP) est utilisé pour réduire les coûts
    • Kubernetes n'est pas utilisé
    • Docker est utilisé pour simplifier le déploiement
    • Les services managés de GCP font gagner du temps