Verwende einen großen Server (2022)

• Der Kern der Debatte ist nicht Monolith vs. Microservices, sondern die Frage, ob verteilte Systeme den Entwicklungs-/Betriebs-Overhead wert sind
• Moderne Einzelserver verfügen mit Dutzenden bis Hunderten Kernen, TB-klassigem Speicher und Dutzenden bis Hunderten Gbps I/O über mehr als genug Leistungsreserven für die meisten Webdienste
• Reale Benchmarks zeigen, dass ein einzelner Server leistungsstarke Verarbeitung bewältigen kann, etwa Nginx mit 500.000 RPS, PostgreSQL mit 70.000 IOPS, NoSQL mit 1 Million IOPS, 4K-Encoding mit 75 FPS
• Die Cloud bietet Komfort und Verfügbarkeit, verlangt dafür aber einen erheblichen Kostenaufschlag, sodass die Investitionsrendite genau geprüft werden sollte
• Nur bei extrem schwankenden Nutzungsmustern bieten Cloud-native- oder Serverless-Architekturen echte Kostenvorteile
• Allerdings ist der Kostenaufschlag von Serverless-/Micro-VM-Konfigurationen hoch; bei kontinuierlicher/vorhersehbarer Last ist vertikale Skalierung wirtschaftlicher
• Verfügbarkeit lässt sich weitgehend durch Primär-/Sekundär-Redundanz (oder 2×2) und unterschiedliche Hardware-Kombinationen lösen; sinnvoll ist eine Strategie, bei der nur CDN und Backups verteilt eingekauft werden

---

Überblick: Der Wert von „einem großen Server“ statt verteilter Systeme

• Im Kern der Debatte „Monolith vs. Microservices“ steht die Frage, ob die Einführung verteilter Systeme den realen Aufwand an Entwicklerzeit und Kosten rechtfertigt
• Moderne Software läuft auf Servervirtualisierung und verschiedenen Abstraktionsschichten; auch „Serverless“ oder „Bare Metal“ basieren letztlich auf physischen Serverressourcen
• Heutige Server bieten eine weit höhere Kosten-Effizienz pro Leistung, als viele annehmen
  • Im Vergleich zu früher sind Serverspezifikationen bei Kernzahl, Speicherbandbreite, PCIe-Lanes und NVMe-Storage sprunghaft gestiegen, sodass viele Dienste ihre Ziel-QPS auch ohne Verteilung erreichen können

Die starke Leistung moderner Serverhardware

• Ein Beispielserver von Microsoft Azure nutzt zwei AMD-Server-CPUs der 3. Generation mit insgesamt 128 Kernen und 256 Threads
• Ein einzelner Server erreicht eine Rechenleistung von rund 4 TFLOPs und übertrifft damit Supercomputer aus den frühen 2000er Jahren
• Mit 16 DDR4-3200-RAM-Slots pro Sockel ist eine Erweiterung auf bis zu 8 TB Speicher möglich; auch im praktischen Einkauf sind 1 TB RAM verfügbar
• Insgesamt stehen 128 PCIe-Gen4-Lanes zur Verfügung; mit 30 NVMe-SSDs und Netzwerkkarten mit 50–100 Gbps sind leistungsstarke Storage- und Netzwerkverbindungen möglich

Was mit einem solchen Einzelserver möglich ist (laut Benchmarks)

• 400–800 Gbps Videoübertragung, NoSQL mit 1 Million IOPS, PostgreSQL mit 70.000 IOPS, Nginx mit 500.000 RPS sind erreichbar
• Auch bei CPU-, Speicher- und I/O-intensiven Aufgaben wie einem Linux-Kernel-Build in 20 Sekunden oder x264-4K-Encoding mit 75 FPS zeigt sich hoher Durchsatz

Vergleich der Miet- und Kaufkosten von Servern

• OVHCloud: Ein Server mit 128 Kernen/512 GB RAM kann für etwa $1.318 pro Monat gemietet werden
• Hetzner: Ein Server mit 32 Kernen/128 GB RAM wird für 140 € pro Monat angeboten; je nach Größe variiert die Preisstruktur
• AWS m6a.metal: Ein Server mit 96 physischen Kernen/768 GB RAM kostet $8,29 pro Stunde, also etwa $6.055 pro Monat; der Cloud-Aufschlag ist erheblich
• Ein Server mit ähnlicher Ausstattung kostet bei Dell beim Direktkauf etwa $40.000; gegenüber der Cloud kann sich die Investition in rund 8 Monaten amortisieren
• Für dieselbe Verarbeitungskapazität wird bei Serverless ein Kostenaufschlag von schätzungsweise 5,5× gegenüber Instanzen und 25× gegenüber günstigem Hosting fällig

Warum verteilte Systeme populär wurden

• Früher (um 2010) machten die Grenzen von CPU-, Speicher- und Storage-Leistung es für große Dienste notwendig, mehrere Server zu kombinieren
• Durch große Einzelserver, NVMe-SSDs und hohe Speicherbandbreite hat sich die Leistungsgrenze eines einzelnen Knotens zuletzt stark erhöht; VMs und Container sind jedoch weiterhin meist auf kleine Serverressourcen ausgelegt

Wann ein einzelner großer Server ausreicht

• Die meisten Webdienste mit bis zu 10k QPS kommen mit einem einzigen Server aus; einfache Dienste können sogar bis in den Bereich von einer Million QPS reichen
• Selbst bei Videostreaming ist die Control Plane auf einem Einzelserver realistisch; anhand von Benchmarks und allgemeinen Leistungstabellen lässt sich die passende Servergröße abschätzen
• Abgesehen von Sonderfällen genügt für Verfügbarkeit meist bereits eine Konfiguration aus Hauptserver und Backup-Server

Lieber „höher“ als „breiter“: wenige große statt vieler kleiner Server

• Selbst wenn ein Cluster nötig ist, verursachen wenige große Server geringeren Koordinations-Overhead (O(n)) als viele kleine Server
  • Langfristig ist es also oft effizienter, die Zahl der Server zu reduzieren und deren Ausstattung zu erhöhen
• Bei Serverless und kurzlebigen Container-Umgebungen fällt dieser Overhead besonders stark ins Gewicht
• Der Nachteil ist der Single Point of Failure, doch dieser lässt sich bereits mit Primär-/Sekundärbetrieb (in unterschiedlichen DCs) weitgehend entschärfen
• Noch robuster ist eine 2×2-Konfiguration (2 Server im Primär-DC + 2 Server im Sekundär-DC) in Verbindung mit unterschiedlicher Hardware bzw. unterschiedlichen Fertigungsserien, um korrelierte Ausfälle zu vermeiden
• Beim Mieten lässt sich durch Diversifizierung der Servermodelle das Risiko von Kettenausfällen identischer Festplatten oder SSDs verringern

Vorteile und Grenzen der Cloud

• Die Cloud punktet bei Verfügbarkeit, Wiederherstellungsgeschwindigkeit und operativem Komfort; dafür kann ein Premiumpreis gerechtfertigt sein
  • Systeme lassen sich innerhalb des Kostenrahmens schnell neu starten, ohne längere Ausfälle, und können einen großen, gitterartig verwalteten Ressourcenpool nutzen
  • Mietserver-Anbieter sind günstiger, haben aber oft Grenzen bei Qualität, Netzwerk und Premium-Support
• Cloud-Vertrieb empfiehlt jedoch oft anbietergebundene Architekturen wie Auto-Scaling-VMs, Serverless oder gemanagte HA-Datenbanken; daher sollten Kosten und Komplexität kritisch beobachtet werden
• Großflächige Traffic-Verarbeitung an sich ist nicht der Hauptgrund für Cloud-native-Architekturen; viele Beispiele zeigen, dass auch ein einzelner großer Server mehrere Millionen gleichzeitige Nutzer bedienen kann

Kosten von Spitzenlasten und das Kriterium burstiger Last

• Irgendjemand muss Kapazität für Spitzenlast bereitstellen; deshalb wird die Spitzenlast am Ende irgendwo in der Lieferkette berechnet
• Für burstige, kurzfristige Jobs (z. B. einmalige groß angelegte Simulationen) sind Serverless/Auto-Scaling wirtschaftlich, bei kontinuierlicher, vorhersehbarer Last ist der feste Betrieb großer Server kosteneffizienter
• Mit 1-Jahres-Verträgen/Spot-Instanzen/Preisverhandlungen lassen sich Instanzkosten weiter senken, wodurch der Aufschlag gegenüber Serverless noch größer wird

Quantitative Bewertung des „Cloud-Premium“

• Serverless Computing wie AWS Lambda kann gegenüber einem gleichwertigen Server einen Kostenaufschlag von 5- bis 30-fach verursachen
• Annahme: Ein Server für $8,2944/Stunde liefert 1k QPS und 768 GB RAM; wird derselbe Durchsatz durch Lambda ersetzt, kostet das etwa $46/Stunde, also ein 5,5-facher Aufschlag
• Gegenüber OVH-Mietservern wird ein Aufschlag von 25× geschätzt; schon bei 5 % Auslastung ist günstiges Hosting wirtschaftlicher als Serverless
  • Mit Langzeitverträgen, Spot-Instanzen usw. kann die Differenz noch weiter steigen
• Auch bei abweichender QPS bleibt der Aufschlagsfaktor über die Umrechnung in Speicher-Zeit ähnlich; entscheidend ist die Skalierung des Servers passend zur Workload-Größe

Häufige Gegenargumente und Missverständnisse

• „In der Cloud braucht man kein Betriebspersonal mehr“: Geändert hat sich oft nur die Rollenbezeichnung zu Cloud Ops; weiterhin sind Fähigkeiten für Dokumentation, Änderungsverfolgung und Reaktion auf Deprecations nötig, was die Personalkosten eher erhöht
• „In der Cloud sind keine Sicherheitsupdates mehr nötig“: Ein Teil davon entfällt, aber nur in leicht automatisierbaren Bereichen; Library-Audits und Konfigurationsprüfung bleiben weiterhin notwendig
• „Cloud heißt automatisch Hochverfügbarkeit“: Mehr Komplexität schafft neue Schwachstellen, und selbst Region-/Provider-Redundanz beseitigt korrelierte Ausfälle nicht vollständig
• „In der Cloud entwickelt man schneller“: Die anfängliche Agilität ist ein Vorteil, sollte aber mit Blick auf den Kosten-Kipppunkt überwacht werden, um rechtzeitig umzusteigen
• „Unser Traffic ist sehr burstig“: In diesem Fall sind Serverless und Auto-Scaling passend
• „Und was ist mit CDN?“: Geringere Latenz und Bandbreitenersparnis sind ein zwingender Fall für eingekaufte Verteilung; Gleiches gilt für Backups, die ebenfalls sinnvoll extern bezogen werden

Monolith vs. Microservices und die Serverstruktur

• Ein „großer Server“ wird oft mit einer monolithischen Architektur verbunden, doch auch mehrere Microservices in Containern auf einem einzigen Server sind möglich
  • Allerdings fallen Interprozesskommunikation, Deployment und Observability-Overhead selbst auf einem einzelnen Host ins Gewicht, sodass der reale Performancegewinn im Verhältnis zur Komplexität deutlich sinkt
• Für frühe Phasen und kleine bis mittlere Größenordnungen sind Monolithen oder wenige Services im Hinblick auf operative Einfachheit vorteilhafter

Fazit

• In den meisten Fällen ist vertikale Skalierung (ein großer Server) einfacher und wirtschaftlicher als horizontale Skalierung oder eine cloudzentrierte Architektur
• In Kombination mit Primär-/Sekundär-Redundanz, heterogener Hardware und ausgelagerten CDN-/Backup-Lösungen lässt sich praxisgerechte Zuverlässigkeit erreichen; bei kontinuierlicher Last ist der Vorteil bei den Total Cost of Ownership (TCO) groß
• Wenn eine robuste Strategie zur Hardware-Redundanz vorhanden ist, ist der Ansatz „ein großer Server“ für reale Dienste eine sehr geeignete Wahl

[GN⁺]

Hacker-News-Kommentare

• Eines der größten Probleme der Cloud-Kosten („Cloud Tax“) ist, dass sie den Bereich der Lösungen, über die Ingenieure nachdenken können, künstlich einschränken. Wenn man zum Beispiel etwa 200 $/Monat an AWS zahlt, bekommt man einen Server mit 4 vCPU und 16 GB RAM — das entspricht ungefähr einem Entwickler-Laptop von vor fünf Jahren. Bei Hetzner kann man für denselben Preis dagegen einen Server mit 48 Kernen und 128 GB RAM mieten. Der Unterschied bei der Rechenleistung ist enorm. Mit einer zehnmal größeren Kapazität werden Vorgehensweisen praktikabel, die auf kleinen Nodes keinen Sinn ergeben. Solche Bedingungen sparen manchmal auch Engineering-Zeit, die sonst in komplexere Systeme fließen würde. Natürlich gibt es noch andere Überlegungen wie Haltbarkeit, aber umgekehrt garantieren dedizierte Server auch konstante Leistung ohne Sorgen über noisy neighbors
  • 2025 kann man für allgemeine Zwecke Services wie fly.io ohne viel Komplexität oder umständliche Abläufe nutzen, und für bestimmte Frameworks gibt es Optionen wie Vercel (gute Angebote, die auf einen bestimmten Stack spezialisiert sind). Wenn man mehr braucht, kann man bei OVH/Hetzner/Latitude echte Monster-Maschinen günstig mieten. Für den bloßen Betrieb eines Blogs gibt es ohnehin massenhaft VPS-Angebote. Die traditionelle Cloud wird inzwischen nur noch für Regulierung, interne Prozesse oder Ineffizienz genutzt. Sowohl Entwicklerproduktivität als auch Maschinenkosten sind dort aus meiner Sicht null. Es sei denn, ein Team ohne jegliche Einschränkungen mag DMV-artige Freigabesysteme, laute Intel-Nodes, teure Margen und miserablen Support — dann ergibt das für die meisten keinen Sinn
  • Das geht noch weiter — mit Bare-Metal-Servern braucht man keine Netzwerklatenz, keine Verzögerungen/Konkurrenz bei der Speicherbandbreite von VMs und keine separate Caching-Struktur. Man kann Postgres zum Beispiel einfach mit sehr viel RAM versorgen und nur Linux-Disk-Caching verwenden. Viel einfacher und schneller
  • Ich verstehe nicht, warum man selbst für kleine Services reflexartig AWS nehmen muss. Ich habe es nicht in der von dir beschriebenen Komplexität erlebt, aber ein Kunde nutzte für eine kleine PHP-Web-App plus AWS-Server/SQS/S3-Kombination 100 $/Monat. Ich habe das mit Python/Django/PostgreSQL (anfangs SQLite) umgesetzt und auf einen VPS für 25 $/Monat umgezogen. PDF-OCR, Preisupdates, das Auffinden fehlender Produkte und der Site-Betrieb laufen alle problemlos auf 4 Kernen und 6 GB RAM. Es ist eine interne App, die niemals weit über 100 Nutzer hinausgehen wird, und selbst wenn sie irgendwann wächst, wäre die Migration sehr einfach. Auf dem aktuellen Niveau gibt es keinen Grund für einen AWS-Server für 100 $, jedenfalls nicht bevor man wirklich massiv skaliert
  • Stimme voll zu. Wenn man eine eingebettete Datenbank wie sqlite nutzt und Schreibvorgänge (Batches) optimiert, kommt man selbst mit Hetzner extrem weit. Das Argument „man reserviert übermäßig viel Kapazität und verschwendet sie“ ergibt außerhalb von AWS keinen Sinn mehr (das Preis-Leistungs-Verhältnis ist unvergleichlich). Je komplexer ein System ist, desto eher sinken Zuverlässigkeit und Resilienz im Vergleich zu einem einzelnen Node. Es ist fast nie so, dass nur eine Sache isoliert ausfällt
  • Ich sehe es eher genau andersherum. Ich finde Hetzner großartig für kleine Websites, aber bei großen Projekten fühlt sich die Cloud praktisch ohne Einschränkungen an. Wenn es ein Projekt ist, bei dem meine Zeit wertvoll genug ist, sind Hosting-Kosten von 200 $ oder 2000 $ bedeutungslos. Ich sehe auch keinen großen Unterschied im Entwicklungsaufwand zwischen AWS CDK/Terraform+GitHub Actions und Docker/K8s/Ansible+CI-Pipeline. Ich hatte nie das Gefühl, dass Bare Metal wesentlich mehr Engineering-Zeit spart. IaC mit Fargate+RDS ist ebenfalls bequem. Wenn man wirklich separate, skalierbare und haltbare File-Storage-Lösungen braucht oder Dinge wie dynamische Erstellung von Subdomains und die Integration mehrerer dedizierter Services auf verschiedenen Infrastruktur-Ebenen, ist der Aufwand für Lernen und Integration neuer Services eher noch größer. Ich mache so etwas tatsächlich schon seit der Zeit vor der Cloud, und bei umsatzgenerierenden Projekten halte ich Cloud-Kosten für eine lohnende Investition. Wenn ein Projekt durch diese Kosten zu stark belastet wird, ist es eher ein Hobby als ein Business. RAID oder verschiedene Cluster-Dateisysteme zu verwalten, möchte ich mit den Ressourcen der meisten Startups/Firmen oder mit meiner Zeit nicht. Es fühlt sich an wie der Unterschied zwischen Leuten, die gern an Arch+Emacs herumbasteln, und Leuten, die mit einem MacBook zufrieden sind. Wer den Kernel-Scheduler ändern will, soll Arch nutzen — allen anderen würde ich ein MacBook empfehlen. Gleichzeitig habe ich aber auch erlebt, dass dedizierte Server genau richtig waren, wenn echtes Raw Throughput bei sehr kleinem Budget wichtig war (das sparte Tausende Dollar). Wenn es erfolgreich geworden wäre, hätten wir danach vermutlich vertikal skaliert — aber das ist ein seltener Fall
• HN (Hacker News) betreibt zwei Server: einen für den Live-Betrieb und einen Backup-Server. Das ist ein nützliches Muster, weil man bei Hardware-Problemen oder nötigen Upgrades sofort ein Failover machen kann. Man muss aber aufpassen, dass nicht beide gleichzeitig ausfallen, wenn sie vollständige Klone voneinander sind
  • Nicht so katastrophal wie bei SSDs, aber auch bei AMD-CPUs gab es einen interessanten Fehler. Nach ungefähr 1044 Tagen blieb ein bestimmter Kern komplett hängen. Beispiel für einen AMD-EPYC-Rome-CPU-Hang
  • Ich frage mich, ob es Statistiken zu den Downtimes von HN (Hacker News) gibt. Ich erinnere mich in den letzten zehn Jahren nur an ein oder zwei Ausfälle, gefühlt liegt die Uptime bei über 99,99 %
• Ich nutze seit über zehn Jahren ein Hybridmodell aus Colocation und Public Cloud, und ab einer gewissen Größe war das immer die beste Lösung für Kostenoptimierung. Auch die Hardware-Effizienz wird kontinuierlich besser. Man braucht Netzwerk-/Infrastruktur-Administratoren, aber in Wahrheit ist das heute sehr leicht zu verwalten, und „Cloud“-Administratoren braucht man im Grunde ebenfalls, sodass es beim Personal kaum Einsparungen gibt. Es gibt viele Colocation-Optionen, und Anbieter bündeln Bandbreite. Ich habe einmal 8 Dell-VRTX-Cluster, SAN und über 500 VMs betrieben (von großem msSQL bis kube); in der Public Cloud wäre die Rechnung selbst mit Reservierungsrabatten sechsstellig gewesen. Die Colocation-Kosten lagen dagegen bei 2.400 $/Monat (hauptsächlich Strom). Auch die deutlich geringere Geschwindigkeit von Public-Cloud-Nodes überrascht immer wieder (selbst bei derselben CPU/vCPU-Generation). Man muss natürlich gute Geräte-Deals, Updates, Lizenzen und Supportverträge im Blick haben, aber realistisch ist das gut beherrschbar. Außerdem lassen sich Cloud und Networking inzwischen leicht verbinden: Glasfaseranschluss legen lassen und mit dem VPC verbinden, fertig
  • Ich verstehe Colocation so, dass man eigene Hardware kauft und im Rechenzentrum nur Strom/Rack/Leitung mietet. Ich wüsste gern, ob das wirklich so ist und was gegenüber gewöhnlichem Bare-Metal-Server-Mietmodell die Vorteile sind
• Ich diskutiere dieses Thema seit Jahren mit Freunden. Der größte Nachteil lokaler Infrastruktur ist, dass man Fachleute braucht, die sie richtig betreiben. Der Artikel konzentriert sich auf das obere Ende der Skala, aber im unteren Markt amortisiert sich ein kleines Rack oder etwas Networking oft schon nach einem Jahr, wenn man bereits etwas Equipment hat. Angesichts der heutigen Cloud-Aufschläge wäre lokale Infrastruktur wahrscheinlich sogar wirtschaftlicher, selbst wenn man einen Administrator zusätzlich einstellt
• In einem Unternehmen, an dessen Gründung ich beteiligt war, haben wir eine Enterprise-Automation-Engine gebaut, und das Team wollte die Lösung als SaaS ausrollen, um den Umsatz zu maximieren. Tatsächlich hätte eine Multi-Tenant-DB-Struktur plus VPS völlig gereicht, aber das Team war darauf fixiert, Kubernetes zu lernen und einen Cloud-native-Stack aufzubauen, und verbrachte ein Jahr damit, Entwicklungsumgebung und Betriebsautomatisierung zu entwickeln. Am Ende ging das Unternehmen recht schnell unter
  • Aber die Ingenieure konnten mit dieser Erfahrung dann Kubernetes in ihren Lebenslauf schreiben und sich damit neue Jobs suchen
  • Bei mir ähnlich — ich habe viel zu viel Zeit damit verschwendet, Probleme im Voraus zu lösen, die vielleicht erst in fünf Jahren relevant geworden wären. Für die meisten Projekte und frühen Startups reicht einfach PaaS oder nginx+Docker-Container. Wenn irgendwann echter Schmerz entsteht, kann man sich dann darum kümmern
  • Deshalb mag ich einfach PaaS, bis „die Rechnung wirklich weh tut“. Heroku/Render/fly bezahlen und sich auf PMF (Product-Market Fit) konzentrieren. Oder man investiert aus Spaß an Servern in K8s, verbrennt VC-Geld und wechselt dann wiederholt zum nächsten Job
• Viele Unternehmen sind gar nicht so wichtig. Viele stressen sich damit, was passiert, wenn der Betrieb ausfällt, aber die von ihnen betriebenen Services sind in Wahrheit nicht derart kritisch. Wenn die Produktionsumgebung tagsüber ausfällt, ist das unangenehm, aber die Welt geht nicht unter. Solche Firmen haben Budgets explodieren lassen, obwohl früher ein einfacher Office-Server problemlos 250 Personen getragen hat. Die Cloud ist für bestimmte Aufgaben hervorragend, aber vieles andere ist eher Marketing-Übertreibung. Viele Ingenieure neigen allerdings dazu, von „perfekter Skalierbarkeit“ besessen zu sein und nach idealen Architekturen zu suchen, statt nach Lösungen, die einfach gut genug sind
  • Ein früherer Teamkollege von mir sagte bei der Arbeit immer: „Zumindest stirbt niemand, wenn wir einen Fehler machen, also müssen wir uns nicht zu viele Sorgen machen.“ Er hatte schon in Bereichen mit viel größerer Verantwortung gearbeitet, und diese Haltung hat in schwierigen Situationen sehr geholfen
• Wenn man komplexe Strukturen mit dem Ziel von 100 % Verfügbarkeit baut, macht man oft Fehler, die die Zuverlässigkeit am Ende senken. Die meisten Unternehmen können in Wahrheit gelegentliche ein bis zwei Stunden Ausfall oder sogar Datenverlust verkraften. Wenn man diese Erwartung vorher klar kommuniziert, kann man viel einfacher und am Ende zuverlässiger entwickeln
  • Es ist auch deutlich billiger. Allerdings werden solche Erwartungen von nichttechnischen Führungskräften oft nicht akzeptiert (insbesondere Datenverlust ist fast nie tolerierbar). Ingenieure sagen zwar, sie verwalten nur die Umgebung, aber in der Realität ist das schwer durchzuhalten, und wenn etwas schiefgeht, wirkt man schnell inkompetent
• Ein ziemlich guter Artikel. Wenn man auf diese Weise (außerhalb der Cloud) skaliert, sollte man auch das Hinzufügen eines CDN erwägen. Ein CDN bringt außerdem WAF- und DNS-Failover-Effekte mit. Etwas schade ist bei einem Nicht-Cloud-Ansatz, dass man die Datenbank selbst betreiben muss. Deshalb kann man Anbieter in Betracht ziehen, die Cloud-Datenbanken als Option anbieten, oder bei einer Active/Passive-Struktur den passiven Node günstiger als Cloud-VM+Autoscaling betreiben. Servermieten sind heute wirklich billig: 4-GB-VPS für etwa 6 $, 32-GB-Quad-Core-Bare-Metal schon um 90 $. Preisvergleichsseiten wie serversearcher.com sind dafür nützlich
  • Ich habe Postgres in einem Docker-Container betrieben und einfach regelmäßig Backups gemacht; das war völlig problemlos. Der Betrieb ist simpel, es gibt eigentlich nichts, worüber man sich beschweren müsste
  • Auf einer einzelnen Maschine bekommt man mit sqlite viel höhere Performance und einfachere Verwaltung als mit Postgres/MySQL
• Ich betreibe meine Services ebenfalls auf VPS. Die Cloud habe ich schon vor langer Zeit aufgegeben. Wenn meine Projekte anfangen, Geld zu verdienen, will ich Hardware kaufen und in Colocation stellen. Die Cloud war für mich wie eine Dating-App — inzwischen ist der Spaß vorbei, und ich will lieber etwas wirklich Produktives machen
  • Auch Colocation ist voller Probleme. Dass durch Stromausfälle im Rechenzentrum Hardware stirbt, ist wirklich häufig. Paradoxerweise ist der Strom bei mir zu Hause stabiler. Wenn man kein Geschäft betreibt, bei dem ein paar Minuten Downtime Umsätze in Millionenhöhe beeinflussen, können die meisten Leute ihre Server genauso gut im Keller laufen lassen. Viele überschätzen den Bedarf an 99,999 % Uptime oder riesiger Bandbreite massiv. Colocation ist auch nicht so billig, wie viele denken. Strom im Rechenzentrum ist oft teurer als normale gewerbliche oder private Stromtarife. Wirklich günstig sind nur Internet und Glasfaser, und in vielen Ländern bekommt man inzwischen 5–10 Gbit Business-Anschlüsse für 100 Euro (früher kostete schon 1 Gbit leicht über 2.000 Euro)
• Unabhängig von Kosten- oder Kapazitätsanalysen ist es schwer, sich dem Branchentrend zu widersetzen. Der Vorteil, sich „gar nicht um Hardware kümmern zu müssen“, existiert wirklich. Dazu kommt eine starke Denkweise, dass capex (Investitionsausgaben) unbedingt vermieden werden müsse (Server-Hardware bedeutet hohe Vorabkosten). Und wenn eine AWS-Region ausfällt, fühlt es sich nicht so an, als sei es „unsere Schuld“, während es bei einem internen Server sofort als „unsere Verantwortung“ wirkt
  • Diese extreme Abneigung gegen capex (Investitionsausgaben) ist fast ganz dem VC-Finanzierungsmodell geschuldet — wenn Investoren nur auf hyper­schnelles Wachstum drängen, lässt sich Vorabinvestition (Serverkauf) logisch kaum rechtfertigen. Ein stabiles Geschäft kann dagegen jedes Jahr problemlos kleine capex-Ausgaben tragen
  • Man muss Server-Hardware nicht unbedingt kaufen — bei Anbietern wie Hetzner reicht Miete völlig aus. Ich würde gern genauer verstehen, worin konkret der Vorteil liegt, sich „nicht um Hardware kümmern zu müssen“
  • Diese Denkweise, capex sparen zu wollen, gibt es tatsächlich. Wer nur einen Taschenrechner bedienen kann, sieht schon heute, dass Serverkosten im Gesamtgeschäft kaum ins Gewicht fallen. Teuer ist vielmehr der „Raum“ um den Server herum — deshalb mietet man meist nicht den Server, sondern den Platz (Rack/Strom)
  • Was Unternehmen am Ende wirklich kaufen, ist eine „Abstraktion von Verantwortung“. Führungskräfte in Großunternehmen fühlen sich wohler, wenn die Lösung von großen Anbietern wie MS oder AWS kommt
  • Wenn man Bare-Metal-Server mietet, muss man sich weder um capex noch um Wartung kümmern