Flexibilität, schnelle Skalierung bei Lastspitzen und niedrigere Kosten – das sind die Versprechen der Cloudanbieter. Mit dem Anmieten von Servern ist es aber nicht getan: Wer in die Cloud umzieht, sollte Anwendungen und Gewohnheiten anpassen. Nur dann profitiert man wirklich von der Cloudinfrastruktur.
Von
Jan Mahn
Dass Betreiber von Rechenzentren ihre Server vermieten, ist kein neues Geschäftsmodell, sondern seit Jahrzehnten üblich. Unter Bezeichnungen wie „Root-Server“, „vServer“ oder „Dedicated Server“ bekommt man ganze physische Server oder virtuelle Maschinen mit unterschiedlich viel zugesicherten Ressourcen bei zahlreichen Anbietern. Darauf läuft meist eine Linux-Server-Distribution, manchmal auch Windows Server. Einsetzen kann man die Maschinen für unterschiedlichste Serversoftware, vom Webserver über eine Videokonferenzsoftware bis zur KI-gestützten Datenauswertung. Gemein ist diesen Angeboten, dass man auf dem Server die volle Kontrolle über das Betriebssystem hat und nach Belieben Software installieren darf. Das unterscheidet das Serverhosting vom Webhosting – dort gibt es einen vorinstallierten Webserver (und oft einen SQL-Datenbankserver) und als Kunde darf man nur Dateien fürs eigene Webangebot in einem Ordner ablegen.
Üblich sind beim Serverhosting eher lange Vertragslaufzeiten: Mindestens einen Monat, gerne auch 12 oder 24 Monate muss man dem Vermieter treu bleiben und den Server nutzen. Der Wechsel auf ein anderes Paket, zum Beispiel mit mehr Leistung, ist meist mit Kosten oder gar manuellem Umzugsaufwand verbunden. Oft verlangen die Anbieter einen Obolus für die Ersteinrichtung.
Ab etwa 2010 nahm dann ein neues Geschäftsmodell Fahrt auf: Cloud Computing. Von den Marketingabteilungen wurde der Begriff seitdem inflationär benutzt und auch IT-Laien, die nie in Verlegenheit kommen würden, selbst Server zu mieten, haben schon von „der Cloud“ gehört. Dabei ist der Kern der Idee derselbe wie beim klassischen Hosting – vermietet werden vor allem Server, aber auch Speicherplatz oder gleich fertig installierte und vom Anbieter gepflegte Serverdienste wie zum Beispiel Datenbanken.
Minutenpreise
Der große Unterschied ist das Abrechnungsmodell: Abgerechnet wird bei Cloudanbietern in Sekunden, Minuten oder Stunden, nicht in Monaten oder Jahren, und die Mindestlaufzeit liegt oft nur bei einer Minute. Die Vermieter haben die Prozesse auf Basis von gängigen Virtualisierungstechniken so automatisiert, dass ein virtueller Server innerhalb von wenigen Sekunden einsatzbereit ist. Damit werden ganz neue Einsatzbereiche möglich: Ein Ingenieur beispielsweise, der für die Berechnung eines mathematischen Modells nur eine halbe Stunde am Tag eine Hochleistungsmaschine mit 12 Prozessorkernen und 64 GByte RAM braucht, kann eine solche in der Weboberfläche eines Cloudanbieters bestellen, darauf seine Berechnung ausführen und die Maschine nach 30 Minuten wieder löschen. Für ein paar Euro bekommt er so Rechenleistung, für die er sich sonst teure Hardware ins Büro stellen müsste.
Aber auch Dienste, die rund um die Uhr laufen, profitieren von der Flexibilität in der Cloud – bestes Beispiel ist ein typischer Webshop, der im Zeitraum von Ende November bis zum 24. Dezember im Weihnachtsgeschäft mehr Kunden bedienen muss als im restlichen Jahr zusammen. Mit einem klassischen virtuellen Server in einem langfristigen Tarif würde er in elf von zwölf Monaten für eine Infrastruktur bezahlen, die kaum ausgelastet ist, weil sie auf den Ansturm des Weihnachtsgeschäfts ausgelegt ist. Das lohnt sich nur für den Vermieter. Bei Cloudanbietern dagegen könnte der Händler die Ressourcen, die seiner gemieteten virtuellen Maschine zugewiesen werden, Mitte November in Erwartung des Adventsansturms anpassen und nur bezahlen, was auch gebraucht wird.
Milliardengeschäft
Mit dem Mieten von Servern ist es nicht getan. Bis Anwendungen stabil bei Cloudanbietern laufen, sind viele Probleme zu lösen. Eine Übersicht über Open-Source-Werkzeuge liefert das Angebot landscape.cncf.io.
Dieses Modell ist für Kunden wie Anbieter gleichermaßen attraktiv. Allein im ersten Quartal 2021 hat Amazon mit seinen Clouddiensten „Amazon Web Services“ (AWS) 13,5 Milliarden US-Dollar umgesetzt. Seit 2014 konnte das Unternehmen den Umsatz in jedem einzelnen Quartal steigern. Entgegen der landläufigen Meinung bedeutet Cloud-Computing aber nicht zwangsläufig, sich in die Abhängigkeit von einem der drei großen US-Anbieter Google Cloud, Amazon AWS und Microsoft Azure zu begeben. Auch europäische und deutsche Anbieter vermieten Server, Speicherplatz und Datenbanken zum Minutenpreis – und für die DSGVO-konforme Datenverarbeitung in deutschen Rechenzentren müssen Sie nicht einmal mehr zahlen. In der Marktübersicht ab Seite 62 erfahren Sie, was Sie bei EU-Anbietern fürs Geld bekommen und worauf Sie neben dem Minuten- oder Stundenpreis noch achten sollten.
Bei Unternehmenskunden ist die Flexibilität der Cloudanbieter beliebt: Für den im Juni 2021 veröffentlichten „Cloud-Monitor 2021“ befragte die Unternehmensberatung KPMG im Auftrag des Branchenverbands Bitkom über 550 deutsche Unternehmen nach ihrer Cloudnutzung. 82 Prozent gaben an, schon Clouddienste zu nutzen, 15 Prozent diskutieren und planen noch. 2016 waren es noch 65 Prozent Nutzer und 18 Prozent Planer. Cloudcomputer machen eigene Server meist nicht überflüssig: Nur 5 Prozent der befragten Unternehmen, die die Cloud verwenden, setzen auf eine Cloud-Only-Strategie, immerhin 31 Prozent haben eine Cloud-First-Strategie, versuchen also, neue Dienste primär auf Mietservern zu betreiben. Bemerkenswert an der Studie: 33 Prozent der Cloud-Kunden gaben an, keine Strategie zu verfolgen.
Vorteile ausnutzen
Dabei ist eine Strategie dringend empfohlen, bevor man aus dem eigenen Rechenzentrum in „die Cloud“ umzieht. Wenn man einfach die bisher im eigenen Haus oder beim Hoster laufenden Server zu einem Cloudanbieter umtopft, hat man nämlich nichts gewonnen.
Zum Umstieg gehört ein neuer Blick auf Server: Früher haben Administratoren ihre Server behandelt wie Haustiere. Die Maschinen hatten originelle Namen, wurden über Jahre gepflegt und bestenfalls von Betriebssystemversion zu Betriebssystemversion aktualisiert. Ging es ihnen schlecht, wurde der Fehler gesucht und ausgetrieben. Konfigurationsdateien wurden von Hand liebevoll aufgepäppelt. Ins Backup kamen nicht nur die anfallenden Daten, sondern gleich ein Abbild der ganzen Maschine. In vielen Umgebungen stehen noch immer solche individuell hergerichteten Einzelstücke, die um jeden Preis am Leben erhalten werden müssen – weil sie eine wichtige Aufgabe erfüllen, aber niemand mehr genau weiß, welche Komponenten darauf in welcher Version installiert und konfiguriert werden mussten. Die Admins hängen daran wie an einem vergreisten Haustier, das astronomische Tierarztrechnungen verursacht. Das hat oft fatale Folgen: Diese Altlasten laufen gern mit hoffnungslos veralteten Betriebssystemen, weil sich niemand ans Upgrade traut. Änderungen müssen zwangsläufig im Produktivsystem ausprobiert werden, weil man keine Testumgebung mit vergleichbaren Bedingungen aufbauen kann.
Dem gegenüber steht der neue Ansatz, der vor allem im Cloudumfeld verbreitet ist: Server werden nicht wie Haustiere, sondern wie Nutzvieh behandelt. Sie sind ersetzbar, müssen nur fleißig ihren Zweck erfüllen. Sie werden nicht gepflegt, sondern ausgetauscht, wenn sie schwächeln oder Ärger machen. Das funktioniert aber nur, wenn man seine Administrationsgewohnheiten ändert. Statt einen Server direkt per SSH oder RDP mit Klicken und Tippen zu verwalten, schreibt man reproduzierbare Rezepte, die jeden einzelnen Administrationsschritt enthalten. Diese Rezepte lagert man außerhalb der Server – das können im einfachsten Fall einfache Skripte sein, einfacher wird die Arbeit mit Anwendungen wie Ansible. Weiter vereinfachen kann man sich das Leben, wenn man die Software auf den Servern noch in Container steckt und diese mit Docker oder Kubernetes ausführt. Im Kasten unten finden Sie kurze Erklärungen zu Software, die die Umsetzung einer Cloudstrategie einfacher macht.
Aber nicht nur die Servereinrichtung, auch die Serverbestellung muss reproduzierbar sein: Die Cloudanbieter haben zwar alle Weboberflächen mit Bestellformularen für neue Server – diese nutzt man aber am besten so wenig wie möglich. Als professioneller Cloudkunde besucht man die Webseite nur am Anfang, um einen Account zu erstellen und die Kontaktdaten zu hinterlegen. Danach spricht man mit dem Anbieter nur über ein API – ebenfalls per Skript oder Ansible. Diese Art der Arbeit ist am Anfang ungewohnt: Anstatt eine Umgebung an einem Stück einzurichten und nebenbei zu dokumentieren, tüftelt man einige Tage an den Rezepten, bestellt immer mal wieder Testserver, vernichtet sie wieder und bestellt neue.
In einer perfekten Welt hat man am Ende der Arbeit eine Rezeptsammlung, die alle wesentlichen Schritte enthält: Mit einem Befehl auf der Kommandozeile werden dann je nach Anforderung drei oder dreihundert Server bestellt, DNS-Einträge angelegt, mit Docker oder Kubernetes ausgestattet und die Container mit der Anwendung gestartet. Zugegeben, bis dieser Pfad reibungslos funktioniert, vergeht etwas mehr Zeit, als wenn man die Server per Hand zurechtbiegt. Aber mit einem guten Rezept startet man auch eine Testumgebung innerhalb von wenigen Minuten ohne Handarbeit oder eine Demo-Umgebung oder eine weitere Instanz für neue Kunden oder ... Und auch ein Umzug von einem Cloudanbieter zum anderen sollte dann keine Panik verursachen: Rezept anpassen, ausführen und Anwendungsdaten kopieren.
Gut geplant
Ein Umzug von eigenen Servern in die Cloud will gut überlegt sein. Mit einer Hauruck-Maßnahme, bei der man alte Probleme auf neue Infrastruktur umzieht, ist niemandem geholfen. Die Techniken und Strategien aus dem Cloud-Native-Umfeld lohnen sich aber auch, wenn man seine Dienste weiterhin nicht aus der Hand geben will. Auch im eigenen Rechenzentrum kann es nicht schaden, wenn man flexibel bleibt.
Wie ein Unternehmen ganz ohne eigene Server eine Anwendung für den Einsatz in der Cloud vorbereitet und welche Probleme es zu lösen gibt, lesen Sie ab Seite 67 – hat man sich erst an die neue Admin-Arbeit gewöhnt, macht das Umziehen durchaus Spaß.
(jam@ct.de)
