- 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
Noch keine Kommentare.