Migration von AWS zu Hetzner senkt Cloud-Kosten um 76 %

• Durch die Migration von AWS und DigitalOcean zu Hetzner wurden die Cloud-Kosten um 76 % gesenkt und die Ressourcenkapazität gleichzeitig verdreifacht
• Zuvor wurden die Stabilität von AWS und die Einfachheit von DigitalOcean genutzt, indem beide Cloud-Dienste parallel betrieben wurden
• Nach dem Aufbrauchen der kostenlosen Credits entstand eine monatliche Betriebskostenbelastung von über 449 US-Dollar, sodass nach Alternativen wie Hetzner gesucht wurde
• Um Kosten zu senken, wurde ein selbstverwalteter Cloud-Stack aufgebaut, bestehend aus Talos Linux-basiertem Kubernetes, CloudNativePG, Ingress NGINX, ExternalDNS, cert-manager und weiteren Komponenten
• Mit ARM-Shared-vCPU-Servern und S3-kompatiblem Storage von Hetzner konnte trotz gleichbleibender Performance und Stabilität eine massive Skalierung der Ressourcen erreicht werden
• Der Bedienkomfort ist etwas geringer, aber als alternative Cloud in Europa bietet Hetzner ein hervorragendes Verhältnis aus Kosten und Leistung

---

Hintergrund

• Sämtliche von DigitalSociety entwickelte Software läuft cloudbasiert
• Vor der Migration wurde die Hauptinfrastruktur sowohl auf AWS (zentrale Services sowie Verwaltung von Authentifizierung, E-Mail usw.) als auch auf DigitalOcean (leichtgewichtige Services, Monitoring, Kubernetes) betrieben
• AWS wurde wegen der Vertrautheit aus mehr als 15 Jahren Nutzung und der hohen API-Stabilität gewählt
• DigitalOcean wurde wegen der einfachen Kubernetes-Umgebung, der kostenlosen Control Plane und der Kosteneffizienz gewählt
• Anfangs wurde nur DigitalOcean genutzt, doch für datenintensive SaaS wie tap wurden viele Ressourcen und zusätzliche Credits benötigt, weshalb die AWS-Startup-Credits (1.000 US-Dollar) verwendet wurden

Ende der Credits und Kostendruck

• Dank AWS Fargate (serverloses Container-Running) ließ sich die Umgebung anfangs günstig aufbauen, doch wegen der datenintensiven Natur des Dienstes tap waren zur Aufrechterhaltung der Performance mindestens 2x CPU und 4 GiB RAM nötig
• Ein Container mit dieser Spezifikation kostet auf Fargate-Basis mehr als 70 US-Dollar pro Monat; zusammen mit zwei Worker-Instanzen und weiterer Infrastruktur stiegen die monatlichen Kosten auf 449,50 US-Dollar
• Die bereitgestellten Gratis-Credits waren in weniger als sechs Monaten aufgebraucht und wurden für ein bootstrapped Startup zu einer ernsthaften Fixkostenbelastung

Suche nach Alternativen

• Um die hohen Betriebskosten zu senken und technologische Unabhängigkeit zu gewinnen, wurde nach Cloud-Anbietern mit Sitz in Großbritannien oder der EU gesucht
• Die Preisattraktivität von Hetzner überzeugte so sehr, dass trotz selbstverwalteter VPS-Umgebung und höherer Betriebs-Komplexität die Migration sowohl von AWS als auch von DigitalOcean beschlossen wurde
• Da die meisten Services bereits auf Kubernetes basierten, wurde dank der einfachen Cluster-Bereitstellung mit Talos Linux auch in der Hetzner-Umgebung ein eigenes Kubernetes-Cluster aufgebaut
• Zwar gab es dort keine Managed-DB-Services wie bei AWS oder DigitalOcean, aber mit CloudNativePG ließ sich ein PostgreSQL-Cluster sicher in Kubernetes integrieren und zentral verwalten (Monitoring, Backups, Ausfallbehandlung usw.)

Neuer Infrastruktur-Stack

• Hetzner: Nutzung von ARM-Servern, Block Storage, Load Balancern, Netzwerk, Firewalls und S3-kompatiblem Object Storage
• Talos Linux: Automatisierung des Betriebs durch Kubernetes-Node-Management mit deklarativer Konfiguration
• CloudNativePG: Deklaration des DB-Clusters in Kubernetes-Manifesten sowie integrierte Unterstützung für automatische Backups, Failover usw.
• Ingress NGINX Controller: Zentrale Verwaltung des HTTP-Routings innerhalb des Clusters
• ExternalDNS: Automatische DNS-Anbindung für Ingress-Ressourcen
• cert-manager: Automatische Ausstellung von TLS-Zertifikaten für HTTPS
• Die gesamte Infrastruktur wurde mit Terraform und Helm als Code abgebildet und über GitHub Actions automatisiert ausgerollt, wodurch DevOps umgesetzt wurde

Kostenvergleich

• Monatliche Kosten vor der Umstellung: AWS + DigitalOcean = 559,36 US-Dollar
• Monatliche Kosten nach der Umstellung: Hetzner = 132,96 US-Dollar (−76 %)
• Ressourcenausbau:
  • CPU: 12 vCPU → 44 vCPU (+367 %)
  • RAM: 24 GiB → 88 GiB (+367 %)
  • Trotz der höheren Ressourcen lagen die monatlichen Gesamtkosten deutlich niedriger

Herausforderungen und Lernprozesse bei der Migration

• Die Network Zones von Hetzner entsprechen nicht vollständig den Availability Zones von AWS
  • AWS bietet in einer Region mehrere Availability Zones, und das private Networking ist regionsweit umfassend verbunden
  • Bei Hetzner gibt es unter einer Network Zone (eu-central) mehrere Standorte (location), zwischen denen die Netzwerklatenz hoch ist
  • In der Praxis zeigte das Monitoring, dass eine Verteilung über mehrere Standorte hinweg zu Problemen wie Performance-Einbußen führte
  • Als Alternative wurde innerhalb eines einzelnen Standorts (Nürnberg) eine Placement Group genutzt, um durch physische Verteilung der Server Ausfallsicherheit zu erreichen
• Auch containerbasierte Services lassen sich nicht einfach portieren
  • Beim Wechsel von AWS ECS zu Kubernetes dauerte die Anpassung der Automatisierungsskripte für die gesamte Konfiguration (insbesondere für die Verteilung von Config-Dateien) unerwartet lange
  • Letztlich wurden mit Kustomize die Einbindung sensibler Konfigurationen und die Verwaltung von Config-Dateien verbessert, was Nachvollziehbarkeit und Reviewbarkeit erhöhte

Fazit

• Hetzner ist kein bequem zu nutzender Managed Service, aber für Teams mit Self-Management-Fähigkeiten eine sehr effiziente Wahl
• Durch den Eigenbetrieb bleibt die Kontrolle über die Detailkonfiguration erhalten und das Preis-Leistungs-Verhältnis wird maximiert
• Auf diese Weise wurde eine Grundlage geschaffen, um das datenintensive SaaS tap weiterhin zu vertretbaren Kosten und mit stabiler Performance zu entwickeln und zu betreiben

[GN⁺]

Hacker-News-Kommentare

• Ich möchte wirklich betonen, wie enorm der spürbare Performance-Gewinn ist, wenn man direkt auf Bare Metal deployt. Bei unserem Service hat sich die Performance verdoppelt und liefert eine vorhersehbare, stabile Leistung. Dafür gibt es mehrere Gründe:

  • Niedrige Latenz: Wenn man das Netzwerk direkt verwaltet, teilt man sich nicht das komplexe Netzwerk eines großen Rechenzentrums, wodurch sich die Latenz um mehr als das Zehnfache reduziert

  • Cache-Optimierung: Mit einer auf die Hardware optimierten Bereitstellung lässt sich die tatsächliche Leistung moderner CPUs voll ausnutzen

  • Dedizierte NVMe-Nutzung: Die Disk-I/O-Geschwindigkeit ist enorm

  • Ein weiterer Vorteil ist, dass man Autoscaler kaum noch braucht. Bei gleichem Preis ist die Hardwareleistung 10-mal höher und die Geschwindigkeit doppelt so hoch, sodass es sinnvoller ist, in voller Größe zu fahren. Das gesamte System ist stabil und leicht zu verwalten

  • Man muss sich auch keine Sorgen um S3-Gebühren machen. Man steckt einfach 15-TB-NVMe-Drives in jeden Server und betreibt einen MinIO-/garage-Cluster. Wir verarbeiten in einem 10-Node-Cluster 20 GiB pro Sekunde und 50.000 API-Calls pro Sekunde. Mit S3 wäre allein das bei den API-Calls ein erstaunlicher Preisunterschied von 20 bis 250 US-Dollar pro Sekunde

  • Es fällt nur eine feste Monatsgebühr an

  • Dazu kommen günstiger schneller Storage, kostengünstiger Betrieb großer PostgreSQL-Instanzen und deutlich weniger Einschränkungen und Frickelei als in der Cloud

  • Selbst wenn man in eine solche Architektur investiert, kostet sie im Vergleich zu AWS nur ein Zehntel

  • Wenn einem die Selbstverwaltung zu viel ist, übernehmen wir (https://lithus.eu) das für die Hälfte der AWS-Kosten und unterstützen auch bei DevOps. Kontakt über adam@, siehe Domain

  • Technischer Hintergrund: Bare Metal bedeutet, dass es direkt auf realen Servern und nicht in einer Virtualisierung (VM) läuft

  • Ich hoffe wirklich, dass wir das alte Zeitalter hinter uns lassen, in dem es hieß: „Mehr Hardware macht alles schneller“ und „Kosten spielen keine große Rolle“. In meiner Karriere habe ich in der .NET-Zeit erlebt, wie wir mit einem einzelnen Rack-Server mehrere Millionen Nutzer bedient haben. Später wechselte ich zu einer Firma mit Cloud-basierter, containerisierter Node-Microservices-Architektur, und das tägliche Chaos aus Rechnungen und Performance-Problemen jagt mir manchmal bis heute einen Schauer über den Rücken

  • Wandel scheint sich immer zu wiederholen. Wenn ich unser Unternehmen anschaue, wirkt es fast so, als lägen wir gerade deshalb an der Spitze des Trends zu lokaler Cloud, Edge und On-Prem-IDCs, weil wir nicht jeder neuen Technologie hinterherlaufen

  • Die S3-API zu benutzen fühlt sich an, als würde man Zwiebeln schälen. Je länger man sie benutzt, desto mehr Tränen kommen

  • Mit Bare Metal braucht man dediziertes Personal für Netzwerkverwaltung, Sicherheit, Monitoring, Patches und Aktualisierungen. Die Kosten für solche Spezialisten lohnen sich nur ab einer gewissen Größenordnung. Deshalb ist die Cloud für kleine und mittlere Unternehmen in Bezug auf Sicherheit und Betriebskosten weiterhin im Vorteil

  • Selbst bei AWS gibt AWS in den eigenen Unterlagen an, dass bei Lambda die Zuweisung von 1 vCPU in der Praxis nur etwa 50 % entspricht. Mit mehr Speicher- und CPU-Zuweisung verbessert sich das Verhältnis zwar, aber 100 % Performance bekommt man nicht immer

• Ich dachte schon immer, dass man mit dedizierten Servern die Effizienz maximieren kann. Ich betreibe ein paar Nodes bei Hetzner, und selbst wenn man über die Auktion ältere Server mietet, die schon drei Jahre alt sind, bekommt man eine Performance, die in einer ganz anderen Liga als bei VMs spielt. Server-Hardware ist auf viele Kerne und I/O optimiert, und die meisten Clouds überbuchen die Hardware massiv. Sogar bei der Disk-I/O werden alle möglichen Tricks eingesetzt, etwa NAS im Hintergrund und die Emulation lokaler Disks. Die meisten Startups brauchen diese übertriebene Virtualisierung und NAS-basierten Disks gar nicht. Wenn man stattdessen Server bei einem Anbieter wie Hetzner mietet, kommt man viel weiter und günstiger. Mich würde interessieren, welche Anbieter in Nordamerika, insbesondere in Kanada, ein Preis-Leistungs-Verhältnis auf Hetzner-Niveau bieten. OVH kenne ich already, aber ich würde mich über Hinweise auf ähnliche Anbieter freuen

  • Viele Leute scheinen zu glauben, man müsse die technischen Architekturen von Google oder Facebook sofort eins zu eins nachbauen. Wir betreiben unsere Dienste bescheiden auf europäischen VPS. Trotzdem sagt jeder neue Mitarbeiter, ob im Business oder in der Entwicklung, jedes Mal, man müsse ein Cloud-Migrationsprojekt starten. Jedes Mal muss ich dann erklären: „Wir nutzen bereits Cloud, und dein Cloud-Migrationsprojekt für den Lebenslauf wird hier nicht stattfinden.“

  • Ich habe selbst einmal die CPU-Performance von Cloud- und Bare-Metal-Servern benchmarked, vielleicht ist das hilfreich: https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12

  • Eine Website, die ich kürzlich gefunden habe, könnte hilfreich sein: https://vpspricetracker.com. Das Konzept ist sehr beeindruckend. Die meisten dort gelisteten Anbieter bieten auch dedizierte Server an

  • Falls mit „Hetzner-Qualität in den USA“ gemeint ist, dass die Marke nicht lokal sein muss: Hetzner selbst betreibt inzwischen auch zwei Rechenzentren in den USA

  • Für Kanada könnten https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/ als Referenz interessant sein

• Wir erleben denselben Trend. Viele Teams migrieren zu Hetzner und sind begeistert vom Preis-Leistungs-Verhältnis, merken dann aber, dass sie den gesamten Postgres-Betrieb wie Backups, Failover und Monitoring wieder selbst aufbauen müssen. Deshalb haben wir selbst ein Managed Postgres gebaut, das direkt auf Hetzner läuft. Es nutzt dieselbe hardwareoptimierte Struktur und bringt Hochverfügbarkeit (HA), Backups und Point-in-Time Recovery (PITR) mit. Es ist Open Source, läuft nahe an der Hardware und vermeidet die versteckten Fallstricke wie I/O-Gebühren und Data-Egress-Kosten, die man bei AWS oft erlebt. Wer mehr wissen will, kann in den Blog schauen 1, 2

  • Genau aus diesem Grund finde ich den Reiz von Big Cloud, insbesondere von PaaS und Managed SQL, sehr groß, und die Entwicklungsteams, die ich berate, sehen das genauso. Auch ohne viel Betriebserfahrung ist es beruhigend, wenn Datenbank-Backups und -Wiederherstellung, Patches, Zugriffsbeschränkungen, Port-Management, Anomalie-Erkennung und Abwehr von DoS-Angriffen automatisch erledigt werden. Politisch wie technisch ist die Nutzung eines beliebten Cloud-Anbieters eine Art psychologisches Sicherheitsnetz

  • Falls jemand mit einer selbst konfigurierten, selbst verwalteten Postgres-Version Probleme hat, könnte https://www.elephant-shed.io/ interessant sein

• Es ist interessant, dass solche Artikel oder Kommentare fast nie den Kontext dazuschreiben, in dem ihre Ratschläge gelten. Es macht einen enormen Unterschied, ob jemand in seiner Freizeit einen Gemeindebrief betreibt oder ein hochfrequentiertes Enterprise-SaaS mit Kunden auf der ganzen Welt. Ohne Beschreibung der eigenen Umgebung sind Empfehlungen zu Preis, Performance oder Verfügbarkeit im Grunde bedeutungslos. Web-Infrastruktur ist auch deshalb übermäßig komplex geworden, weil Menschen gegenseitig Ratschläge übernehmen, obwohl ihre Anforderungen völlig unterschiedlich sind

  • Ergänzend zu meiner Ansicht „Unkritisch befolgte Ratschläge bei unterschiedlichen Anforderungen machen die Realität nur komplexer“: In manchen Unternehmen setzt sich der Cloud-Account-Manager mit an den Lunch des C-Levels und sorgt dafür, dass AWS-Nutzung angeordnet wird. Dabei wird ein AWS-Architekt direkt in unser Team entsandt, und natürlich empfiehlt er nur die teuersten serverlosen Optionen. In Wirklichkeit deployen wir am Ende aber doch ständig neue Docker-OS-Images und müssen sie genauso ununterbrochen pflegen wie auf normalen Bare-Metal-Servern

  • Sogar mein persönliches Pastebin würde ohne Bare Metal nicht durchhalten (Scherz)

  • Das ist ein typisches Beispiel dafür, wie die IT-Branche funktioniert

  • Anforderungen, technisches Niveau, Kostenstruktur und Problemraum sind völlig unterschiedlich. Hetzner und AWS sehen oberflächlich beide nach Cloud aus, sind in Wirklichkeit aber völlig verschiedene Dienste. Das sage ich als jemand, der beides genutzt hat

  • Stimme ich stark zu. Ich habe meine Meinung dazu auch in einem Blogkommentar festgehalten: https://news.ycombinator.com/item?id=45616366. Kurz gesagt: „Verstehe Hosting-Anbieter über ihre Preisstufen von DIY bis Enterprise, und wenn Nichtnutzung der bessere Deal ist (YAGNI), dann wähle es gar nicht erst.“

• Ich betreibe seit über 10 Jahren SaaS auf Hetzner. Vollständig dedizierte Hardware, Cluster in Rechenzentren in Deutschland und Finnland, verwaltet mit ansible. Für VPN-Verbindungen zwischen den Servern nutze ich vpncloud; die Software ist wirklich hervorragend. Die monatlichen Hosting-Kosten sind im Vergleich zu AWS und Co. extrem gering, und die Server sind deutlich schneller. Mit einer einfachen Struktur und wenigen Servern kommen wir gut aus. Wenn nötig, fügt man einfach weitere Server hinzu, wobei sich Bare Metal natürlich nicht innerhalb von Minuten skalieren lässt. Man muss einige Stunden oder Tage im Voraus planen. Die Datenbank ist mit RethinkDB verteilt aufgebaut, um Ausfälle abzufangen, wobei wir künftig zu FoundationDB wechseln wollen

  • Ich betreibe etwas Ähnliches mit rethinkdb. Mich würde aber interessieren, warum du dich ausgerechnet für FoundationDB entschieden hast. RethinkDB wird noch gepflegt, und gelegentlich kommen sogar neue Features dazu. Erstaunlich viele Nutzer sind auch noch in der Slack-Community aktiv

  • Es freut mich, dass es noch Leute gibt, die RethinkDB verwenden

  • Verbindest du die Hetzner-DE-/FI-Zentren direkt per vpncloud? Ich dachte, Hetzner selbst bietet so etwas auch günstig an

• Ich habe in letzter Zeit viele Teams beim Wechsel von AWS zu Hetzner (und Netcup) unterstützt, und die größte Überraschung für die Leute ist nicht einmal der Preis oder die Performance an sich, sondern wie radikal sich alles vereinfacht, wenn man 15 Schichten verwalteter Abstraktionen und Dienste entfernt. Die Sorgen um S3/EFS/FSx, Lambda-Cold-Starts oder EBS-Burst-Credits verschwinden. Man deployt einfach Docker auf schnelles NVMe, und es funktioniert. Dafür braucht man etwas mehr DevOps-Kompetenz für Monitoring, Backups, Patches und Ähnliches. Solche Betriebsaufgaben sind aber nach der Automatisierung nicht etwas, das sich jede Woche ändert. Bei Elestio konzentrieren wir uns auf genau diese Vereinfachung und bieten vollständig gemanagte Stacks für mehr als 400 Open-Source-Softwares auf jeder Cloud, einschließlich CI/CD. Das deckt auch Produktion auf Hetzner und anderswo ab https://elest.io (zur Einordnung: Ich arbeite bei Elestio und biete dort Multi-Cloud-Open-Source-Services an)

  • Mich interessiert euer Managed-Postgres-Service. Unterstützt ihr Streaming-Replikate und Streaming-Backups, oder speichert ihr nur Dumps in S3?

• Zu Beginn meiner Karriere arbeitete ich bei einer großartigen Firma, aber wir brauchten eine Postgres-Version, die von RDS damals nicht unterstützt wurde, daher musste ich mehrfach Postgres direkt auf EC2 aufsetzen. Das war noch vor Docker, und mit der Zeit fühlte sich die Einrichtung immer mehr wie reine Zeitverschwendung an. Sobald RDS diese Version unterstützte, wurde alles schlagartig einfacher. Ich erinnere mich noch lebhaft daran, wie ich bis 3 Uhr morgens immer wieder Postgres installiert habe. Der Artikel ist zwar gut, aber am Ende spart man vielleicht nur ein paar hundert Dollar im Monat. Schon wenn ein Engineer nur eine Stunde im Monat für die Verwaltung aufwendet, kann das die Einsparung zunichtemachen. Und wenn plötzlich eine Störung auftritt, kann die Ersparnis eines ganzen Jahres an einem einzigen Tag verpuffen. Für ein persönliches Projekt, bei dem Zeit nicht viel zählt und man große Server braucht, kann Bare Metal sinnvoll sein. Am Ende wird aber der Wert der eigenen Zeit größer. Ein Ghost-Blog kostet beim offiziellen Hosting zum Beispiel 10 Dollar im Monat; man könnte auch mehrere Instanzen auf einer Hetzner-VM betreiben. Aber wenn dann etwas kaputtgeht, fragt man sich irgendwann, ob 20 Dollar mehr nicht besser sind, als 2 oder 3 Stunden mit Reparaturen zu verbringen

• Der größte Vorteil einiger dedizierter Server von Hetzner ist unbegrenzte Bandbreite. Ich hoste eine bildlastige Website, und seit dem Wechsel zu Hetzner zahle ich seit drei Jahren nur noch eine feste Gebühr und kann nachts ruhig schlafen

• Hetzner hat klare Grenzen bei der Skalierung. Wir haben anfangs Hunderte von VMs auf Hetzner betrieben und mussten in Spitzenzeiten auf über tausend skalieren. Dabei traten Probleme auf: Uns wurden gelegentlich IPs aus Blacklists zugewiesen, was Verbindungen zu AWS und Google, insbesondere zu S3, erschwerte. Zu einem bestimmten Zeitpunkt waren in unserer Region sogar keine VMs mehr verfügbar, sodass neue Zuweisungen komplett gestoppt wurden. Am Ende ist Hetzner großartig, wenn man keine massive Skalierung braucht, aber wenn man wirklich stark wachsen muss, muss man andere Dienste dazumischen

  • Dass in einer Region keine VMs mehr verfügbar sind, scheint kein Problem nur eines bestimmten Cloud-Anbieters zu sein. GCP hatte vor ein paar Jahren Ähnliches. Wenn man zu Spitzenzeiten auf einen Schlag Hunderte VMs anfordert, scheint jede Cloud damit zu kämpfen zu haben

  • Dass Microsoft Hetzner- und Scaleway-Dienste blockiert hat, ist gut bekannt https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. Ich wusste nicht, dass AWS und GCP das ebenfalls getan haben, aber überrascht mich nicht besonders. Die Big Clouds rechtfertigen solches wettbewerbswidriges Verhalten mit dem Vorwand „Spam-Zufluss“, aber in Wirklichkeit ist es das nicht

  • Vielleicht geht es hier um den Unterschied zwischen Nutzern echter Hetzner-Hardware wie Server Auction und Nutzern virtueller Server (VMs). Physische Server sind bei Preis-Leistung und Geschwindigkeit deutlich besser, und auch wenn die VMs nicht revolutionär sind, sind sie immer noch günstiger als bei Wettbewerbern

  • Diese Kontroverse betrifft das Hetzner-Cloud-Produkt, also die VMs. Das Cloud-Produkt wurde im Vergleich zu den dedizierten Servern erst relativ spät eingeführt. Viele Nutzer kommen wegen des Werts der dedizierten Server überhaupt erst zu Hetzner

  • Rein aus Neugier: Was für ein Dienst benötigt Hunderte bis Tausende VMs, und warum habt ihr dafür VMs statt dedizierter Server verwendet? Die größte VM bei Hetzner soll 48 Kerne, 192 GB RAM und 960 GB SSD haben; ich frage mich, welche Anforderungen solche Spezifikationen nötig machen

• Es gibt gute Gründe, Hetzner zu nutzen, aber ein paar Dinge sollte man beachten. Die Verfügbarkeit ist etwas schwächer als bei AWS, und es gibt weniger Regionen. Deshalb würde ich auf jeden Fall empfehlen, es zusammen mit Cloudflare zu nutzen. Bei Hetzner betreiben wir die Kernsysteme (K8s), während die Daten auf R2/D1/KV und Edge Durable Objects verteilt werden. Wir sharden Kundendaten pro DO, was sowohl die Last auf der zentralen Datenbank reduziert als auch Sicherheitsvorteile bringt

  • AWS hatte überraschenderweise ebenfalls einige größere Ausfälle. Letztlich sind Verfügbarkeitsprobleme strukturell schwer zu vermeiden, solange man nicht für Multi-Region ausgelegt ist

  • Ich habe mein Setup ähnlich aufgebaut: Kernsysteme und redundanten Storage auf dedizierten Hetzner-Servern, dazu weltweite Edge-Nodes bei OVH, quasi wie ein eigenes CDN

  • Wenn sich die Kundendaten am Edge befinden, was genau ist dann der „Kern“?