Braucht Ihr Startup wirklich komplexe Cloud-Infrastruktur?

 (hadijaveed.me)
4 Punkte von GN⁺ 2024-09-15 | 1 Kommentare | Auf WhatsApp teilen

Braucht man wirklich komplexe Cloud-Infrastruktur?

  • Beim Hören von Pieter Levels im Lex Fridman Podcast habe ich viele Einsichten gewonnen
  • Pieter betreibt Anwendungen auf einem einzelnen Server und hat damit ein erfolgreiches Micro-SaaS-Business aufgebaut
  • Es ist wichtig, die Komplexität von Cloud-Infrastruktur zu vermeiden und sich auf Product-Market-Fit zu konzentrieren
  • Das gilt vielleicht nicht für jedes Startup, aber man sollte Komplexität um der Komplexität willen vermeiden

Jüngste Beobachtungen

Projekt 1: Lambda-Überlastung

  • Betrieb verschiedener Services mit 20–30 Lambda-Funktionen
  • Hintergrundjobs mit SQS und Lambda
  • Über CloudWatch verteilte Logs

Ergebnis: Debugging ist schwierig, Änderungen sind mühsam und Deployments sind kompliziert. Das hätte sich mit einem einzelnen NodeJS-Container oder einer Python-Flask-/FastAPI-App und Redis vereinfachen lassen.

Projekt 2: Microservices-Chaos

  • Betrieb von 7 kleinen Microservices auf Kubernetes (EKS)
  • Separate Services für CRUD und Business-Logik

Ergebnis: Es wurde mehr Zeit für das Infrastruktur-Management aufgewendet. Fraglich, ob diese Art der Trennung wirklich nötig war.

Die Stärke eines Single-Server-Setups

  • Moderne Server sind leistungsstark. Hetzner und latitude.sh bieten starke VMs zu günstigen Preisen an
  • Auch GCP-VMs und EC2-Instanzen sind preislich vernünftig
  • Sie bieten starke Rechenleistung mit 40 GB RAM und mehreren Kernen
  • Alles ist zentralisiert und dadurch einfach zu verwalten
  • Das Problem, auf Millionen QPS zu skalieren, kann man später lösen

Für ein Single-VM-Setup braucht man:

  1. Eine leistungsstarke Maschine (EC2, GCP VM, Hetzner usw.)
  2. Sicheren Zugriff (HTTPS, SSH mit IP-Beschränkung oder SSM)
  3. CI/CD für Zero-Downtime-Deployments
  4. DNS-Konfiguration
  5. Regelmäßige Datenbank-Backups
  6. Redundanz durch eine Standby-VM

Docker Compose

  • Docker Compose ist hervorragend für die lokale Entwicklung
  • Mehrere Services lassen sich mit einem einzigen Befehl verwalten
  • In Produktionsumgebungen wird es seltener eingesetzt
  • Während Updates kann es zu Downtime kommen

Docker Compose Anywhere: ein Wochenendprojekt

  • Docker Compose Anywhere wurde an einem Wochenende entwickelt
  • Es bietet folgende Funktionen:
    • One-Click-Setup für Linux-Server über GitHub Actions
    • Zero-Downtime-Deployments mit GitHub Container Registry und Docker Rollout
    • Verwaltung von Umgebungsvariablen und Secrets (unter Erwägung von age oder sops)
    • Automatisierte Postgres-Backups über GitHub Actions
    • Unterstützung mehrerer Apps auf einer einzelnen VM
    • Automatisches SSL mit Traefik und Let's Encrypt

Einige Überlegungen

Für die Sicherheit:

  • Strenge Firewall-Regeln setzen (nur notwendige Ports öffnen)
  • SSH-Keys absichern (bei AWS bevorzugt SSM, bei GCP die CLI)
  • Einen Bastion Host zur Härtung der Sicherheit verwenden
  • Secrets schützen und den Einsatz von WAF oder Cloudflare erwägen

Zum Datenschutz:

  • Verschlüsselte Datenbank-Backups in sicheren Cloud Storage übertragen (z. B. S3)
  • Regelmäßig Disk-Snapshots für zusätzliche Redundanz erstellen
  • Aufbewahrungsrichtlinien für Backups und Snapshots umsetzen

Zusammenfassung von GN⁺

  • Dieser Beitrag betont, dass Startups komplexe Cloud-Infrastruktur vermeiden und sich mit einfachen Setups auf den Product-Market-Fit konzentrieren sollten
  • Er stellt die Vorteile eines Single-Server-Setups und einfache Deployment-Methoden mit Docker Compose vor
  • Wichtig ist, keine Zeit mit komplexem Infrastruktur-Management zu verschwenden, sondern sich auf die Entwicklung des Kernprodukts zu konzentrieren
  • Ähnliche Projekte mit vergleichbaren Funktionen sind etwa Heroku und DigitalOcean

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-15
Hacker-News-Kommentare

  • In vielen Projekten versuchen Teams, die neuesten Technologien einzusetzen, und liefern dabei oft Ergebnisse von geringer Qualität

    • Es gibt unausgereifte Teams, die Kubernetes verwenden wollen, ohne es wirklich zu verstehen
    • Mit Puppet werden automatisierte Prozesse aufgebaut, um Docker-Dienste auf verschiedenen VMs auszuführen oder Python-Backends zu betreiben
    • Startups geben in der Cloud viel Geld aus und liefern dennoch schlechtere Ergebnisse als die DevOps-Pioniere von 2017
    • Zugehöriger Blogbeitrag: The Emperor's New clouds

  • In einem kleinen Startup wird eine einzelne VM genutzt, um nginx, webapp, postgres, redis usw. zu betreiben

    • Entwickler können lokal mit derselben Konfiguration arbeiten, was das Debugging erleichtert
    • Vertikale Skalierung ist möglich und für die Frühphase geeignet

  • Ein SaaS wurde auf einem einzelnen Server gestartet und dann auf mehrere Server skaliert

    • Eine verteilte Datenbank wird auch ohne Kubernetes betrieben
    • Es werden leistungsfähigere Bare-Metal-Server statt virtueller Maschinen des Cloud-Anbieters verwendet
    • Zur Serververwaltung werden ansible und terraform als Automatisierungstools genutzt

  • Die Kernfunktionen von Kubernetes wie Deployments, Pod-Services und Blue-Green-Deployments sind nützlich

    • In einer Cloud-Native-Umgebung kann die Nutzung verschiedener Open-Source-Systeme komplex werden

  • Viele bauen komplexe Infrastrukturen auf, um Kubernetes zu lernen

    • Für die Skalierung auf große Kunden kann das nützlich sein
    • Für Gründer oder CTOs ist es möglicherweise weniger nützlich

  • Selbst in Büchern über Microservices wird empfohlen: "Baue zuerst einen Monolithen"

    • Am Anfang ist ein Monolith beim Debugging einfacher
    • Docker vereinfacht die Anfangsphase
    • Je nach geschäftlichem Bedarf wird später zu Kubernetes gewechselt

  • Es ist nicht empfehlenswert, sich von Anfang an für komplexe Frameworks zu entscheiden

    • Eigene Tools zu verwenden ist nicht immer effizienter
    • Standard-Tools zu verwenden kann langfristig effizienter sein

  • In der Cloud werden nur VM, Block- und Blob-Storage, DNS, IdP und Domain-Registrar genutzt

    • Dienste wie FaaS sind komplex und schwer zu debuggen
    • Eine einzelne VM und eine monolithische Codebasis sind ideal

  • Ein Projekt wurde 6 Jahre lang auf einem einzelnen VPS für 10 $/Monat betrieben

    • Die VPS-Technologie hat sich stark weiterentwickelt und ist sehr zuverlässig
    • Cloud-Infrastruktur wird für Zusammenarbeit und Betriebsmanagement-Funktionen genutzt

  • Cloud-basierte Lösungen werden bevorzugt, aber selektiv eingesetzt

    • Mit Google Cloud Platform (GCP) werden Kosten gesenkt
    • Kubernetes wird nicht verwendet
    • Mit Docker werden Deployments vereinfacht
    • Die Managed Services von GCP sparen Zeit