2023 lag der Ruhm nur 11 MB/s entfernt

Die Wahrheit über Cloud-Kosten

• Es gibt die Wahrnehmung, dass Cloud-Services günstig seien, doch in der Praxis besteht die Möglichkeit, dass Nutzer überhöhte Kosten zahlen.
• AWS erwirtschaftet den Großteil der Gewinne von Amazon, was bedeuten könnte, dass Cloud-Services tatsächlich teuer sind.

Berechnungen ausgehend von First Principles

• Wenn man eine der Top-1000-Websites bauen möchte, etwa wie businessinsider.com, braucht man ungefähr 200 Mio. Besucher pro Monat und 400 Mio. Page Views.
• Allein mit HTML-Dokumenten werden monatlich 30 TB Bandbreite benötigt, doch das sind nur 11 MB/s – ein sehr niedriger Maßstab für moderne Hardware.

Latenz verstehen

• Betrachtet man die Lichtgeschwindigkeit, benötigt ein Hin- und Rückweg bis ans andere Ende der Erde etwa 200 ms, tatsächlich sind es aber ungefähr 300 ms.
• Wenn man JS, CSS und Medien über ein CDN ausliefert, kann man 300 ms Serververarbeitungszeit einsparen, was denselben Effekt haben kann, als stünde der Server direkt neben dem Nutzer.

Grenzen von Edge-Technologien

• Edge-Technologien lösen trotz der Weiterentwicklung der zweiten Generation von Serverless-Technik nicht das Datenbankproblem.
• Die meisten komplexen Seiten benötigen Datenbankabfragen, was die Latenz erhöhen kann.

Überlegungen zu den Kosten

• Hetzner.com bietet im Vergleich zu AWS EC2 deutlich günstigere Server- und Bandbreitenkosten.
• Cloud-Anbieter stellen anfangs vieles kostenlos bereit, doch mit der Skalierung steigen die Kosten stark an.

Die realistische Lage

• Abgesehen von speziellen Use Cases können die meisten Websites oder SaaS-Angebote auf einem einzelnen Server laufen; das ist günstiger und einfacher zu warten.
• Man kann SQLite lokal verwenden, CSS, JS und Bilder über ein CDN cachen und mit Server Side Rendering die Performance verbessern.
• Auch ohne komplexes Docker-Setup oder Virtualisierung lässt sich ausreichend skalieren; zudem ist die Verwaltung einfacher und kostengünstiger.

Meinung von GN⁺

• Dieser Artikel stellt die verbreitete Annahme infrage, Cloud-Services seien kosteneffizient, und weist darauf hin, dass Nutzer womöglich mehr bezahlen als tatsächlich nötig.
• Im Vergleich zur Kostenstruktur von Cloud-Services zeigt er, dass klassisches Hosting auf einem einzelnen Server weiterhin eine tragfähige Alternative sein kann.
• Er betont, dass Technologien wie Serverless, Docker und horizontale Skalierung nicht in jeder Situation nötig sind und dass ein einfacherer Ansatz manchmal bessere Performance und niedrigere Kosten bringen kann.
• Hervorgehoben wird auch die Bedeutung von Datenbankoptimierung und regionaler Platzierung, was darauf hindeutet, dass sich damit eine gleiche oder sogar bessere Performance als mit Cloud-Services erreichen lässt.
• Bei der Technologiewahl sollte man den tatsächlichen Traffic und die Performance-Anforderungen bewerten und unter Kosten-Nutzen-Gesichtspunkten klassisches Server-Hosting als Alternative zur Cloud in Betracht ziehen.

[GN⁺]

Hacker-News-Kommentare

• Erfahrungen im Hosting-Geschäft

  • Früher wurden im Hosting-Geschäft je nach Kundenanforderungen komplexe Systeme bereitgestellt.
  • Um AWS etwas entgegenzusetzen, wurde eine API-basierte Cloud-Hosting-Plattform entwickelt, doch 2012 erreichte der Umsatz seinen Höhepunkt.
  • Kunden wollten komplexere, auf AWS basierende Lösungen und vertrauten einfachen Servern nicht.
  • Das Unternehmen wurde bootstrap-finanziert betrieben und verstand nicht, warum es nötig sein sollte, das Kostenrisiko von AWS zu tragen.
  • AWS wird wegen der tief verwurzelten „Cleverness“ in einer ganzen Generation von Softwareentwicklern bevorzugt.

• Fehler in der Traffic-Analyse

  • Traffic ist nicht gleichmäßig verteilt, und der Bandbreitenbedarf zu Spitzenzeiten liegt weit über dem Durchschnitt.
  • In realen Diensten sind für den Aufbau von TCP- und TLS-Verbindungen mehrere Roundtrips nötig, und die Antwortzeit ist für die Nutzererfahrung entscheidend.

• Serverfehler und Traffic

  • 500 Internal Server Error zeigt an, dass der Server mehr Traffic verarbeitet als erwartet.

• Ansatz zur Skalierung von Diensten

  • Es ist ratsam, unnötige Skalierung zu vermeiden und nur dann auszubauen, wenn es wirklich nötig ist.
  • Treten Performance-Probleme auf, sollte man erst dann darauf reagieren.

• Vorteile von AWS

  • Mit AWS hat man im Fall eines Dienstausfalls zumindest eine Ausrede.

• Diskussion über Cloud-Architekturen

  • Es geht nicht um eine Debatte über die Notwendigkeit von Cloud-Architekturen, sondern darum, Alternativen aufzuzeigen.
  • Verfügbarkeitsprobleme bei Serverausfällen lassen sich auch auf andere Weise lösen.

• SQLite und vertikale Skalierung

  • Statt SQLite kann selbst gehostetes Postgres verwendet werden, was allerdings mehr Einrichtungsaufwand erfordert.
  • Eine Architektur ist möglich, bei der der gesamte globale Zustand im Speicher gehalten und Snapshots auf der Festplatte gespeichert werden.

• Kombination von API und SQLite-Datenbank

  • SQLite kann in einem einzelnen Thread viele Abfragen verarbeiten.
  • Durch In-Memory-Caching auf der API-Seite und das Umgehen der Datenbank bei statischen Seiten lässt sich die Performance verbessern.

• Verfügbarkeitsprobleme eines einzelnen Servers

  • Wird ein Dienst auf nur einem Server betrieben, kann es zu ungeplanten Ausfallzeiten kommen.
  • Dabei sollten die Zeit für die Datenwiederherstellung und das Ausmaß des Datenverlusts berücksichtigt werden.

• Wechsel in die Cloud und Verfügbarkeit

  • Der Wechsel in die Cloud fühlt sich oft wie Gruppendruck an.
  • Unter Verfügbarkeitsgesichtspunkten kann ein einzelner Server riskant sein; sinnvoll ist eine kluge Mischung aus CDN und Cloud.