Brauchen Startups wirklich komplexe Cloud-Infrastruktur?
(hadijaveed.me)- Für frühe Startups kann es sinnvoller sein, Zeit in den Produktbau und die Suche nach Product-Market-Fit zu investieren, statt vom ersten Tag an Kubernetes oder Auto-Scaling aufzubauen
- 20–30 Lambda-Funktionen sowie über SQS und CloudWatch verteilte Logs machten Debugging, Änderungen und Deployments schwierig; mit einem einzelnen NodeJS-Container oder einer Flask-/FastAPI-App und Redis hätte sich das vereinfachen lassen
- In einem Beispiel mit 7 Microservices auf EKS, die CRUD und Business-Logik aufteilten, floss mehr Zeit in den Betrieb der Infrastruktur als in die Entwicklung von Features
- Auch eine einzelne VM kann mit Optionen wie EC2, GCP VM, Hetzner oder latitude.sh und Servern mit 40 GB RAM und mehreren Kernen genug Rechenleistung für frühe Dienste bieten
- Selbst bei einer einfachen Architektur braucht es für den produktiven Einsatz HTTPS, eingeschränktes SSH/SSM, CI/CD, DNS, Datenbank-Backups, eine Standby-VM, Disaster Recovery, Sicherheitsregeln und Aufbewahrungsrichtlinien für Backups
Wie in frühen Startups übermäßige Infrastruktur entsteht
- Pieter Levels wird als Beispiel genannt: Er betreibt mehrere Micro-SaaS auf einem einzelnen Server, vermeidet so die Komplexität von Cloud-Infrastruktur und konzentriert sich auf Product-Market-Fit
- Dieser Ansatz ist nicht für jedes Team die richtige Antwort, zeigt aber gut, wie Deployments und Infrastrukturverwaltung um der Komplexität willen komplex werden können
- Kleine Entwicklerteams nach dem MVP können zwar bei Deployments und Datenbankverwaltung auf Schwierigkeiten stoßen, aber nicht jedes Projekt braucht vom ersten Tag an Kubernetes, komplexe verteilte Systeme und Auto-Scaling
- Eine einfache Infrastruktur gibt Teams mehr Zeit, gute Produkte zu bauen und Markttauglichkeit zu finden
- Unternehmen im Enterprise-Maßstab haben zwar eigene Themen wie Compliance und große Belegschaften, doch frühe Startups müssen diese Komplexität nicht einfach übernehmen
Praxisbeispiele: Komplexität als Betriebsbelastung
-
Zu viele Lambdas
- Es gab 20–30 Lambda-Funktionen für verschiedene Services
- Auch SQS und mehrere Hintergrundjobs waren Lambda-basiert aufgebaut
- Logs waren über CloudWatch verstreut, was die Ursachenanalyse erschwerte
- Debugging war schmerzhaft, Änderungen umständlich, und selbst im Monorepo wurden Deployments kompliziert
- Mit einem einzelnen NodeJS-Container oder einer Python-Flask-/FastAPI-App sowie Redis-basierten Hintergrundjobs hätte sich das deutlich vereinfachen lassen
-
Zu viele Microservices
- Auf Kubernetes EKS liefen 7 kleine Microservices
- CRUD und Business-Logik waren in getrennte Services aufgeteilt
- Kubernetes ist mächtig, aber das Team verbrachte mehr Zeit mit Infrastruktur als mit Feature-Entwicklung
- Ob diese Service-Aufteilung bei dieser Größenordnung wirklich nötig war, bleibt fraglich
Warum ein einzelner Server ein realistischer Ansatz ist
- Eine Single-Server-Architektur nutzt die Leistung moderner VMs konsequent aus
- Bei Hetzner und latitude.sh gibt es leistungsstarke, budgetfreundliche VMs
- Auch GCP VMs und EC2 liegen preislich in einem vernünftigen Rahmen
- Ein Server mit 40 GB RAM und mehreren Kernen kann sinnvoller sein als mehrere verteilte Services, viele Lambdas oder zahlreiche ECS-Tasks
- Alles ist an einem Ort, was Betrieb und Verwaltung vereinfacht
- Skalierung auf Millionen QPS kann man angehen, wenn dieser Zeitpunkt tatsächlich kommt; dann gibt es wahrscheinlich auch ein Infrastruktur-Team
- Für einen stabilen Betrieb einer einzelnen VM braucht es grundlegende Betriebsmechanismen
- Eine robuste Maschine wie EC2, GCP VM oder Hetzner
- HTTPS fürs Web und sicheren Zugriff wie IP-beschränktes SSH oder SSM für Deployments
- CI/CD für Deployments ohne Downtime
- DNS-Konfiguration
- Regelmäßige Datenbank-Backups
- Eine Standby-VM für Redundanz
- Eine belastbare Disaster-Recovery-Strategie und eine getestete durchschnittliche Wiederherstellungszeit, was mit einer Backup-VM erreichbar ist
Docker Compose und Docker Compose Anywhere
- Docker Compose eignet sich in der lokalen Entwicklung gut, um mehrere Services mit einem einzigen Befehl zu verwalten, wird in Produktion aber seltener genutzt
- Es wird erwähnt, dass Docker Swarm deprecated ist
- Bei Updates kann es mit Docker Compose zu Downtime kommen
- Es gibt einen Leitfaden für Production-Deployments, und es braucht ein Gleichgewicht zwischen Einfachheit und Produktionsreife
- Docker Compose Anywhere ist ein Wochenendprojekt, das eine Single-VM-Konfiguration weiter vereinfachen soll
- Richtet Linux-Server per GitHub Actions mit einem Klick ein
- Unterstützt kontinuierliche Deployments ohne Downtime mit GitHub Container Registry und Docker Rollout
- Bietet Verwaltung von Umgebungsvariablen und Secrets; zur Verbesserung der Sicherheit werden age oder sops erwogen
- Bietet automatische Postgres-Backups auf Basis von GitHub Actions
- Unterstützt mehrere Apps auf einer einzelnen VM
- Automatisiert SSL mit Traefik und Let’s Encrypt
- Kann Next.js-, Go-, Python- und Node.js-Apps sowie weitere deployen
Sicherheits- und Betriebsprinzipien, auf die man auch bei Einfachheit nicht verzichten kann
- Sicherheit und Datenschutz dürfen auch in einer einfachen Architektur nicht weggelassen werden
- Es braucht strikte Firewall-Regeln, die nur notwendige Ports öffnen
- SSH-Schlüssel sollten sicher verwaltet werden; unter AWS wird SSM, unter GCP die CLI bevorzugt
- Zur Härtung der Sicherheit kann ein Bastion Host eingesetzt werden
- Secrets sollten geschützt und der Einsatz von WAF oder Cloudflare erwogen werden
- Verschlüsselte Datenbank-Backups sollten in S3 oder einen gleichwertig sicheren Cloud-Speicher übertragen werden
- Für zusätzliche Redundanz sollten regelmäßig Disk-Snapshots erstellt werden
- Für Backups und Snapshots sollten Aufbewahrungsrichtlinien umgesetzt werden
- Die Priorität von Engineers sollte darin liegen, die Einfachheit des Setups zu bewahren und sich auf das Kernprodukt zu konzentrieren
- Komplexe Setups, die Google Engineering oder große Unternehmen nachahmen, sowie neue Tools können die Aufmerksamkeit leicht ablenken
- Ob Startup oder nicht: Am wichtigsten ist es, mit Nutzern zu sprechen und Product-Market-Fit zu finden
1 Kommentare
Meinungen auf Hacker News
Ich habe bei mehreren Projekten wegen Hype-Technologien viel Blut, Schweiß und Tränen vergossen.
Obwohl die Teams klein waren, produzierten sie mit der Begründung, sie bräuchten „unbegrenzte Skalierbarkeit“, oft Ergebnisse von kaum zu glaubender Qualität; es kam auch vor, dass unreife Teams, die nicht einmal richtig verstanden, was LTS bedeutet, entschieden, sie bräuchten Kubernetes.
Heute habe ich schlanken Puppet-Code, mit dem ich bei jedem Anbieter eine gehärtete VM in der gewünschten Größe erstellen und darauf Docker-Services, ein Python-Backend oder das Serving statischer Dateien betreiben kann.
Ob eine Hetzner-VM 2 oder 48 Kerne hat: Innerhalb von 5 Minuten richte ich den Service ein, kontrolliere die Konfiguration über versionierte Manifeste und überwache mit eigenen Naemon-Plugins, ob die Konfiguration eingehalten wird.
Das ist ein vollständig reproduzierbarer Prozess, während Startup-Teams in der Cloud schneeflockenartige Einmalkonfigurationen bauen, jeden Monat Tausende Euro ausgeben und trotzdem schlechtere Ergebnisse liefern als DevOps-Pioniere im Jahr 2017.
Ich habe dazu auch einen Beitrag mit dem Titel The Emperor's New clouds geschrieben: https://logical.li/blog/emperors-new-clouds/
Die Frage „Wie reproduziert man Konfigurationen ohne Docker oder andere Technologien?“ habe ich nie verstanden.
Die Skripte waren deterministisch, die Dependency-Versionen waren festgepinnt, Konfiguration, Eingabeparameter und Ausführungsreihenfolge waren identisch, und alles lief auf deterministischen Rechensystemen.
Es gab keinen Grund, warum es nicht reproduzierbar sein sollte.
Statt zu sagen, dass Docker auf einer gehärteten VM läuft, kann man sagen, dass dort kubelet läuft, und statt mehrerer provisorischer „docker services“ kann man all diese VMs über eine k8s-Control-Plane mit sehr geringen Kosten steuern.
Ich sehe nicht, warum diese Methode besser sein soll; sie wirkt eher schlechter.
Schlechte Cloud-Infrastruktur ist, wenn man versucht, alles zu nutzen, was AWS verkauft, und die gesamte Infrastruktur dadurch an eine viel zu hohe Abstraktionsschicht gebunden wird, sodass sie nicht mehr auf eine andere Plattform migriert werden kann.
k8s ist etwas völlig anderes.
Wenn die Antwort auf auch nur einen dieser Punkte „selbst gebaut“ oder „dafür reicht ein Skript“ lautet, dann ist genau das der Grund, warum k8s wertvoll ist.
Bei einem Python-Backend kann man das Build-Skript direkt auf dem VPS reproduzieren:
pip install requirements.txt>python main.py>nano /etc/systemd/system/myservice.service>systemd start myservice> fertig.Zum Skalieren von Instanzen packt man diese Befehle in ein Bash-Skript
build_my_app.sh; das übernimmt dann die Rolle einer neuen Dockerfile und kann auf jedem Server in wenigen Dutzend Sekunden installieren.Wenn man sie als IaaS nutzt, kann man Prototypen deutlich schneller bauen als mit anderen Ansätzen, einschließlich VPS bei anderen Anbietern.
Besonders Google Cloud hat weniger Lock-in und passt besser zum Prinzip der geringsten Überraschung.
Nach dem Bau eines Prototyps sollte man sich allerdings fragen, ob man ihn an einem günstigeren Ort neu aufbauen will.
Dass man Festplatten nahezu unbegrenzt erweitern kann und Snapshots hat, ist gut; außerdem kann die Cloud einen Prototyp bis auf Produktionslast skalieren und so messen lassen, welche Größenordnung wirklich nötig ist.
Wenn man sich jedoch auf „Cloud-Magie“ wie Cloud Run oder Lambda verlässt, dauert das Lernen und Debuggen am Ende genauso lange wie mit der alten Methode.
In einem kleinen Startup machen wir es fast genau so
Es gibt zwar komplexere Teile wie automatische Skalierung von Job-Queues mit GPU-Anteil, aber der Kern ist eine einzelne VM mit nginx, Web-App, Postgres, Redis
Da es B2B ist, gibt es auch kaum Traffic
Entwickler können dieselbe Konfiguration unverändert auf Linux-Laptops oder in Linux-VMs auf anderen Plattformen ausführen, und wenn sie möchten, kann jeder für Demos oder Tests auch eine eigene Cloud-VM haben
Das Bootstrapping eines neuen Systems besteht im Wesentlichen daraus, SSH-Keys einzuchecken und ein Shell-Skript auszuführen
Debugging ist einfach, es ist weder komplex noch teuer, und bevor horizontale Skalierung nötig wird, kann man ziemlich weit vertikal skalieren
Es passt nicht für alle, aber vor der Seed-Phase halte ich es für völlig angemessen
Das ist eine zusätzliche Indirektionsstufe gegenüber dem Ansatz „Public Keys einchecken“, und Nutzer können ihre Keys austauschen, ohne eine Git-Änderung vorzunehmen
Außerdem weicht es zwar ziemlich von der ursprünglichen Beschreibung ab, aber das Leasen von SSH-Keys ist wirklich gut, weil es Offboarding-Situationen deutlich besser handhabt: https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
Beim Suchen nach dem Link habe ich auch Dokumentation gefunden, in der Vault behauptet, Einmalpasswörter bereitzustellen <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
Allerdings gehöre ich fest zum Lager „PasswordLogin no“, also sollte man das auf eigene Vorsicht verwenden
Postgres kann alles
Wie verfolgt man bei so einer Konfiguration die Konfiguration und Updates der VM?
Die Antwort lautet: „Nein, nicht wirklich“
Mein SaaS lief anfangs auf einem einzelnen Server, und nachdem wir Product-Market-Fit erreicht hatten, sind wir auf mehrere Server umgezogen
Das sind Bare-Metal-Server bei Hetzner; es gibt keine Microservices, und ich muss mich nicht mit Kubernetes befassen, betreibe aber eine verteilte Datenbank
Diese Bare-Metal-Server sind im Vergleich zu virtuellen Maschinen von Cloud-Anbietern enorm leistungsfähig
Vor ein paar Jahren habe ich das auch selbst gemessen: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
Insgesamt ist dieser Ansatz geradezu absurd effektiv
Man muss sich nicht mit Komplexität wie Kubernetes herumschlagen, vermeidet Kaskadenausfälle, die in komplexen Systemen zwangsläufig auftreten, und spart Entwicklungszeit, Wartung sowie monatliche Serverkosten
Der übliche Einwand lautet: „Aber wie skaliert man dann?“ — dabei weiß man noch gar nicht, ob man überhaupt skalieren muss, und mit solchen leistungsstarken Rechnern und einem vernünftigen Design kommt man schon mit 3–5 Servern sehr weit
Natürlich heißt das nicht, dass man sein Business im Wandschrank zu Hause betreiben sollte
Für die Serververwaltung braucht man weiterhin Automatisierung; ich verwende ansible und terraform
Sie befeuert den Optimismus, dass die Software in sehr kurzer Zeit riesigen Erfolg haben wird, und die Leute wollen das glauben
Ich weiß nicht, ob du den Artikel gelesen oder nur den Titel gesehen hast
Wenn du bis zum Abschnitt A few considerations weiter unten gehst, wird es schwer, darüber zu lachen
Diese „paar Überlegungen“ sind insbesondere dann ein beträchtlicher Block an Sicherheitsarbeit, wenn sehr sensible Informationen gespeichert oder übertragen werden
Wie geht man in so einer Situation mit Compliance-Anforderungen wie HIPAA um?
Es gibt zwei Arten von Programmierern
Die, die glauben, schon alles gesehen zu haben, und die, die wissen, dass sie fast nichts gesehen haben
Deshalb sind solche absoluten Aussagen ermüdend
Die entscheidenden 20 % von Kubernetes sind Deployments, Pods, Services, der Umgang mit Blue-Green-Deployments, deklarative Definitionen und die Trennung per Namespace, und das ist wirklich gut.
Wenn man sich nur an diese einfachen Grundlagen hält, einen verwalteten Kubernetes-Service in der Cloud nutzt und zustandsbehaftete Datenbanken außerhalb des Clusters belässt, wird daraus eine gute Erfahrung.
Probleme entstehen, wenn man in den „Cloud-native“-Kaninchenbau hineingezogen wird und anfängt, alle möglichen Nischen-Open-Source-Systeme, Operatoren, Ambassador, Sidecar-Patterns usw. zu verwenden.
Diese Dinge sind für Umgebungen gedacht, in denen mehrere unabhängige, aber miteinander verbundene Technikteams und verschiedene Programmiersprachen koexistieren.
Ich habe das Gefühl, dass Menschen in solchen Diskussionen oft über zwei unterschiedliche Dinge sprechen.
Für mich ist es nur eine einheitliche Deployment-Methode, besser als Docker Compose.
Für die Control Plane zahle ich nur sehr geringe Kosten, und die Worker sind normale VMs mit kubelet.
Für viele Leute scheint „Kubernetes“ aber den zweiten Absatz oben zu bedeuten.
Man muss es überhaupt nicht so verwenden.
Man kann einen k3s-Cluster einrichten und nur Workloads, Services und Ingress lernen.
Das ist alles, was man braucht, um provisorische VM- und Docker-Setups zu ersetzen.
99 % brauchen oder wollen nur etwas wie docker-compose++.
Zero-Downtime-Deployments als Standard und ein einfaches Konfigurationssystem für Replica Sets oder andere Replikations- und Verteilungsmechanismen – damit ist es fast erledigt.
Es wäre schön, etwas zu haben, das genau das macht.
Kubernetes bringt viel Ballast mit, und Docker Compose ist für wichtige Produktionsanforderungen ein wenig zu grundlegend.
Kubernetes hat gefühlt eine Million Knöpfe und Regler, mit denen es sich für jeden Zweck anpassen lässt, aber man kann sie genauso gut ignorieren und es einfach halten, indem man nur die Kernfunktionen nutzt.
Man kann sehr schnell ein Setup mit ordentlichen Deployments, sehr einfachen Logs und Metriken sowie guter Developer Experience aufbauen.
Weil sein Ruf so schlecht ist und ich es vorher noch nie benutzt hatte, habe ich mich auf das Schlimmste eingestellt, als ich fragte, ob ich einen Server für interne Tools einrichten dürfe.
Tatsächlich gab mir die Person, die es eingerichtet hatte, ein 30-minütiges Tutorial, erklärte mir die Konzepte insgesamt und gab mir genug Informationen, um den Server zu deployen; die Bereitstellung lief ohne Probleme.
Auch automatische Deployments per
git pusheinzurichten, war sehr schnell erledigt.Für mich wirkte es wie eine völlig naheliegende Wahl.
Wenn man nicht buchstäblich nur einen einzigen Service hat, ist es viel einfacher zu verwenden.
Allerdings habe ich es nicht selbst installiert; vielleicht kommt der schlechte Ruf also von diesem Teil.
Wenn k8s nicht im Lebenslauf steht, wie soll man dann einen neuen Job bekommen? :)
Im Ernst: Ich glaube, viele Leute wählen absichtlich den schwierigen Weg, um groß angelegte Infrastruktur zu lernen.
Ein weiterer häufiger Grund ist: „Wenn wir sehr viele Kunden bekommen, wird es viel einfacher“ oder „wir können je nach Nachfrage dynamisch skalieren“.
Für die Entwickler ist das alles plausibel, für Gründer oder professionelle CTOs aber nicht in gleichem Maße.
Manche Leute kümmern sich nicht um die Anforderungen und Zeitpläne potenzieller Kunden, sondern verbrennen Geld, während sie beeindruckend wirkenden Unsinn bauen.
Das ist ungefähr so, als würde man für einen Reifenwechsel in die Werkstatt fahren und der Mechaniker braucht drei Wochen, weil er wegen seines eigenen Entwicklungsdrangs Lowrider-Hydraulik und drehende Radkappen einbauen will.
Das Schlimmste ist, dass es für die nächste Person grundsätzlich unklar wird.
Man weiß nicht, ob etwas tatsächlich dort ist, weil es gebraucht wurde, oder ob es nur glitzernde Dekoration ist.
Ich bin mir nicht sicher, ob die Leute das aus Interesse machen, weil sie Technik mögen, oder ob sie, wie gesagt, technokratisch ihre Fähigkeiten hochziehen wollen, um k8s in den Lebenslauf zu schreiben.
Ich denke nur: „Das sieht schmerzhaft zu verwalten aus.“
Deshalb denke ich, dass k8s-Infrastruktur besser von einem engeren Kreis wirklich erfahrener Leute entworfen und bearbeitet wird – zumindest von erfahrenen Leuten, die Mentees anleiten können.
Und wenn sie nicht nötig ist, also bei den meisten Startups, kleinen Unternehmen und mittelgroßen Firmen, sollte man bei bestehenden Paradigmen bleiben, die einfacher zu nutzen sind.
Sie waren mit ihrer Wahl sehr zufrieden und haben ausführlich darüber gebloggt.
Das ist ein Fall, in dem „wenn wir sehr viele Kunden bekommen, wird es viel einfacher“ tatsächlich zutraf.
Eine alte und oft ermüdende Debatte, aber ich gebe trotzdem mal meine zwei Cent dazu
Ob man vom ersten Tag an ein komplexes Framework wählen sollte: vermutlich nicht, solange das Team nicht genug Erfahrung damit hat
Wogegen ich mich aber wehre, ist die Vorstellung, dass der Betrieb von Infrastruktur mit maßgeschneiderten Prozessen und Custom-Tools immer weniger Wartungsaufwand verursacht als bewährte Tools
Es ist die sture Ablehnung des Strohmanns „Komplexität“, obwohl die selbst gebauten Prozesse keineswegs einfach sind und viel Zeit vom Kernprodukt abziehen
Alle mögen die Einfachheit, ein Binary auf einen VPS zu kopieren und den Dienst neu zu starten
Aber bald braucht man Konfigurations- und Secret-Management, und wenn es wegen Verfügbarkeit und Redundanz mehrere Server werden, braucht man schrittweise Deployments, Load Balancing, Rollbacks usw.
Man wird auch eine Staging-Umgebung wollen, und dieser Workflow muss sich leicht replizieren lassen
Wenn das Team wächst, zeigt sich außerdem, dass man eine produktionsähnliche Umgebung lokal nicht betreiben kann
So kommen immer weitere Anforderungen hinzu
Am Ende muss man jede neue Anforderung auf seine eigene spezielle Weise lösen, statt sich auf Standardlösungen zu stützen, die andere längst erarbeitet haben
Später wird daraus ein Problem versunkener Kosten
Gibt man die Custom-Tools auf, die man kennt und versteht, und wechselt zu unbekannter „Komplexität“?
Je mehr man investiert, desto schwieriger wird der spätere Wechsel
Mein Vorschlag ist, von Anfang an Praktiken zu befolgen, die einen späteren Wechsel zu Standard-Tools erleichtern
Also etwa ab Tag 1 per Container deployen und die 12-Factor-Methodik übernehmen
Und wenn man wegen benötigter Funktionen ins Straucheln gerät, ist es besser, früher statt später auf bewährte Tools umzusteigen
Wahrscheinlich stellt man fest, dass die Angst vor dem Unbekannten unbegründet war, und langfristig verbringt man weniger Zeit mit Infrastruktur
Ein Ansatz, den ich erwogen habe, ist, vom ersten Tag an mit Standard-Tools, also k8s + gitops, zu starten, aber weiterhin auf einer einzelnen VM zu laufen
Was hältst du davon?
Dagegen findet man viele „Cloud Engineers“, die solche „komplexen“ Cloud-Systeme verstehen und sie mit terraform deployen und warten können
Das ist ein sofort einsetzbares Skillset
VM, Block- und Blob-Speicher, DNS, IdP, Domain-Registrar
Das ist ungefähr alles, was ich in der Cloud bequem genutzt habe
Sobald es zu FaaS und seinen Freunden geht, wird es für mich wirklich seltsam
Ich komme schwer damit klar, dass man nicht in die Maschinen hineinschauen kann, auf denen die Produktionsumgebung läuft
Das Debugging über Cloud-Dashboards ist eine miserable Erfahrung
Microsofts Ansatz halte ich noch für das, was tatsächlich „funktionieren“ dem am nächsten kommt, aber selbst der ist wirklich furchtbar, und ich möchte ihn nie wieder anfassen
Auch nach 10 Jahren ist meine ideale Architektur immer noch eine einzelne VM, auf der eine monolithische Codebase mit lokalen SQLite-Instanzen spricht
Das Aufkommen von NVMe-Speicher hat diesem Ansatz ziemlich viel Rückenwind gegeben
Backups erledigt man über Snapshots des Block-Storage, und Transaktionsdauerhaftigkeit bei Bedarf über WAL-Replikation
Dumm einfach
Es ermöglicht, sich auf das Geschäft und die Kunden zu konzentrieren
Kunden interessieren sich überhaupt nicht dafür und werden dafür auch nicht bezahlen
Jeder Code und jede Infrastruktur ist ein reiner Minusfaktor, deshalb sollte man so wenig wie möglich davon haben
Wenn Leute sagen, die Cloud sei teurer als On-Premises, ist das oft der Grund
Wenn man eine VM rund um die Uhr laufen lassen will, gibt es bessere Optionen
Selbst Bücher über Microservices sagen, man solle zuerst einen Monolithen bauen
Bevor man echte Nutzerreaktionen bekommt, weiß man nicht, wie man das System aufteilen sollte, und es ist einfacher, einen Monolithen aufzuteilen, als Services umzustrukturieren
Vielleicht muss man den Monolithen nie aufteilen
Auch Stripe hat am Ende Teile aus seinem Rails-Monolithen herausgelöst, aber der Monolith trägt erstaunlich weit
Es ist schwer, etwas zu finden, das leichter zu debuggen ist als ein Monolith wie Django/Rails
Allerdings hilft es, ein wenig vorauszuschauen, wohin die Infrastruktur gehen könnte
Die frühe Version unseres Unternehmens wurde als Django-Docker-Container auf einer einzelnen VM gebaut, und Deployments liefen manuell mit
docker pull; docker stop; docker startDiese Konfiguration hielt länger durch, als wir erwartet hatten
Docker ist eine gute Möglichkeit, Problemen beim Packaging von Abhängigkeiten auszuweichen
In der Anfangsphase können Dinge lästig sein wie die Frage, ob nach der Installation eines neuen DB-Treibers auf dem Server die nötigen C-Header-Dateien vorhanden sind oder ob die Konfiguration anders ist als auf dem Mac
Nach unserer Seed-Extension-Runde sind wir wegen geschäftlicher Anforderungen an Zuverlässigkeit und Skalierbarkeit auf k8s umgestiegen, und k8s hat uns gut bis zur Series B getragen
Weil wir alles dockerisiert hatten, war die Umstellung einfach, aber in der Frühphase haben wir Komplexität aggressiv reduziert
Und man sollte das Framework richtig nutzen, statt schlechte Versionen der Funktionen nachzubauen, die das Framework bereits bietet
In dieser Hinsicht erzielt eine erfahrene Person bessere Ergebnisse als zehn unerfahrene
Mit der Zeit summiert sich der Unterschied
Ich denke, die Hälfte der echten Gründe, warum Leute von Monolithen genug haben, liegt an schlechten und schlecht betriebenen Monolithen
Sie sagen, Daten sollten in eigenen Services gespeichert werden, und wenn man einen Multi-Paradigm-Ansatz wie relational plus Volltextsuche braucht, können daraus mehrere Services werden
Auch die User Experience sollte einen eigenen Service nutzen
Mindestens sollte dazwischen noch ein weiterer Service stehen, und normalerweise landen hier Django und Rails
Optional könnten zusätzliche Services für Dinge wie Authentifizierung oder Finanztransaktionen nötig sein
Ich habe ein Projekt etwa 6 Jahre lang auf einem einzigen 10-Dollar-VPS betrieben
Dank eines dauerhaften Rabatts von lowendtalk habe ich tatsächlich noch weniger bezahlt, und es war ein VPS-Anbieter mit Schwerpunkt auf Gameservern
Abgesehen von einem Ausfall über einen ganzen Tag, als ich die Konfiguration vermasselt hatte und eine saubere Neuinstallation des OS machen musste, und einem Fall, in dem der Anbieter nach Vorankündigung die IP-Adresse änderte, lag die Stabilität fast bei 99,999
VPS-Technik hat sich wirklich enorm weiterentwickelt und ist sehr stabil
Die Node-Disks sind als RAID 1 konfiguriert, und bei Node-Wartung lässt sich die VM selbst problemlos per Live-Migration auf eine andere Maschine verschieben
Snapshots kann man ebenfalls erstellen
Für mich wäre Cloud-Infrastruktur vermutlich nicht wegen höherer Stabilität die Wahl, sondern wegen Funktionen für Zusammenarbeit und Betriebsmanagement wie IAM, Secret-Management und Infrastructure as Code, oder wegen Datacenter-Compliance wie HIPAA
Kommt auf die Situation an
Persönlich mag ich Cloud-basierte Lösungen, weil sie viel Zeit sparen
Allerdings wähle ich sehr selektiv aus, was ich einsetze, und es gibt auch Lösungen, die so komplex sind, dass sie eindeutig kontraproduktiv sind
Ich betreibe ein kleines, gebootstrapptes Startup
Uns fehlt sogar das Geld, um uns selbst Gehälter zu zahlen, und ich verdiene meinen Lebensunterhalt mit Consulting nebenher
Da Budget und Zeit so begrenzt sind, müssen wir sehr sorgfältig entscheiden, was wir nutzen
Deshalb mag ich Dinge wie Google Cloud
Unsere GCP-Rechnung ist mit ein paar Hundert Euro im Monat ziemlich niedrig
Wir könnten zu einem günstigeren Anbieter wechseln, aber der Zeitaufwand wäre schwer zu rechtfertigen, und im Vergleich zu AWS, das ich früher genutzt habe, gefallen mir auch Googles UI und Tools
Für Kubernetes haben wir keine Verwendung
Allein die Kosten für den Betrieb eines leeren Clusters wären höher als unsere aktuelle monatliche GCP-Rechnung
Wir brauchen es auch nicht, weil wir nicht in die Microservices-Falle getappt sind
Docker mag ich dagegen
Es macht Software-Deployments idiotensicher einfach
Unsere Website ist ein Google-Storage-Bucket, der über einen Load Balancer und Google CDN ausgeliefert wird
Derselbe Load Balancer routet REST-Aufrufe an zwei VMs, auf denen der Monolith läuft
Diese VMs kommunizieren mit einer Managed DB, Managed Elasticsearch und Managed Redis
DB und Elasticsearch sind teuer, aber als Managed Services sparen sie viel Zeit und Aufwand
Das ist im Grunde alles, was wir haben, und es ist einfach und auch nicht so teuer
Wenn wir alles zu einem Anbieter wie Hetzner verschieben würden, könnten wir die Kosten vermutlich um etwa 50 % senken
Das könnte sich lohnen, ist für mich aber nicht besonders dringend
Wenn ich diese Managed Services verliere, wird mein Leben schwieriger
Außerdem scheinen einige Kunden AWS zu bevorzugen, daher müssen wir vielleicht eines Tages zu AWS zurück, und das spielt ebenfalls eine Rolle