- Erfahrungsbericht eines Entwicklers, der von AWS auf eigene Server migriert ist und die monatlichen Infrastrukturkosten auf ein Zehntel gesenkt hat: von 1.400 Dollar auf 120 Dollar bei stärkerer Serverleistung
- Bare-Metal-Server von Anbietern wie Hetzner kosten bei 80 Kernen rund 190 Dollar im Monat und sind damit 7- bis 18-mal günstiger als vergleichbare Instanzen bei AWS
- Der Grund, warum Cloud-Ingenieure den Betrieb eigener Server ablehnen, liegt in Jobsicherheit und der Abhängigkeit von komplexer Infrastruktur; die tatsächlichen Kosten trägt schließlich der Arbeitgeber
- Die meisten kleinen Unternehmen brauchen keine Enterprise-Funktionen wie Hochverfügbarkeit, Multi-Zone-Replikation oder automatisches Failover; ein einzelner Server kann bereits mehrere Millionen Requests pro Tag verarbeiten
- Serverbetrieb bleibt nach der Ersteinrichtung stabil, und mit Hilfe von AI-Tools ist die Einstiegshürde für den Betrieb von Linux-Servern so niedrig wie nie zuvor
Beispiele für reduzierte Cloud-Kosten
- Kürzlich wurden alle Projekte aus der Cloud migriert, wodurch die monatlichen AWS-Kosten um den Faktor 10 gesenkt und Tausende Dollar eingespart wurden
- Die monatliche AWS-Rechnung sank von rund 1.400 Dollar auf unter 120 Dollar
- Gleichzeitig wurde leistungsstärkere Server-Infrastruktur zu geringeren Kosten erreicht
- Die Performance verdoppelte sich, und die Abhängigkeit vom Anbieter entfiel
- Als dieser Tweet viral ging, zeigten sich zwei Dinge: Viele Entwickler interessierten sich für die Methode, und viele andere reagierten mit starker Ablehnung und konfrontativem Verhalten
- Aus Geschäftssicht wurden offensichtliche Vorteile erzielt — zehnmal niedrigere Kosten, doppelte Performance und weniger Vendor Lock-in — und trotzdem gab es heftigen Gegenwind
Die Interessen der Cloud-Befürworter
- Die meisten Kritiker hatten in ihrem Profil Begriffe wie "devops", "cloud engineer", "serverless guy", "AWS certified" stehen
- Sie betreiben ihre eigenen Projekte nicht in der Cloud und zahlen die Cloud-Kosten nicht selbst
- Die AWS-Rechnung ihres Arbeitgebers ist ihnen egal; den Schmerz verschwendeter Tausender Dollar pro Monat spüren sie nicht
- Warum AWS für sie bequem ist
- Es wirkt technisch komplex und lässt sie vor anderen Entwicklern klüger erscheinen
- Es schafft Abhängigkeiten und Lock-in-Effekte, die sie als Mitarbeiter schwer ersetzbar machen
- Weil Cloud-Nutzung hohe Gehälter absichert, haben sie keinen Anreiz, Entscheidungen zu treffen, die für das Unternehmen effizient sind
- Im Gegenteil: Je komplexer und undurchsichtiger die Infrastruktur eines Unternehmens ist, desto sicherer wird ihr Arbeitsplatz
- Sie werden die Wahrheit, dass Server in Wirklichkeit günstig sind, nicht aussprechen
Günstige Optionen zum Mieten von Servern
- Umzug zu Hetzner (keine Partnerschaft, einfach nur günstige Server)
- Ein Bare-Metal-Server mit 80 Kernen ist für unter 190 Dollar im Monat zu mieten
- Vergleichbare Instanzen der C5-/C6-Reihe bei AWS kosten 2.500 bis 3.500 Dollar im Monat und sind damit 13- bis 18-mal teurer
- Selbst mit Reserved Instances liegen die Kosten noch bei rund 1.300 Dollar im Monat, also immer noch 7-mal höher, dazu kommen 46.000 Dollar Vorauszahlung und ein 3-Jahres-Vertrag
- Auch VPS-Optionen sind attraktiv
- Maschinen mit 48 vCPU gibt es für 300 Dollar im Monat, ohne Setup-Gebühr oder Langzeitvertrag und mit voller Flexibilität
- Eine Maschine mit 8 Kernen und 32 GB RAM kostet 50 Dollar im Monat und kann — sofern nicht mehrere Millionen Requests täglich anfallen — alle Projekte gleichzeitig betreiben
Server kaufen und Rechenzentren nutzen
- Langfristig ist der Kauf von Servern günstiger
- Ein Rack-Server mit 44 CPU, 256 GB RAM und 2 TB NVMe SSD lässt sich für unter 1.000 Dollar kaufen
- Damit kann eine App jahrelang für weniger Geld betrieben werden als die monatlichen Cloud-Kosten betragen
- Optionen zum Mieten von Rack-Fläche im Rechenzentrum
- Es lässt sich ein Cage oder Shared Rack Space in einem Rechenzentrum mieten, inklusive Strom, Internet, Kühlung und Sicherheit
- Über Websites wie DatacenterMap kann man Rechenzentren in der Region finden
- Für kleine Entwickler ist das oft zu komplex
- Man muss Ingenieure einstellen und Preise verhandeln, was umständlich ist
- Es richtet sich meist an mittelgroße bis große Unternehmen und ist für kleine Teams unpraktisch
- Praktisch entspricht es dem Mieten bereits montierter Server bei Anbietern wie Hetzner, nur ohne den Aufwand für die Hardware-Verwaltung
Entgegnung auf die Kritik „Ist das nicht immer noch Cloud?“
- Die häufigste Kritik lautet: "Ist das nicht immer noch Cloud?" oder "Du hast die Cloud gar nicht verlassen, sondern nur den Cloud-Anbieter gewechselt."
- Diese Kritik verfehlt den Kern
- Entscheidend ist der Unterschied zwischen dem Betrieb eigener Server und der Selbstverständlichkeit, immer Cloud zu wählen
- Wer eine kleine Linux-Maschine betreibt und damit teure Managed Services wie RDS ersetzt, zahlt 10- bis 100-mal weniger
- Die meisten Entwickler haben Angst vor Servern und brauchen nur etwas Ermutigung, um günstige eigene Server einzurichten
- In der Praxis braucht fast niemand die teuren Managed Services der Cloud; einige Linux-Boxen mit Standardsoftware reichen in den meisten Fällen aus
- Die Debatte über Bezeichnungen verschleiert das Wesentliche
- Ob VPS, Bare Metal, On-Premises oder Colocation — die Bezeichnung ist nicht wichtig
- Server müssen irgendwo stehen; wichtig ist, ob mehr Geld in der eigenen Tasche bleibt oder an Amazons Aktionäre geht
- Wer so argumentiert, übernimmt im Grunde die Rolle eines Gatekeepers
- "So macht man es nicht richtig; du musst auch noch den Switch selbst kaufen, das Rack selbst bauen und die Ethernet-Kabel selbst anschließen"
- Das ist eine toxische und faule Argumentation, die sich an oberflächlichen Details festbeißt und dem eigentlichen Punkt ausweicht
Cloud-Kosten sind grundsätzlich teuer
- Gaslighting-Versuche von Cloud-Befürwortern
- "Du nutzt die Cloud falsch", "Sie ist nur teuer, weil du es falsch machst", "Man muss wissen, wie man die Cloud richtig benutzt"
- Diese Leute haben Alternativen nie selbst ausprobiert und keine echte Erfahrung damit, für ihre eigenen Projekte Server zu betreiben
- Der Autor kennt AWS gut und hat sogar für AWS-Zertifizierungen gelernt
- Es wurde geprüft, ob die Infrastruktur überprovisioniert war
- Es wurde geprüft, ob für ungenutzte Services gezahlt wurde
- Es wurde unzählige Stunden in AWS-Kostenoptimierung investiert, unter anderem mit dem Erfolg, eine AWS-Rechnung von über 5.000 Dollar pro Monat mehr als zu halbieren
- Serverless Computing, Reserved Instances und Ähnliches sind bekannt
- Reserved Instances verschärfen das Problem nur: Sie schaffen Vendor Lock-in und binden einen für drei Jahre
- Wer einen Ausstieg aus der Cloud erwägt, trifft mit einem 3-Jahres-Vertrag die schlechteste Wahl
- Fazit nach allen Versuchen: Die Cloud ist einfach zu teuer
Ursachen für den Widerstand
- Warum interessieren sich so viele Menschen so sehr dafür, ob Kosten gesenkt werden?
- Zwei zentrale Schlüsse
- Es geht um den Lebensunterhalt: Wenn genügend Menschen überzeugt werden, verlieren Leute in diesen Rollen möglicherweise ihre Jobs
- Irrationale Argumente aus Angst: In den letzten zehn Jahren war der Aufbau auf Cloud-Basis der Trend; dadurch entstanden Millionen Jobs für "devops"- und "cloud engineers". Wenn nun der Ausstieg aus der Cloud zum Trend wird, könnte das für viele Cloud-Spezialisten das Karriereende bedeuten
- Viele Entwickler wissen insgeheim, dass die Cloud nicht so gut ist wie anfangs versprochen
- Sie sehen, dass die AWS-Ausgaben ihres Arbeitgebers zehnmal höher sind als nötig, sagen aber trotzdem "passt schon"
- Sie wollen weder Manager verärgern noch das Risiko eingehen, Verantwortung übernehmen zu müssen
- Sie fürchten die politischen Kosten, wenn sie im Team der lautesten Person widersprechen
- AWS hat eine starke kultartige Anhängerschaft
- Zertifizierungen trainieren Menschen darauf, reale Sales-Pages und Produktbeschreibungen auswendig zu lernen
- Es gibt Evangelists, die statt Pragmatismus Dogmen vertreten
- Es wird Angst vor der Außenwelt geschürt (Server sind gefährlich! Sie skalieren nicht!)
- Die Rolle des "cloud engineer" wird zur Identität gemacht; der Einstieg ist leicht, der Ausstieg schwer
- Weil ihre Existenzgrundlage daran hängt, wiederholen AWS-Anhänger irrationale Argumente wie Glaubenssätze
- Sie wiederholen Punkt für Punkt Aussagen von AWS-Verkaufsseiten, ohne zu hinterfragen, ob sie tatsächlich gebraucht werden
- Weil es um ein Glaubenssystem geht, werden Menschen in solchen Debatten irrational
Die Geschichte der Cloud
- Früher betrieb jeder seine eigenen Server
- Auf VPS, bei Hosting-Diensten, auf Bare-Metal im Rechenzentrum, in einem dunklen Raum in der Firma oder zu Hause
- Jeder war daran gewöhnt und damit vertraut, sich per SSH auf Maschinen einzuloggen
- Anfang der 2010er begann eine Marketing-Psyops-Kampagne für die Cloud
- Dahinter stand ein gezielter Versuch, Enterprise-Technologie an Startups in frühen Phasen zu verkaufen
- Ziel war es, sie so früh wie möglich abhängig zu machen und später bei Finanzierung und Wachstum auszuschlachten
- Die Strategie von AWS
- Einführung von Credits speziell für Startups
- Teilnahme an Startup-Accelerators, um möglichst jedes Startup zu onboarden
- Der Trick war einfach: Beim Aufbau der Infrastruktur war alles extrem günstig oder kostenlos; sobald das Startup wächst, wird alles extrem teuer — und durch den Lock-in ist der Ausstieg schwer
- IBM Cloud verfolgte eine ähnliche Strategie (Veranstaltung 2014)
- Damals lief alles auf Heroku und funktionierte gut
- Die Frage war: "Was ist diese ganze Cloud eigentlich, und wie benutzt man sie?"
- Es wirkte, als wolle man etwas verkaufen, das gar nicht für einen selbst gedacht war
- Diese Unternehmen haben in den vergangenen Jahren Millionen Dollar in Cloud-Werbekampagnen gesteckt, um junge Startups zur Einführung von Enterprise-Technologie zu bewegen
- Das Nullzinsumfeld des vergangenen Jahrzehnts hat den heutigen Zustand zusätzlich begünstigt
- Inzwischen gibt es eine Gegenbewegung
- Vor allem angeführt von @dhh und der Rails-Community
- Sie wirkt im Kern erfrischend, richtig und näher an der Realität der meisten Software-Unternehmen
Für die meisten Unternehmen ist die Cloud unnötig
- Manche haben eine vollkommen verzerrte Vorstellung davon, wie echte Software-Unternehmen aussehen
- Sie denken aus der Perspektive der Fortune 500 und halten Enterprise-Anforderungen für den Standard
- Sie glauben, dass der Durchschnittsbetrieb Hochverfügbarkeit, Multi-Zone-Replikation, automatisches Failover, verteilte Kubernetes-Cluster und alle anderen Cloud-Funktionen braucht
- Tatsächlich brauchen das nur sehr wenige Software-Unternehmen
- Die meisten Unternehmen werden nach dem Potenzgesetz dauerhaft klein bleiben
- In den USA machen kleine Unternehmen 99,9 % aller Unternehmen aus
- In der Europäischen Union stellen KMU (unter 250 Mitarbeitenden) 99 % aller Unternehmen
- Die meisten Entwickler überschätzen ihren Skalierungsbedarf
- Die Schwelle, ab der etwas als "hoher Traffic" gilt, liegt viel zu niedrig
- Ein konkreter Referenzpunkt: Aktuell werden mit einem Setup aus 2 Servern mehrere Millionen Requests pro Tag für Millionen monatlicher Besucher verarbeitet
- Indie-Macher wie @levelsio betreiben alles auf einem einzelnen Server
- Die meisten Entwickler haben nie ein eigenes Projekt mit echten Nutzern und echtem Produktionstraffic auf einem einzelnen Server betrieben
- Auch die technischen Anforderungen werden überschätzt
- Nur eine winzige Minderheit von Software-Unternehmen braucht solche Funktionen, und diese haben dafür meist gute technische Gründe
- Bei Netflix etwa müssen enorme Mengen Video für Kunden weltweit transkodiert und gestreamt werden; deshalb braucht es verteilte Systeme, CDN und Edge Computing
- Wenn eine kleine App mit tausend Nutzern nur JSON-Objekte hin- und herschickt, ist all das völlig unnötig
- Viele Entwickler haben die magische Vorstellung, ihr eigenes Projekt sei so etwas wie Netflix
- Das ist Wunschdenken, nachvollziehbar, aber es führt zu falschen technischen Entscheidungen
- Sie glauben, Nutzer würden beim Tippen auf einen Button ein paar Millisekunden Verzögerung bemerken, und deshalb brauche es weltweit verteilte Server
Mit Servern wird es schon klappen
- Viele Menschen haben magische Vorstellungen davon, wie Rechenzentren funktionieren
- Sie glauben, Server in Rechenzentren seien fragil, volatil und könnten einfach in Luft aufgehen
- Manche glauben sogar, ein Blitzschlag könne ein ganzes Rechenzentrum zerstören
- Moderne Rechenzentren sind auf all diese Probleme vorbereitet und verfügen über zahlreiche Schutzmechanismen
- Schutz nicht nur gegen alltägliche Dinge wie Blitze, sondern gegen fast alles, was die Verfügbarkeit gefährden könnte
- Redundante Stromversorgung, redundante Kühlung, redundante Internetanbindung, redundante Löschsysteme, redundante Sicherheitssysteme sowie umfangreiche physische Sicherheit
- Alles im Rechenzentrum ist auf Resilienz und Redundanz (mindestens N+1, manchmal 2N) ausgelegt, um Uptime zu garantieren
- Diese Sichtweise ist vor allem angstgetrieben und das Resultat erfolgreicher Cloud-Marketing- und Psyops-Kampagnen
- Wo speichert AWS seine Maschinen denn — an einem magischen Ort unter dem Regenbogen?
- Wie sollen ausgerechnet AWS-Maschinen auf magische Weise vor Problemen geschützt sein, die andere Rechenzentren ebenfalls betreffen?
- Katastrophen können passieren (OVH-Brand 2021), deshalb braucht man Backups zur Wiederherstellung
- Aus rund 15 Jahren Serverbetriebserfahrung heraus sind solche Fälle selten; Ausfälle von mehr als ein paar Minuten gab es nie
Serverbetrieb ist kein Fulltime-Job
- Wer lange genug Server betrieben hat, weiß: Der meiste Aufwand steckt in der Ersteinrichtung, danach laufen Server meist relativ stabil
- Hardwareausfälle sind vergleichsweise selten, und wenn ein Server einmal läuft, funktioniert er oft jahrelang perfekt, ohne größere Eingriffe
- Der Betrieb eigener Server ist kein Fulltime-Job
- Man braucht kein Team aus fünf DevOps-Leuten
- Man muss auch keinen Server-Administrator einstellen: Man kann es selbst machen, und so schwierig ist es nicht
- Claude und ChatGPT verstehen Linux-Systeme und deren Verwaltung gut und können dabei helfen
- Nach dem Tweet meinten einige, dies sei der erste eigene Server und die Sicht auf Serverbetrieb sei zu optimistisch
- Tatsächlich gibt es Erfahrung im Serverbetrieb seit 2006
- Angefangen hat alles mit dem Bearbeiten von PHP-Skripten und dem Hochladen auf FTP-Server
- Danach kam das Lernen, wie man WordPress installiert, Templates anpasst, und von dort entwickelte sich alles weiter
- Diese Erfahrung war wertvoll und vermittelte die Grundlagen
- Es wurde gelernt, was Linux ist und wie man sich darin bewegt
- Bis 2007 wurden bei Canonical Ubuntu-CD-ROMs angefordert, per Post erhalten und auf einer Partition des elterlichen Computers installiert, um Linux zu lernen
- Diese frühen Erfahrungen vermittelten die Grundlagen der Webentwicklung, und alles Weitere baute darauf auf
Warum Linux zu lernen wichtig ist
- Die neue Generation von Entwicklern (Gen Z, Alpha) ist vollständig von der Hardware entkoppelt, auf der Software läuft
- Diese grundlegenden Erfahrungen fehlen
- Sie sind in einer Zeit aufgewachsen, in der irgendein zufälliger Mensch auf YouTube einen bestimmten Anbieter bewirbt und einen bestimmten Befehl zeigt, der alle Infrastrukturprobleme angeblich magisch löst
- Dass sie magische Annahmen darüber haben, was ein Server ist und wie er funktioniert, ist daher nachvollziehbar
- Sie glauben, mit "serverless" arbeiten zu können, merken aber nicht, dass sie ihren Code auf mehreren anderen Rechnern ausführen
- Natürlich lernen viele trotzdem mehr über Linux und Server, aber dem durchschnittlichen Bootcamp-Absolventen fehlt die praktische Linux-Erfahrung, die FTP-Hacker vor 20 Jahren oft hatten
- Das ist kein moralisches Urteil, weder gut noch schlecht — es ist einfach der aktuelle Zustand der Webentwicklung
- Das Ergebnis: Firmen wie Vercel verdienen Millionen Dollar mit einer neuen Entwicklergeneration, die nicht genau weiß, was sie tut und nie selbst Server betrieben hat
- Unwissen hat einen doppelten Preis: die Unwissenheit selbst und das Geld, das Menschen dafür zahlen, dass andere diese Unwissenheit ausnutzen
- Wer nicht weiß, wie Dinge funktionieren, zahlt am Ende real dafür
Jetzt ist die beste Zeit, Server zu lernen
- Auch wenn man noch nie eigene Server verwaltet hat und alles mit Backend-Geruch beängstigend findet, wird es schon klappen
- Tatsächlich gab es noch nie einen besseren Zeitpunkt, um Server souverän zu beherrschen
- Claude und ChatGPT kennen sich beide sehr gut mit Linux aus und können Schritt für Schritt helfen — in einer Form, die es in der Technikgeschichte so noch nie gab
- Man kann nicht nur lernen, wie man etwas einrichtet und wie es funktioniert, sondern bei Änderungen auch Fragen stellen und die Schritte befolgen, ohne jemanden einstellen zu müssen
- Es ist nicht so beängstigend und auch nicht etwas, das man ständig tun muss
- In einem AI-Zeitalter, in dem Codegenerierung Standard wird und Code zur Commodity werden kann, könnte das Wissen, wie man diesen Code auf günstigen Produktionsservern deployt und für Endnutzer tatsächlich nutzbar macht, zu einem zentralen Differenzierungsmerkmal für Entwickler werden
- Natürlich muss man sich um Dinge wie Sicherheit kümmern
- Wer behauptet, der Betrieb eigener Server sei unsicherer als der Betrieb von AWS-Servern, als würden EC2-Instanzen magisch vor Hackern geschützt, den kann man ignorieren
- In Wirklichkeit ist eine korrekte Konfiguration gar nicht so schwer, wenn man sich an Guides und Setup-Skripte hält
- Viele Entwickler arbeiten in Produktion deutlich schlechter als jemand mit AI-Unterstützung, obwohl sie mehr Erfahrung haben
- Wenn man ChatGPT fragt, wie man einen Linux-Server härtet und Security-Best-Practices wie keine Passwort-Authentifizierung und nur starke SSH-Keys umsetzt, ist man zu 90 % fertig
- Cloudflare bietet eine zusätzliche Schutzschicht
- Nachdem die Linux-Box abgesichert wurde, kann man alles über Cloudflare laufen lassen
- Wenn die Server-IP im DNS per Proxy verborgen bleibt, ist das ideal
- DDoS-Schutz, Edge-Caching und erstklassiges DNS gibt es im Grunde kostenlos
24 Kommentare
Wenn man den Zeit- und Arbeitsaufwand bedenkt, der dafür nötig ist, die erforderliche Infrastruktur On-Premises selbst aufzubauen, wirken Cloud-Services gar nicht so teuer.
Und Cloud-Dienste nutzt man wegen der hohen Verfügbarkeit, nicht wegen der Kosten.
Ich sehe das ein bisschen wie bei IKEA oder Daiso.
Es gibt sicher auch Cloud-Services, die ein sehr gutes Preis-Leistungs-Verhältnis haben und vernünftig bepreist sind.
Aber wenn man die nutzt, fängt man irgendwann auch an, die Sachen mitzubenutzen, die dann schon etwas teuer wirken.
(Nur ein grobes Beispiel:) Wenn man Lambda nutzt, verwendet man danach auch API Gateway, und das ist dann etwas teuer und unpraktisch -_-^
So läuft das eben.
Was ich übrigens sehr nachvollziehbar finde, ist:
Warum AWS für diese Leute praktisch ist
Es wirkt technisch komplex und lässt sie vor anderen Entwicklern schlau aussehen
Genau dieser Satz.
Ganz ehrlich: AWS-Services sind alt und wurden über lange Zeit weiterentwickelt, dabei gibt es etliche Funktionen, die nicht einmal deprecated werden konnten. Sich damit gut auszukennen wirkte cool, deshalb habe ich damals auch die SA-Zertifizierung gemacht, haha ... dem stimme ich total zu~~
Cloud, On-Premises und IDC haben jeweils ihre Vor- und Nachteile; entscheidend ist letztlich, je nach Einsatzzweck und Größenordnung die passende Wahl zu treffen.
Die größte Prämisse ist, dass "Hardware-Ausfälle fast nie vorkommen" ...
Nach meiner Erfahrung sind damals, als wir im Unternehmen ein Rack im IDC gemietet und Server betrieben haben, im Schnitt alle drei Tage Festplatten gestorben,
weshalb ich ständig unterwegs war, um Platten zu tauschen und RAID wiederherzustellen ...
Wenn es irgendwie geht, sage ich einfach: Nutzt die Cloud.
Wie groß der Wert ist, bei einem Hardware-Ausfall alles mit einem "Klick" wieder hochzufahren ...
Dass alle drei Tage einmal eine Festplatte ausfällt, ist schon etwas seltsam...
Ich glaube nicht, dass das ein typischer Fall ist.
Das ist eine Geschichte von vor über 10 Jahren, und vermutlich war es Seagate..
Backblaze hat angekündigt, dass im letzten Jahr 4372 Laufwerke ausgefallen sind; bei dieser Größenordnung fällt also ungefähr alle 2 Stunden ein Laufwerk aus ...
Das ist eine Häufigkeit, die bei sehr großem Maßstab auftreten kann.
Nun ja, ich habe ziemlich lange in einem Rechenzentrum mit etwa 100 42U-Racks gearbeitet, in einer Umgebung mit HPC, HCI, einem mit frühem Hadoop aufgebauten verteilten Dateisystem und allen möglichen Storage-Systemen, aber ich habe nie erlebt, dass dort alle drei Tage eine Festplatte ausgefallen ist.
Hacker-News-Kommentare
Ich betreibe seit Jahren eigene Server und halte alles bewusst einfach, wodurch ich viel Zeit und Geld spare.
AWS oder Azure meide ich, weil die Einrichtung komplex ist und die UI auch nicht besonders gut ist.
Wichtig ist, Server so zu verwalten, dass sie sich jederzeit nur anhand von Konfigurationsdateien wiederherstellen lassen. Deshalb sind Tools wie Ansible unverzichtbar.
Wenn man unbedingt Cloud nutzen muss, empfehle ich DigitalOcean. Es ist simpel und intuitiv, was der psychischen Gesundheit guttut.
Ich nutze DO nur für Disaster Recovery auf Stufe 3 und konfiguriere Cluster automatisch mit Terraform und Ansible.
Die meisten Entwickler-Communitys neigen dazu, Trends hinterherzulaufen, aber ich erwirtschafte selbst in so einem Umfeld stabile Einnahmen, indem ich einen JVM-basierten Clojure-Monolithen auf meinem physischen Server-Cluster deploye.
ulimit-Einstellungen, Performance-Probleme mit SYN-Cookies, Sicherheitsupdates, Reaktionen auf Zero-Day-Angriffe, E-Mail-Versand (IP-Warming, Verwaltung von Spam-Listen), DSGVO-Compliance usw.All das liegt dann in meiner Verantwortung, und Leute, die Cloud nutzen, sind nicht einfach nur „hereingelegt worden“.
Ich mag kein Schwarz-Weiß-Denken. Die meisten Startups können viel Geld sparen, wenn sie statt EC2 zu Anbietern wie Hetzner, Linode oder DigitalOcean wechseln.
Aber Cloud hat auch viele Vorteile — Funktionen wie Backups, Managed Databases, Multi-AZ lassen sich mit ein paar Klicks nutzen.
Es gibt keine anfänglichen Hardware-Investitionen, und bei hoher Spitzenlast kann es am Ende sogar günstiger sein.
Da Engineering-Zeit jedoch sehr wertvoll ist, kann Cloud in einer Phase schnellen Wachstums sinnvoll sein.
Letztlich ist Cloud nicht deshalb teuer, weil sie teuer ist, sondern weil man unnötige Funktionen nutzt.
Es gibt viele Beispiele, in denen eine Multi-Cloud-Strategie Katastrophen verhindert hat.
Auch VPS oder dedizierte Server haben kaum Anfangskosten, und solange die Spitzenlast nicht extrem ist, ist Cloud nicht zwangsläufig günstiger.
Managed Databases sind bequem, aber es gibt viele erzwungene Upgrades, und wenn es nicht um große Größenordnungen geht, halte ich Selbstverwaltung für besser.
Früher war Hardware-Skalierung schwierig, aber heute kann schon ein einzelner Server die Leistung erbringen, für die man früher ein ganzes Rack brauchte.
Projekte mittlerer Größe können Probleme, die früher Cloud lösen musste, inzwischen selbst bewältigen.
Allerdings ist externe personelle Unterstützung mit Cloud viel einfacher zu bekommen, während es bei Self-Hosting schwer ist, Support-Personal zu finden.
Ich persönlich bevorzuge Self-Hosting, aber für Leute, die Infrastruktur nicht selbst anfassen wollen, ist Cloud wohl die bessere Wahl.
Früher war ich bei einem Hedgefonds-Startup für die IT zuständig.
Wir ließen ein C++-Analyseprogramm auf einem Dual-Xeon-Server (512 GB RAM) laufen, aber der Chef wurde nervös, nachdem er beim Mittagessen gehört hatte: „Warum nutzt ihr nicht AWS?“
Ich habe erlebt, wie „Buzzword-Compliance“ wichtiger genommen wird als Effizienz.
Viele CTOs geben wegen dieser Stimmung unnötig große Budgets aus, und in einer solchen Welt wird eine effiziente Architektur sogar zu einer Marketing-Schwäche.
Der Ausdruck „10x sparen“ ist logisch falsch. 10x bedeutet, dass es mehr ist.
Wichtiger als Serverkosten sind die Wartungs- und Arbeitskosten.
Selbst wenn man 10 EC2-Instanzen betreibt, kann man mit Systems Manager automatische Patches einspielen, ohne eigene Automatisierung bauen zu müssen.
Die Cloud-Debatte ist nicht schwarz-weiß.
Bei kleinen Setups sind Hetzner und AWS ziemlich ähnlich, und bei großen Unternehmen ist entscheidend, ob sie eigene Tooling bauen können.
Der Bereich der mittelständischen Unternehmen (SME) ist am unklarsten. Wenn man für jeden Kunden komplett getrennte Systeme braucht, ist AWS im Vorteil; bei konstanter 24/7-Last sind eigene Server besser.
Wenn man Cloud nur für VM-Hosting nutzt, ist das ein Verlustgeschäft. Oft nutzt man die Cloud-Funktionen gar nicht und zahlt nur die Kosten.
Eigene Server müssen den ganzen Monat für Maximalkapazität bezahlt werden, während man in der Cloud nur die paar benötigten Tage zahlt.
Cloud ist sehr nützlich für den Aufbau eines MVP und die Validierung des Markts.
Mit Startup-Credits und Free Tiers kann man schnell experimentieren und später umziehen, wenn die Kosten zum Problem werden.
Allerdings muss man von Anfang an eine serverunabhängige Architektur entwerfen, und es ist schwer, genug Zeit für eine Migration freizuhalten.
Unser Team nutzt Google Cloud, aber unsere Ausgaben sind so gering, dass der Vertrieb unzufrieden ist.
Die Möglichkeit, zwischen Clouds zu wechseln, wirkt als Verhandlungsmacht.
Außerdem erleichtert Cloud die Einhaltung von SLAs und Datenschutzvorgaben und ist damit hilfreich, das Vertrauen von Unternehmenskunden zu gewinnen.
Ich frage mich, warum AWS anfangs so explosionsartig gewachsen ist.
Anfang der 2010er waren Rack-Miete und Serveraufbau teuer und langsam, und Multi-Region-Setups waren fast unmöglich.
AWS hat diese Probleme gelöst, aber inzwischen hat sich die Lage verändert.
Es gab auch die Anekdote, dass Squarespace während Hurrikan Sandy mit eigenem Treibstoff seine Server am Leben hielt.
Bei Hetzner kann man einen Server bestellen und 10 Minuten später Ubuntu installieren und Ansible einrichten.
Fester Preis, unbegrenzte Bandbreite, vorhersehbare Performance — die Einfachheit ohne unnötige Abstraktion ist der Reiz.
EC2 hat diesen Aufwand beseitigt, und Lambda ging noch einen Schritt weiter. Inzwischen ist Bare-Metal-Miete viel günstiger geworden.
Die frühere Politik von AWS mit kostenlosen Credits war faktisch eine Lock-in-Strategie.
Eigene Server in ein Rechenzentrum zu stellen, ist weniger schwer, als man denkt.
Ich brauchte für einen Gaming-Server eine CPU mit hohem Takt, die in der Cloud schwer zu bekommen war, also habe ich selbst aufgebaut.
Der Betrieb kostete inklusive Einrichtungsgebühr etwa 15 £ im Monat und lief über Jahre hinweg gut. Insgesamt war das eine erhebliche Kostenersparnis.
Man platzierte Geräte in einem Rechenzentrum in Seattle und verwaltete sie remote über ein modembasiertes KVM.
Wir sind vor einigen Jahren zu Hetzner migriert und werden dank der Einsparungen wohl nicht mehr zur Cloud zurückkehren.
Eine Ausnahme sind Cloudflare Workers; die Qualität ist gut und das kostenlose Kontingent großzügig.
Dank KI ist es viel einfacher geworden, Automatisierungs-, Deployment- und Backup-Skripte zu schreiben, wodurch die Verwaltung einfacher ist als früher.
Zur Info: Anthropic Claude Code bietet Pro-/Max-Nutzern bis zum 18. November 250 $ kostenlose Credits an.
Die entsprechende Ankündigung findet sich in diesem Tweet.
Wenn man auch nur einmal eine Backup-Wiederherstellung erlebt hat, merkt man den Wert davon wahrscheinlich, oder? On-Premises ist bei Backup-Wiederherstellungen am nervigsten.
Nun ja … Ich stimme voll und ganz zu, dass „Cloud-Kosten unnötig teuer sind“ und dass man „in den meisten Fällen die Funktionen der großen Cloud-Anbieter nicht braucht“, aber der Tonfall lässt den Text unangenehm zu lesen wirken, als wolle er behaupten, Cloud-Dienste seien allesamt Betrug. Es klingt, als würde man sagen: „Versicherungsprodukte sind allesamt Betrug.“
Die Cloud nutzt man, wenn man Server nicht selbst verwalten will oder wenn sich die Nachfrage nur schwer vorhersagen lässt und man deshalb schnell skalieren muss. Darüber hinaus weiß ich nicht, ob andere Einsatzfälle wirklich sinnvoll sind.
Ich stimme allem zu, aber es ist schade, dass aus der Sicherheitsperspektive nichts darüber gesagt wird, wenn man einen eigenen Server direkt über Jahre hinweg betreibt.
Dem stimme ich ebenfalls zu.
Stimmt.
Ich stimme zu hundert Prozent zu, dass die Cloud teuer ist.
Wenn man aber daran denkt, jetzt mehr als 200 Container auf Bare Metal selbst mit Kubernetes einzurichten und zu betreiben,
und man als alleiniger Backend-Entwickler ohne DevOps arbeitet und bedenkt, dass sich der Aufwand für Serververwaltung und -betrieb für weniger als ein Viertel der Personalkosten einer einzelnen Stelle reduzieren lässt, dann ist das durchaus keine schlechte Wahl.
Wenn es allerdings jemanden gibt, der nur das Server-Infrastrukturmanagement übernimmt, dann kann ein Abschied von der Cloud durchaus eine gute Option sein.
Ich persönlich fand es zum Verrücktwerden, einen Service aufzubauen und dabei die Cloud so weit wie möglich auszuklammern.
Ich brauchte ein Container-Image-Repository, aber als ich es selbst aufsetzen wollte, war lokaler Storage eine Belastung. Also habe ich mich der Einfachheit halber für Backups nach einer S3-kompatiblen Lösung umgesehen, einen VPN-Dienst aufgesetzt, um externen Zugriff zu blockieren, und mich zusätzlich noch um die Verwaltung von HTTPS-Zertifikaten am Reverse Proxy sowie um diverse Einstellungen für die Sicherheit von CI/CD kümmern müssen ... selbst aufbauen eben ...
Wenn man in der Cloud nur ein paar einfache Dienste nutzt, ist Bare Metal natürlich günstiger, und dann ist das vermutlich auch die richtige Wahl. Wenn man aber Anbindungen an andere Dienste braucht und sich verschiedene Aufwände vom Hals schaffen will, kann es trotz aktuell höherer Serverkosten ein Vorteil sein, dass man solche Dienste nicht einzeln von Hand aufbauen muss, weil dadurch Installations- und Verwaltungskosten wegfallen.
Es gibt viele Open-Source-Image-Repositories.
Ja, viele. Ich meinte die Belastung, die ein eigener Betrieb mit sich bringt. Ich nutze auch Nexus oder Harbor.
Ich hatte aufgrund persönlicher Erfahrungen weder eine Belastung noch Probleme.
Da die Maßstäbe dafür unterschiedlich sein können, könnte man das durchaus so sehen.
Für welchen Service entwickeln Sie, dass Sie ein Container-Image-Repository benötigen?
Das liegt daran, dass ich unabhängig davon, welchen Service ich entwickle, die Bereitstellung per Container bevorzuge. Auch bei Deployments ziehe ich es vor, direkte SSH-Verbindungen möglichst zu vermeiden. Wenn man nur an die Kosten denkt ... gäbe es vermutlich auch Möglichkeiten, direkt ohne Registry zu deployen, aber das war nur ein Beispiel, und ich möchte den Fokus eher auf die Unannehmlichkeiten legen, die dadurch entstehen, etwa bei E-Mail-Diensten.