Kriterien für das Cloud-Design Design-Entscheidungen wirken auf den unternehmerischen Wert von Clouds

Anbieter zum Thema

Mirantis

FX Kommunikation Felix Hansel PR-Beratung

Vogel IT-Medien GmbH

VMware Global Inc Zweigndl. Deutschland

DataCore Software GmbH

Clouds existieren in vielfältigen Varianten, von der Referenzarchitektur bis hin zur kunstvoll zusammengestellten und mit eigenen Toolsets versehenen Luxusausführung. Sicherlich sind diese Luxus-Clouds besser als das „Kassenmodell“? Das ist am Ende deutlich zu einfach gedacht. Wie dann?

Vieles hängt davon ab, wie man das Design einer Cloud angeht. Startet man mit einem gut gefüllten Pflichtenheft, ist eine komplexe Cloud das wahrscheinlichste Resultat. Das umgekehrte Vorgehen, also die Standard-Features der gewählten Cloud-Umgebung zu nutzen, führt oft zu Referenzdesigns.

Dazu ein Beispiel: Ein Kunde kauft Hardware für seine Cloud, ohne das Referenzdesign der gewählten Cloud-Plattform zu berücksichtigen. Später stellt sich heraus, dass die gewählten Datenspeicherungsgeräte von der Plattform seines Cloud-Herstellers nicht unterstützt werden. „Aber ich habe doch in der Upstream-Dokumentation der Plattform gelesen, dass die Geräte unterstützt werden”, wird der Architekt in diesem Fall einwerfen.

Das ist schon wahr, aber die Implementationen unterscheiden sich eben. Und die Einbindung der Upstream-Treiber ist nicht nur mit sehr viel zusätzlicher Arbeit verbunden, sondern bringt auch Implikationen für zukünftige Updates, Cloud-Erweiterungen und die Administration nach Herstellervorgabe mit sich.

Es mag sein, dass der Hersteller diese Änderungen gegen entsprechende Vergütung akzeptiert und die Upgrades entsprechend anpasst. Aber ein Restrisiko bleibt bestehen – und die bei den Speichergeräten eingesparten Kosten fließen dann eben in die Kasse des Cloud-Herstellers.

Eckpunkte für die Bewertung

Nehmen wir nun an, dass die besagten Geräte bereits existieren und eingebunden werden sollen, weil man davon ausgeht, auf diese Weise geringere Hardware-Ausgaben zu haben. Nun stellt sich die Frage, ob es Sinn macht, die Änderungen an der Cloud vorzunehmen und das Restrisiko zu akzeptieren, oder die Geräte anderweitig zu verwenden und das Referenzdesign anzuwenden.

Eine generelle Antwort auf diese Frage gibt es nicht. Allerdings sollten bei der Bewertung einige Eckpunkte berücksichtigt werden:

• Gesamtkostenrechnung: Wie viel Geld wird durch die Änderung tatsächlich gespart? Und wie hoch sind die zusätzlichen Kosten für die Einbindung und deren Wartung über die Zeit?

• Kundenerlebnis: Ist die gewählte Lösung im Gesamtzusammenhang besser, gleich gut oder schlechter als die Referenzlösung (beispielsweise im Hinblick auf Faktoren wie Performance und Zuverlässigkeit)? Spiegelt sich dies auch in der Kundenzufriedenheit und den in der Folge damit verbundenen Einnahmen wider?

• Unternehmensrisiko: Was geschieht im Falle eines Ausfalles oder schlimmstenfalls des Totalverlusts? Kann die Plattform schnell wiederhergestellt werden? Sind Ersatzteile einfach verfügbar, gerade im Fall von gebrauchten Geräten? Ist die notwendige Erfahrung im Team vorhanden, um einen solchen Ausfall zu überstehen? Nimmt der Hersteller der Cloud-Plattform das Risiko auf sich oder ist der Kunde auf sich alleine gestellt?

Das Grunddesign der Cloud

Aufbauend auf der Hardware entsteht das Grunddesign der Cloud.

• Wird ein Rechenzentrum genutzt oder sind mehrere beteiligt?

• Wie ist die Aufteilung auf Racks und Fire Compartments?

• Wie sieht die Segmentierung der Cloud aus, um den Bereich, der von einem Ausfall von Komponenten betroffen ist, möglichst überschaubar zu halten?

• Ist Disaster Recovery von Nöten, und welchen Einfluss hat die dafür erforderliche Replikation von Daten in die Disaster Recovery Cloud auf die Performance der Produktionsumgebung?

Ähnlich wie bei der Hardware gibt es auch hier kein generelles Rezept, aber die folgenden Punkte sollten bei Entscheidungen berücksichtigt werden:

Komplexität: Ist mein Team in der Lage, das gewünschte Design zu implementieren und zu unterstützen? In vielen Fällen wird dies ohne externen Support problematisch sein. Wer kann hier ins Boot geholt werden, um die gewünschte Struktur in den Griff zu bekommen? Gerade im Open-Source-Bereich hält sich hartnäckig die Einschätzung, dass man das doch selbst zusammenbauen könne. Kann man durchaus, aber daraus ergeben sich die nächsten Fragepunkte.

Time To Market: Wie lange wird es dauern, bis die Cloud marktreif ist? Die Erfahrung zeigt, dass die Erstellung einer ganz eigenen Plattform nicht nur viel länger dauert und viel teurer ist, als anfangs angenommen, sondern auch, dass es in den meisten Fällen billiger gewesen wäre, eine existierende Plattform einzukaufen. Je komplexer das gewünschte Design ist, desto länger und teurer gestaltet sich die Eigenentwicklung.

Ausfallrisiko: Wie wahrscheinlich ist es, dass eine Komponente oder gar die gesamte Anlage ausfällt? Was wären die Folgen für das Unternehmen? Wie lange würde es dauern, den Schaden zu beheben? Je komplexer das Design ist, desto höher ist das unternehmerische Risiko, gerade beim „Selbstbau“.

Sicherheit: Sicherheit kostet in der Regel Zeit und Geld. „Es wird schon nichts passieren“ – bis es dann eben doch passiert. Da Sicherheit nicht sichtbar ist, wird daran oft genug gespart. Das sieht man nicht zuletzt gerade bei der Welle der Ransomware-Angriffe, die in letzter Zeit überhandgenommen haben.

Und schließlich die Kernfrage: Wie passt der teure und aufwendige Bau einer eigenen Cloud-Umgebung in das Geschäftsmodell? Sofern das Unternehmen nicht gerade selbst im Software-Business tätig ist, lautet die Antwort häufig: Gar nicht.

Hier kann es weitaus sinnvoller sein, einen externen Partner ins Boot zu holen. Aber selbst in der Software-Herstellung ist die Plattform oft nicht das, was den Umsatz steigert. Wenn mehr Gewinn erzielt werden kann, indem der Fokus auf das Kerngeschäft gelegt und die Cloud einem Partner überlassen wird, sollte dies genauso umgesetzt werden.

Und nun zur Komplexität selbst: „So viel wie nötig, so wenig wie möglich“ ist generell ein guter Leitsatz. Die Frage ist nur, wie man das in der Praxis handhabt.

Ein Beispiel ist der Umstieg auf eine andere Technologie. Man kann entweder verlangen, dass die neue Plattform alle Eigenschaften der alten aufweist, oder sich an die Gegebenheiten der neuen Plattform anpassen. Ersteres ist das meist teuer. Dasselbe gilt aber auch auch oft genug für Letzteres.

Die Erfahrung zeigt, dass eine gründliche Prüfung aller Anforderungen, insbesondere derjenigen, die weitreichende Änderungen der Cloud-Struktur bedingen, und die Reduzierung auf ein vertretbares Maß meist zu einem guten Mittelweg führen. Jenseits der Kernkomponenten, die die meisten Cloud-Betreiber einsetzen, gibt es eine breite Palette von individuellen Anpassungen, Tools und Konfigurationsänderungen. Es kann durchaus sein, dass einige dieser Änderungen für die Produktion von Nutzen sein können, aber das Ausprobieren sollte auf keinen Fall in der Produktion stattfinden.

Die unterschätzte Rolle der Staging Cloud

Das bringt uns zu einer wichtigen Komponente für alle ernsthaften Produktions-Clouds: Die so genannte Staging Cloud. Während Entwicklungs-Clouds zusätzlich zur Produktionsumgebung häufig zu finden sind, ist eine Staging Cloud immer noch nicht überall vorhanden.

Staging bezeichnet eine Vorstufe zur Produktion – hier können Dinge getestet werden, ohne dass sie die Produktion gefährden oder die Entwicklung beeinträchtigen. Die Architektur der Staging Cloud sollte der Produktions-Cloud so ähnlich wie möglich sein, aber zumeist sind nur sehr wenige Compute- und Storage-Nodes vorhanden.

Der Einrichtungsmechanismus der Staging Cloud sollte wie in der Produktionsumgebung so weit automatisiert sein, dass Schäden schnell behoben werden können. Für eine Staging Cloud kann ältere Hardware eingesetzt werden, solange sie den Anforderungen genügt.

Der Einfluss des Cloud- und Service-Anbieters

Zum Abschluss sollte noch die Rolle von Cloud- und Service-Anbietern betrachtet werden. Wenige Unternehmen sind wirklich in der Lage, ein Cloud-Projekt von A bis Z alleine durchzuziehen. Und noch weniger können sich das Warten auf eine produktionstaugliche Cloud mit den notwendigen Zusatzkomponenten wie Lifecycle Management, Monitoring, Support und Disaster Recovery leisten.

Ein Cloud-erfahrener Anbieter kann diese Wartezeit und die Kosten eines solchen Projekts drastisch reduzieren. Mit einem Design-Assessment ist es wesentlich einfacher, unter objektiver externer Betrachtung die Anforderungen, die wirklich notwendig sind, auszusieben und in ein Design überzuführen, welches die gewünschte Balance zwischen notwendiger Funktionalität und unkompliziertem Design einhält.

Die angebotene Plattform ist mit Kosten verbunden. Trotzdem teilt man sich die wahren Kosten der Entwicklung einer Cloud-Umgebung mit vielen anderen Kunden und profitiert von der in jedem Projekt des Anbieters gewonnenen Erfahrungen.

Und letztlich holt man sich mit einem verlässlichen Cloud-Partner in der Regel auch ein hohes Maß an Unterstützung ins Boot. Faktoren wie 24x7 Support, Service Level Agreements, Updates und Upgrades, Implementation durch erfahrene Teams und Unterstützung bei der Administration sowie Training für die eigenen Mitarbeiter tragen dazu bei, dass die internen Cloud-Verantwortlichen ruhig schlafen können. Denn wer selbstständig eine Cloud baut, der arbeitet daran selbst und ständig.

(ID:48975835)