Wechsel von AWS auf Bare Metal spart jährlich 230.000 US-Dollar (300 Mio. Won)

• Die Open-Source-Observability-Plattform OneUptime hat ihre Infrastruktur von AWS auf eine Bare-Metal-Lösung migriert und dadurch mehr Kontrolle über die Ressourcen sowie erhebliche finanzielle Einsparungen erzielt.
• Da die meisten Kunden Public Cloud nutzen, war ein unabhängiges Rechenzentrum nötig, um auch bei Cloud-Ausfällen einen Benachrichtigungsdienst bereitstellen zu können.

Anfangskonfiguration: Kubernetes auf AWS

• Es wurde ein Kubernetes-Cluster mit dem verwalteten Elastic Kubernetes Service (EKS) von AWS eingesetzt.
• OneUptime basiert auf Open-Source-Software, die nicht AWS-spezifisch ist, darunter Redis, Postgres, Clickhouse, Docker, NodeJS und BullMQ.
• So werden Abhängigkeiten von AWS vermieden, und Kunden können OneUptime im eigenen Cluster selbst hosten.

Der Umstieg: Migration auf Bare Metal

• Im Rahmen des Strebens nach technischer Exzellenz fiel die Entscheidung für den Wechsel zu einer Bare-Metal-Lösung.
• Gewählt wurde der Betrieb eines Microk8s-Clusters in einer Colocation-Einrichtung, basierend auf früheren Erfahrungen und zukunftsorientierten Zielen.
• Microk8s lässt sich auch in Produktionsumgebungen einsetzen, und der Wechsel auf Bare-Metal-Server ermöglicht dedizierte Ressourcen und Performance-Optimierung.

Die Rolle von Kubernetes und Helm

• Kubernetes und Helm spielten eine zentrale Rolle beim Wechsel von der Cloud auf eigene Server.
• Kubernetes ist eine Open-Source-Plattform zur Automatisierung der Bereitstellung, Skalierung und des Betriebs von Anwendungs-Containern.
• Helm ist ein Paketmanager, der das Definieren, Installieren und Upgraden von Kubernetes-Anwendungen vereinfacht.

Storage und Load Balancer

• Im Bare-Metal-Kubernetes-Cluster werden für Volumes das Network File System (NFS) und als Load Balancer MetalLB verwendet.
• NFS ist ein verteiltes Dateisystemprotokoll, das Client-Computern den Zugriff auf Dateien über ein Netzwerk ermöglicht.
• MetalLB ist eine Load-Balancer-Implementierung für Bare-Metal-Kubernetes-Cluster, die standardisierte Routing-Protokolle verwendet.

Finanzielle Auswirkungen: Mehr als 230.000 US-Dollar Einsparung pro Jahr

• Bei der Nutzung von AWS lagen die Ausgaben bei mehr als 38.000 US-Dollar pro Monat bzw. über 456.000 US-Dollar pro Jahr.
• Nach der Migration auf Bare Metal wurde ein einzelnes Rack beim Colocation-Partner genutzt, wodurch die monatlichen Betriebskosten auf etwa 5.500 US-Dollar sanken.
• Verteilt man die Serverkosten über fünf Jahre, ergibt sich eine Einsparung von mehr als 230.000 US-Dollar pro Jahr; dadurch konnten zusätzliche Mitarbeitende eingestellt und Ressourcen anderen Geschäftsbereichen zugewiesen werden.

Zu berücksichtigende Punkte

• Die Daten werden mehrmals täglich in zwei Büros gesichert und können zusätzlich auch in der Public Cloud gesichert werden.
• Es ist möglich, einen Kubernetes-Cluster über mehrere Standorte in zwei Colocation-Einrichtungen auf verschiedenen Kontinenten zu betreiben.
• In AWS steht ein Backup-Cluster bereit, das im Katastrophenfall innerhalb von 10 Minuten gestartet werden kann.
• Für den Wechsel auf Bare Metal ist die Einstellung eines Serveradministrators nicht zwingend erforderlich, da die Colocation-Einrichtung den Großteil der Hardware-Wartung übernimmt.
• Microk8s wird nicht nur für Entwicklungszwecke, sondern auch in Produktionsumgebungen verwendet, und bei Bedarf ist ein einfacher Wechsel zu einer anderen Kubernetes-Distribution möglich.

Fazit

• Cloud-Dienste wie AWS bieten Flexibilität und hohe Leistungsfähigkeit, sind aber nicht für jedes Unternehmen die wirtschaftlichste Wahl.
• Durch die Nutzung von Open-Source-Technologien und Investitionen in eigene Hardware lassen sich die Kontrolle über Ressourcen verbessern und die Betriebskosten deutlich senken.
• Da jedes Unternehmen eigene Anforderungen hat, ist vor einem solchen Wechsel eine umfassende Bewertung notwendig.

Meinung von GN⁺

Das Wichtigste an diesem Beitrag sind die Vorteile bei Kontrolle und Kosteneinsparung, die Unternehmen durch den Wechsel von Cloud-Diensten zu Bare-Metal-Infrastruktur erzielen können. Interessant ist der Text, weil er anhand eines konkreten Beispiels zeigt, wie technische Entscheidungen finanzielle Ergebnisse beeinflussen können. Dank der Weiterentwicklung von Technologien wie Docker, Kubernetes, Helm und Microk8s ist ein solcher Wechsel heute deutlich einfacher als noch vor einigen Jahren, was die Bedeutung technologischer Entscheidungen und den Wert eines strategischen Ansatzes unterstreicht.

[hhcrux]

230.000 Dollar … Ist das nicht ein Betrag, der schon verpufft, wenn man nur zwei Administratoren für die Betreuung von Colocation-Servern einstellt? Genau deshalb nutzt man doch vollständig gemanagte Services: um sich diese Kosten zu sparen.

[gunrok]

Das stimmt zwar, aber der Haken ist, dass man auch bei AWS je nach Bereich Experten benötigt.

[wedding]

Die Bewertungen sind insgesamt eher negativ. Wenn man sich die Zusammenfassung ansieht, wirkt sie irgendwie auch etwas übertrieben.

[GN⁺]

Hacker-News-Kommentare

• Mit Reserved Instances und Savings Plans lassen sich die AWS-Kosten erheblich senken. Das gilt auch für Transfer- und Speicherkosten, und tatsächlich kann man viel sparen, aber der Unterschied ist nicht ganz so dramatisch, wie zunächst gedacht.
• Angesichts der aktuellen Wirtschaftslage sagen viele: „Davon kann man einen zusätzlichen Engineer einstellen“, aber man sollte sich klarmachen, dass es auch darum geht, „einen Engineer zusätzlich behalten zu können“. Die Frage ist, ob man Teammitglieder entlassen würde, nur um AWS weiter zu betreiben.
• Ein Server-Rack zu betreuen ist nicht so eine große Sache, wie viele denken. Cloud-native Engineers sträuben sich oft dagegen, etwas über Hardware-Management zu lernen.
• Wenn man keine Cloud-Services nutzt und einfach nur virtuelle Maschinen betreibt, ist das nur selten wirklich sinnvoll. Für viele kann das Mieten dedizierter Server die beste Geschäftsentscheidung sein. Das kann deutlich günstiger als EC2 sein, und wenn man viel Reservekapazität hat, lassen sich die üblichen Skalierungsprobleme damit lösen.
• Man sollte sich auf die Geschäftsziele konzentrieren und sich nicht vom Hype mitreißen lassen. In manchen Fällen ist Downtime ein großes Problem, aber für viele Unternehmen sind ein paar Minuten Serviceausfall viel günstiger als die Entwicklung komplexer und teurer Hochverfügbarkeitsmechanismen (HA).
• Wenn man bei AWS statt eines Ferrari einen Toyota Camry kauft, kann man viel Geld sparen. Solche Geschichten sind meist Blog-Spam, in dem Unternehmen behaupten, ihnen sei ein erstaunlicher neuer Hack gelungen. In Wirklichkeit verbrennen sie Geld, weil sie nicht wissen, wie sie ihre Ausgaben kontrollieren sollen.
• Es kommt einem vor, als hätte man erst gestern noch nach einem Colocation-Anbieter gesucht, daher wirkt die Behauptung fragwürdig, man habe so schnell 230.000 US-Dollar eingespart.
• Wenn man bei der Kosten-Nutzen-Abwägung nicht ein Personenjahr Aufwand in den Betrieb eigener Server steckt, war es die richtige Entscheidung.
• Der Beitrag bleibt bei den Details sehr oberflächlich, sodass sich schwer beurteilen lässt, ob das Ganze tatsächlich sinnvoll ist.
• Unternehmen existieren, um Geld zu verdienen, und das Geld kommt durch das Produkt herein, nicht durch Fähigkeiten im Management von Hardware und IT-Infrastruktur.
• Wenn man bei AWS 500.000 US-Dollar pro Jahr ausgibt, kann es durchaus sinnvoll sein, die Cloud zu verlassen, sofern die Infrastruktur vergleichsweise einfach ist und nicht zu erwarten steht, dass die Ausgaben stark steigen.
• Wenn man bei AWS 500.000 US-Dollar pro Jahr ausgibt, reicht es schon, die Beträge in ein Excel-Sheet einzutragen und eine Stunde lang zu prüfen, um offensichtliche Einsparmöglichkeiten zu erkennen — und das hätte man tun sollen, bevor man bei AWS Hunderttausende Dollar pro Jahr ausgibt.