Cloud-Dienste in der Praxis: fünf Szenarien, in denen die Cloud für das Unternehmen arbeitet

WebDisk-Blog · Kategorie: Cloud · Lesezeit: ~7 Minuten

Kurz gefasst:- Statt Allgemeinplätzen über den „Schlüssel zur Modernität“ – fünf konkrete Einsatzszenarien der Cloud im Unternehmen: Anwendungs-Hosting, Backups, Datenspeicher, Testumgebungen und saisonale Lastspitzen.- Der gemeinsame Nenner aller fünf: Ressourcen starten Sie dann, wenn sie gebraucht werden, und Sie zahlen für das, was Sie nutzen – statt vorab in Hardware „auf Vorrat“ zu investieren.- Ehrlich gesagt: Die Cloud ist nicht automatisch günstiger und nicht „von selbst“ sicher – wir schreiben auch darüber, wann sie sich nicht lohnt.

Der Server, der seit fünf Jahren die Unternehmenssysteme stemmt, fällt gerade aus der Garantie. Man kann den nächsten kaufen – und erneut erhebliches Kapital in einer Maschine binden, die den größten Teil des Tages nur zu zehn bis zwanzig Prozent ausgelastet sein wird, denn Hardware kauft man für die Lastspitze, nicht für den Durchschnitt. Man kann aber auch zuerst durchrechnen, wie viel von dem, was dieser Server leistet, sich in die Cloud verlagern lässt – und für Ressourcen dann zahlen, wenn sie tatsächlich arbeiten.

Dieser Artikel ist ein Überblick über Einsatzszenarien, kein Begriffslexikon. Wenn Sie zunächst die Begriffe IaaS, PaaS und SaaS ordnen möchten, lesen Sie „Cloud als Service“ – hier setzen wir voraus, dass die Definitionen hinter uns liegen, und beantworten die praktische Frage: Wofür nutzen Unternehmen Cloud-Dienste wirklich? Wir nehmen fünf Szenarien unter die Lupe, mit denen das Cloud-Abenteuer eines Unternehmens am häufigsten beginnt.

Der Ordnung halber ein Satz Definition: Cloud-Dienste sind IT-Ressourcen – Rechenleistung, Speicherplatz für Daten, fertige Anwendungen – bereitgestellt über das Internet aus der Infrastruktur des Anbieters, auf Abruf gestartet und wieder freigegeben, ohne eigene Hardware zu kaufen.

Szenario 1. Anwendungs-Hosting: ein Server, der mit dem Traffic mitwächst

Der offensichtlichste Anwendungsfall: die Unternehmenswebsite, der Online-Shop, ein B2B-System, eine Anwendung, die von Kunden genutzt wird. Statt eines physischen Servers – eine virtuelle Maschine in der Public Cloud, und daneben die Komponenten, die man im eigenen Serverraum einzeln kaufen und betreiben müsste: private Netzwerke (VPC), eine Firewall, ein Load Balancer, der den Traffic auf mehrere Instanzen verteilt.

Der praktische Unterschied zeigt sich im Lebenszyklus der Anwendung. Sie starten mit einer kleinen Konfiguration, weil das neue System zehn Nutzer hat. Ein halbes Jahr später sind es fünfhundert – die Maschine zu vergrößern oder eine zweite hinzuzufügen ist ein Vorgang im Panel, keine Hardwarebestellung mit mehrwöchiger Lieferzeit. Entwicklungsteams gehen einen Schritt weiter, betreiben auf denselben Ressourcen Container-Cluster (Docker, Kubernetes) und verbinden sie mit ihren eigenen CI/CD-Prozessen.

Bei WebDisk wird dieses Szenario von der Public Cloud WebDisk Cloud bedient – virtuelle Maschinen mit Abrechnung nach tatsächlich genutzten Ressourcen.

Szenario 2. Backup: eine Kopie außerhalb des Unternehmens, ohne einen zweiten Serverraum zu bauen

Die klassische Backup-Regel 3-2-1 besagt: drei Kopien der Daten, auf zwei verschiedenen Datenträgern, davon eine außerhalb des Unternehmensstandorts. Gerade diese letzte Anforderung war historisch am teuersten – sie bedeutete einen zweiten Serverraum, ausgelagerte Bänder oder Festplatten im Tresor. Die Cloud vervollständigt diese Regel ganz ohne diese Dinge: Die Kopie „außerhalb des Standorts“ ist ein Speicher beim Anbieter, an einem physisch anderen Ort als Ihre Systeme.

Das natürliche Ziel der Kopie ist ein Objektspeicher mit S3-Schnittstelle – gängige Backup-Tools können direkt in ihn schreiben, ohne Zwischenstationen. Zunehmend an Bedeutung gewinnt die Widerstandsfähigkeit einer solchen Kopie gegen Ransomware: Angreifer versuchen routinemäßig, Backups zu löschen, bevor sie die Produktion verschlüsseln. Deshalb werden immer häufiger Kopien verlangt, die sich vor Ablauf einer festgelegten Frist nicht löschen lassen (über solche unveränderlichen Kopien schreiben wir in einem separaten Artikel).

Ein Vorbehalt: Backup in der Cloud „passiert nicht von selbst“. Zeitplan, Umfang und – vor allem – Test-Wiederherstellungen bleiben Ihre Aufgabe. Mehr über die Gestaltung dieses Prozesses schreiben wir im Artikel „Backup in der Cloud: das Fundament der IT-Sicherheit“.

Szenario 3. Datenspeicher: Object Storage statt des nächsten NAS

Unternehmensdaten wachsen schneller als alles andere: Dokumente, Scans, Multimedia, Logs, Anwendungsartefakte. Ein lokales NAS antwortet darauf mit immer neuen Festplatten, Umbauten des Arrays und der Frage „Was tun, wenn das Gehäuse voll ist?“. Object Storage – der Objektspeicher – skaliert ohne diese Mechanik: Sie fügen Daten hinzu, verwalten keine Volumes und zahlen für den tatsächlich belegten Platz.

Die Schlüsseleigenschaft ist die standardisierte Schnittstelle S3, die von einem riesigen Ökosystem an Tools gesprochen wird – von der AWS CLI und s3cmd bis hin zu Programmierbibliotheken. Eine Anwendung, die in S3 schreiben kann, funktioniert in der Regel mit jedem kompatiblen Speicher – die Unterschiede zwischen den Implementierungen betreffen Details, nicht den Kern der API; eine praktische Versicherung für den Fall eines Anbieterwechsels. Im Object Storage von WebDisk, der auf der offenen Plattform Ceph aufgebaut ist, lässt sich Verschlüsselung auf Bucket-Ebene aktivieren (ein Bucket ist der Behälter, in dem ein S3-Speicher Objekte, also Dateien, ablegt – ein separater, benannter Datenraum). Die verteilte Architektur speichert die Daten dabei redundant, sodass der Ausfall einer einzelnen Festplatte oder eines Servers nicht ihren Verlust bedeutet.

Und wenn das Team statt rohem S3 eine komfortable Oberfläche für die tägliche Arbeit mit Dateien braucht, übernehmen diese Rolle Aufsätze wie Nextcloud – eine offene Plattform für Dateiaustausch und Zusammenarbeit, bei WebDisk als verwalteter Dienst WebDisk Next verfügbar; der Objektspeicher bleibt dann die Schicht darunter. Eine ausführlichere Beschreibung der Einsatzmöglichkeiten des Objektspeichers finden Sie im Beitrag „Object Storage bei WebDisk“.

Szenario 4. Testumgebungen: Infrastruktur für Stunden, nicht für Jahre

Im eigenen Serverraum ist die Testumgebung meist der älteste Server im Rack – weil „der neue zu schade wäre“. In der Cloud ist es oft umgekehrt: Die Testumgebung kann eine exakte Kopie der Produktion sein, die nur für die Dauer der Tests existiert. Sie klonen die Maschine aus einem Template oder Snapshot, proben eine Migration oder ein Update oder führen Performance-Tests durch – und löschen anschließend alles, wobei Sie für Stunden zahlen, nicht für Jahre.

Derselbe Mechanismus treibt die tägliche Entwicklungsarbeit an: eine eigene Umgebung pro Projekt oder Code-Branch, Build-Maschinen in CI/CD-Prozessen, die nur für die Dauer des Builds erzeugt werden. Auch der klassische Konflikt „Tests fressen die Ressourcen der Produktion“ verschwindet – die Umgebungen sind netzwerk- und ressourcenseitig voneinander getrennt.

Das ist das Szenario, in dem die nutzungsbasierte Abrechnung den größten Unterschied zur eigenen Hardware macht: Infrastruktur, die die meiste Zeit nicht existiert, kostet die meiste Zeit auch nichts.

Szenario 5. Saisonalität: die Lastspitze ohne Hardware, die fürs ganze Jahr gekauft wird

Der Online-Shop vor dem vierten Quartal, das Buchhaltungsbüro beim Jahresabschluss, das Recruiting-Portal in der Bewerbungssaison, eine Kampagne mit TV-Werbung – viele Unternehmen haben Spitzen, in denen der Traffic für Wochen, manchmal für Tage, um ein Mehrfaches steigt. Eigene Hardware muss man für diese Spitze kaufen; den Rest des Jahres steht sie ungenutzt herum und altert.

In der Cloud fügt man Ressourcen vor der Spitze hinzu und baut sie danach wieder ab: größere Maschinen, zusätzliche Instanzen hinter dem Load Balancer, mehr Speicherplatz für Daten. Eine ehrliche Anmerkung: Das bloße „Hinzukaufen von Instanzen“ reicht nicht – die Anwendung muss auf mehreren Maschinen parallel laufen können, und das muss man entwerfen (Zustandslosigkeit, gemeinsamer Session- oder Datenspeicher). Skalierung ist eine Eigenschaft der Architektur, die die Cloud ermöglicht – keine Funktion, die man per Knopfdruck einschaltet.

Wann lohnt sich die Cloud nicht? Eine ehrliche Bilanz

• Konstante, hohe Last 24/7. Wenn die Maschinen jahrelang ununterbrochen unter Volllast laufen sollen, ist eigene Hardware in der Gesamtrechnung mitunter günstiger. Der Vorteil der Cloud wächst mit der Variabilität der Last – deshalb rechnen sich die Szenarien 4 und 5 am leichtesten, während man eine konstante, vorhersehbare Grundlast durchrechnen muss, statt sie einfach anzunehmen.
• Die Verantwortung verschwindet nicht – sie ändert ihren Umfang. Der Anbieter ist für Hardware, Stromversorgung und die Virtualisierungsschicht verantwortlich; die Konfiguration der Systeme, Berechtigungen, Updates und Backups auf Ihren Maschinen bleiben auf Ihrer Seite. Eine falsch konfigurierte Maschine in der Cloud ist genauso verwundbar wie eine falsch konfigurierte im eigenen Serverraum.
• Datentransfer. Das Übertragen großer Datenmengen – insbesondere ausgehender – kann bei Cloud-Anbietern ein erheblicher Kostenposten sein. Prüfen Sie die Konditionen Ihres Tarifs, bevor Sie eine Architektur entwerfen, die ständig große Datenmengen zwischen Standorten hin- und herschiebt.
• Abhängigkeit vom Anbieter. Je mehr einzigartige Dienste einer konkreten Cloud Sie mit Ihrer Anwendung verflechten, desto teurer wird der Umzug. Standardisierte Schnittstellen (wie S3) und offene Software verringern dieses Risiko – es lohnt sich, bei der Anbieterwahl danach zu fragen.

Häufige Fragen

Wofür nutzen Unternehmen Cloud-Dienste wirklich? Am häufigsten für fünf Dinge: das Hosting von Anwendungen und Websites, Backups außerhalb des Unternehmens, Datenspeicher (Object Storage), Testumgebungen für die Dauer der Arbeiten sowie die Bewältigung saisonaler Traffic-Spitzen. Der gemeinsame Nenner: Ressourcen werden gestartet, wenn sie gebraucht werden, und nach tatsächlicher Nutzung bezahlt, statt vorab in Hardware zu investieren.

Ist die Cloud günstiger als ein eigener Server? Manchmal – aber nicht per Definition. Die Cloud verwandelt eine große Investitionsausgabe in Betriebskosten und beseitigt das Bezahlen für untätige Hardware; bei konstanter Volllast schmilzt dieser Vorteil. Ein ehrlicher Vergleich berücksichtigt auf der Seite der eigenen Hardware auch Strom, Kühlung, Wartung, Platz und die Zeit der Mitarbeiter – nicht nur den Preis des Servers.

Mit welchem Szenario sollte man anfangen? Wenn das Unternehmen keine Sicherungskopie außerhalb des eigenen Standorts hat – mit dem Backup. Es erfordert keine Änderungen an laufenden Systemen, liefert sofortigen Nutzen und erlaubt es, den Anbieter bei geringem Risiko kennenzulernen. Der zweite natürliche Kandidat sind Testumgebungen: Ein Fehler kostet wenig, und die Ersparnis ist sofort sichtbar.

Muss man alles auf einmal migrieren? Nein – und meistens lohnt es sich nicht. Der typische Weg ist ein Hybridmodell: Ein Teil der Systeme bleibt lokal, ein Teil (Backup, Datenspeicher, temporäre Umgebungen) läuft in der Cloud. Die Migration von Produktionsanwendungen plant man separat, nachdem erste Erfahrungen gesammelt wurden.

Wo befinden sich meine Daten physisch? Beim Anbieter – deshalb ist der Standort der Rechenzentren eine Frage, die man vor der Vertragsunterzeichnung stellen sollte, insbesondere im Hinblick auf die DSGVO und Branchenanforderungen. WebDisk ist eine polnische Cloud: Wir speichern die Daten in Polen, was die Einhaltung der DSGVO und branchenspezifischer Anforderungen erleichtert.

Zusammenfassung

Cloud-Dienste bewertet man am besten nicht anhand von Schlagworten, sondern anhand von Szenarien: Hosting, das mit dem Traffic skaliert; ein Backup, das die 3-2-1-Regel vervollständigt; ein Datenspeicher, der ohne Hardwaretausch wächst; Testumgebungen für Stunden; Leistungsreserven für die saisonale Spitze. Jedes davon lässt sich einzeln einführen – und jedes lässt sich einzeln durchrechnen. Möchten Sie prüfen, welches in Ihrem Unternehmen sinnvoll ist? Schreiben Sie uns – wir helfen Ihnen, den passenden Startpunkt zu wählen.