Schlagwort: Workload

Dies ist der dritte Artikel in meiner Reihe zu Kostenfallen in der Umsetzung einer Cloud-Strategie. Nach Teil 1, „Warum die Gleichung “Cloud = kostengünstig” nicht immer stimmt“, und Teil 2, „Kostenfallen bei der Cloud-Workload-Selektion vermeiden“, möchte ich in diesem dritten Teil auf typische Kostenfallen in der Phase der Cloud-Workload-Migration eingehen. Ein abschließender Artikel zu Kostenfallen in der Betriebsphase folgt. 

Nachdem im Rahmen der Workload-Analyse geeignete Workloads zur Verlagerung in die Cloud identifiziert worden sind, müssen im nächsten Schritt nicht nur die Migrationsmethoden, sondern vor allem die aufzubauende Zielumgebung zur Aufnahme der Workloads festgelegt werden. Gerade dabei erlebe ich immer wieder, wie in einer ersten Euphorie zu Cloud Services wesentliche Anforderungen eines Enterprise IT-Betriebs im Sinne einer vollständigen „Total-Cost-of-Ownership“ (TCO)-Betrachtung übersehen werden. Prinzipiell muss ich zum Betrieb einer Workload in der Cloud die gleichen Fragen beantworten wie in traditionellen Umgebungen. Die Lösungen können allerdings andere sein. 

Fragen und Antworten zum Betrieb einer Workload in der Cloud 

Es gibt mehr oder weniger offensichtliche Fragen wie z. B. zu (Hoch-)Verfügbarkeit und Katastrophenfall-Vorsorge. Diese können mittlerweile mit den von den Cloud-Service-Providern zur Verfügung gestellten Services gelöst werden, haben allerdings auch ihren Preis. 

Ein Blick auf einschlägige Websites, die die Verfügbarkeit von Cloud Services darstellen (z. B. „CloudHarmony“) zeigt, dass “Cloud is always on” nicht ganz der Realität entspricht. Welche Verfügbarkeit garantiert mir der gewählte Cloud Service? Deckt dies meine Anforderungen ab? Reicht eine schnelle Wiederherstellung (Stop & Restart) oder muss ich zusätzliche Redundanzen mit automatischer Umschaltung vorsehen (Clustering)? Reicht mir regionale Hochverfügbarkeit oder benötige ich aufgrund regulatorischer Vorgaben für den Katastrophenfall eine “Out-of-Region”-Vorsorge? Hat der Cloud-Service-Provider passende Rechenzentrumsstandorte und kann ich damit meine Vorgaben zu „Recovery Time Objective“ (RTO) und gerade auch „Recovery Point Objective“ (RPO) erreichen? Neben den Kosten für die Redundanzen fallen hier dann in der Regel weitere Kosten an, z. B. für den Datentransfer zwischen den Cloud Rechenzentren. 

Ich erinnere an den Auto-Vergleich aus dem zweiten Artikel dieser Reihe. Bezogen auf Verfügbarkeit und Katastrophenfall müsste ich mir also die Frage stellen, ob es ausreicht, einfach nur ein Taxi zu bestellen, wenn ich früh morgens zum Flughafen muss? Oder aber besser gleich zwei, damit eines sicher pünktlich da ist und ich nicht auf ein Ersatztaxi warten kann? Dazu käme noch die Überlegung, zwei unterschiedliche Taxi-Unternehmen zu beauftragen, für den Fall, dass ein Unternehmen aufgrund einer Betriebsstörung zum angefragten Zeitpunkt kein Taxi schicken kann. Üblicherweise wäre dann aber eine Leerfahrt zu bezahlen. Man kann annehmen, dass nur wenige für eine Taxifahrt solche Überlegungen anstellen. Für unternehmenskritische Workloads, bei der Nichtverfügbarkeit für Minuten oder gar nur Sekunden direkt spürbare Auswirkungen auf mein Geschäft haben kann, sind diese Überlegungen allerdings dringend ratsam. Man sollte immer ausgehend von den Auswirkungen eines Ausfalls (= verlorener Umsatz pro Zeitfenster) die Anforderungen definieren und dann die dazu passende Umsetzung wählen, damit Kosten und Nutzen zueinander passen. Oder kurz gesagt: Nicht jeder Workload benötigt 99,999% Verfügbarkeit. 

Sicherheit und Compliance im Fokus 

Auch im Bereich Security und Compliance ergeben sich mit der Verlagerung in die Cloud zahlreiche Fragestellungen: Riskiert man es, den unternehmenskritischen Workload, also den Ferrari unter den Autos, öffentlich auf der Straße zu parken? Oder stellt man ihn besser in ein öffentliches Parkhaus, so dass er ein wenig geschützter steht und zumindest der Gebäudezugang überwacht wird? Vermutlich fühlt man sich aber erst so richtig wohl, wenn der Ferrari in einer privaten Garage steht, zu der ausschließlich man selbst einen Schlüssel besitzt und damit volle Kontrolle über den Zugang hat. Unternehmenskritische Workloads sollten ebenso wenig mit ungeschützten Public Cloud Services umgesetzt werden, sondern bedürfen eines entsprechenden Schutzes z. B. durch Netzwerk-Segmentierung mittels Firewalls und Überwachung (Intrusion Detection, etc.). Auch diese Bausteine können üblicherweise als Cloud Services bezogen werden, verursachen jedoch weitere Kosten, die in der TCO-Betrachtung zu berücksichtigen sind. Amazon Web Services (AWS) bietet z. B. neben den AWS Public Services mit ihrem Virtual Private Cloud (VPC)-Konzept und den darin möglichen Public und Private Subnet eine Abschottung von Cloud Services.  

Ein wesentliches Charakteristikum von Cloud Services ist „Resource Pooling“ oder auch „Shared Resources“. Ressourcen, die jetzt gerade vertrauliche Unternehmensdaten berechnen, transportieren oder speichern, stehen im nächsten Moment einem anderen Cloud Nutzer, womöglich einem Mitbewerber, zur Verfügung. Datenverschlüsselung zu jedem Zeitpunkt ist daher ratsam. Wichtig ist hierbei, auf eine lückenlose Verschlüsselung zu achten, z. B. auch auf die Daten in einer Sicherung. Wie bei einer Garage ist ein Schlüssel notwendig, um auf diese Daten zuzugreifen. Wie aber wird dieser Schlüssel aufbewahrt? Hat ausschließlich man selbst darauf Zugriff, da er sich in der eigenen Hosentasche befindet – Stichwort „Bring your own Key“ (BYOK)? Oder ist er Teil der Schließanlage des Garagenbesitzers, der einen Generalschlüssel hat? Cloud Services bieten kostenpflichtige Lösungen zur Datenverschlüsselung und Schlüsselverwaltung, ein weiterer Kostenblock in der TCO Betrachtung. 

Für den Betrieb stellt sich u.a. die Frage, ob und wie Cloud Ressourcen in unternehmenseigene Systems- und Servicemanagement-Werkzeuge zu integrieren sind. So kann man z. B. eine „End-to-End“-Überwachung von Geschäftsprozessen und ggf. notwendige Störungsbearbeitung unterstützen. Die Betrachtung dieser Frage und weiterer möglicher Kostenfallen im Cloud-Workload-Betrieb folgen im nächsten Artikel. 

Falls bis hierhin der Eindruck entstanden ist, es würde mittels der angeführten Kostenfallen gegen die Nutzung von Cloud Services argumentiert, hier ein klares Dementi! Zur Entkräftung an dieser Stelle der Hinweis, dass für einen fairen TCO-Vergleich im traditionellen Umfeld auch häufig „versteckte“ Kosten z. B. für Hard- und Software-Wartung, Hardware-Refresh und Rechenzentrumsinfrastruktur (Gebäude, Strom, Kühlung, etc.) berücksichtigt werden müssen. Cloud Services bringen diese Dinge mit sich und nur unter Berücksichtigung dieser vergleicht man am Ende beim TCO tatsächlich Äpfel mit Äpfeln. 

Die Wahl der richtigen Migrationsmethode 

Neben der Definition der Zielumgebung sind in dieser Phase auch die Migrationsmethoden für die ausgewählten Workloads festzulegen. Diese brauchen in ihrer Umsetzung Zeit, verursachen Aufwand und damit schlussendlich Kosten, die in einen TCO einfließen. Diese Kosten sind letztendlich unvermeidbar, wenn ich Workloads in die Cloud verschieben möchte. Die gewählte Methode bestimmt jedoch den Zeitpunkt des „Return-on-Invest“ (ROI). Dabei ist es nicht zwangsläufig so, dass eine aufwändigere (= teurere) Methode den ROI verzögert, denn ein Workload erreicht damit in der Regel einen besseren „Cloud Benefit“, z. B. Kosteneinsparungen im Betrieb, schnellere Bereitstellung oder erhöhte Flexibilität. Üblich ist eine Unterscheidung in vier Migrationsmethoden, deren Verhältnis von Aufwand/Zeit und „Cloud Benefit“ in der Grafik oben dargestellt ist. „Retire“ (= abschalten) und „retain“ (= im traditionellen Modell belassen) als mögliche Ergebnisse einer Workload-Analyse benötigen keine Migration. Auch möglich ist eine Aneinanderreihung von Migrationsmethoden: Zum Beispiel einen Workload zunächst per „Lift & Shift“ mit geringem Aufwand in kurzer Zeit in die Cloud übertragen, da die darunterliegende Hardware kurzfristig abgelöst werden muss. Und anschließend per „Re-Architecture“ die Anwendung in Microservices überführen.  

Die Festlegung der Migrationsmethode und Definition einer möglichst vollständigen Zielumgebung liefern wesentliche Kostenblöcke einer TCO und ROI Betrachtung, die in der Umsetzung und im Betrieb als Grundlage der Erfolgsmessung nachzuhalten sind. Und auch im Cloud-Workload-Betrieb lauern weitere Kostenfallen, auf die ich im nächsten Artikel eingehen werde. 

Die (primäre) Motivation einer Cloud-Strategie sollten nicht die Kosten sein, sondern Innovationen und neue Geschäftsmodelle, die die Zukunftsfähigkeit eines Unternehmens sichern. Dies war kürzlich auch Thema des Webcasts „Von der Hybrid zur Balanced Cloud“, unter anderem mit meinem Kollegen Andreas Gräf. Aber trotz allem, es geht nicht ohne stimmigen (Gesamt-) Business Case! Im Artikel „Warum die Gleichung “Cloud = kostengünstig” nicht immer stimmt“ habe ich meine Erfahrungen zu typischen Kostenfallen in den Phasen Cloud-Workload-Selektion, Cloud-Migration und Cloud-Betrieb diskutiert und möchte heute das Thema Cloud-Workload-Selektion vertiefen. Cloud-Migration und Betrieb werden in separaten Artikeln folgen. 

Unternehmensstrategien für die Cloud-Einführung legen meist so etwas wie „cloud first“ für neue Workloads fest. Deshalb sind diese daher heute in der Regel „cloud born“, während für die im traditionellen Data Center bestehende Workload zunächst eine Auswahl und Priorisierung zur Cloud-Migration erfolgen muss. In Kombination mit einem Business Case, der genauso wie die Workload-Analyse fortlaufend gepflegt bzw. überprüft werden muss, erfolgt dann die eigentliche Verlagerung der Workload in die Cloud in Wellen. Vorgehen und Dauer der Workload-Verlagerung können von Unternehmen zu Unternehmen sehr unterschiedlich sein. Dort, wo das Geschäft auf stabilen IT-Systemen beruht, die in den letzten Jahrzehnten optimiert wurden und keinen großen Schwankungen ausgesetzt sind, wird die Verlagerung der Workload vermutlich langsamer vorangehen und es verbleibt noch über Jahre hinweg Workload im traditionellen Rechenzentrum. 

Kriterien für die Workload im Data Center im Hinblick auf eine Cloud-Migration 

Vorweg möchte ich noch auf die bewusste Verwendung von „Workload“ im Unterschied zu „Anwendung“ hinweisen. Unter einer Anwendung verstehe ich „Programm-Code“, der auf einem abgrenzbaren „Deployment Node“, z. B. einer virtuellen Maschine, eine vorgegebene Funktionalität bereitstellt. Unter „Workload“ verstehe ich dagegen neben der Anwendung selbst auch notwendige Umsysteme, ihre Kommunikationsbeziehungen, Daten, Prozesse, Benutzer, etc. Also alles, was notwendig ist, damit die bereitgestellte Anwendungsfunktionalität „bestimmungsgerecht“ verwendet werden kann.  

Kriterien zur Workload-Analyse wurden bereits viel diskutiert. Hier findet sich etwa eine gute Zusammenfassung: „Workloads in die Public Cloud umziehen lassen“. Diese Kriterien  werden auch in verschiedensten Werkzeugen zur automatisierten Cloud-Workload-Analyse berücksichtigt (z. B. „Azure Migrate“). Nach meiner Einschätzung zielen diese aber häufig auf eine reine Bewertung der „cloud readiness“ ab and beantworten Fragen wie beispielsweise:  

• Welche Kontrollmechanismen und -grad sind zur Umsetzung von Compliance oder regulatorischen Anforderungen notwendig? 
• Ist die zugrunde liegende Anwendung einer Workload bereits als Cloud-Anwendung oder als Businessprozess verfügbar? 
• Ist die Workload in sich abgeschlossen?  
• Mit welchen Umsystemen kommuniziert die Workload (Latenz-/
  Bandbreitenanforderungen)? 

Daraus ergibt sich im Wesentlichen die Festlegung der Migrationsmethode zur Cloud-Verlagerung („Lift&Shift“, „Re-Platform“, „Re-Place“, „Re-Architecture“) sowie eine Wellen-Planung, d. h. welche Workloads aufgrund bestehender Abhängigkeiten zusammen in einer Welle migriert werden. Der „cloud benefit“ einer Workload ist hierin zunächst nicht berücksichtigt. Dazu sind Fragen zu stellen wie etwa:  

• Welche Flexibilitäts- und Skalierungsanforderungen hat die Workload? 
• Wo kann auf individuelle Lösungen ohne Einbuße von Wettbewerbsvorteilen verzichtet werden? 
• Welchen Nutzen bringt eine schnellere Anwendungsbereitstellung für diese Workload in der Cloud? 

Die Antworten lassen sich direkt oder auch indirekt in Kosten übersetzen (z. B. „Azure TCO Werkzeug“) und ergeben im Vergleich zu den Workload-Kosten im Data Center einen positiven – gegebenenfalls aber auch negativen – Business Case. Die notwendigen Workload-Charakteristiken für einen positiven Business Case lassen sich gut mit einer Analogie veranschaulichen – und zwar die Anschaffung eines privaten PKW: 

Ein Familienvater, der seine beiden Kinder täglich zur Schule und anschließend selbst zur Arbeit fährt, und der jedes Wochenende mit Sack und Pack unterwegs ist, kauft sich einen Kombi und käme eher nicht auf die Idee, bei ShareNow dauerhaft einen Wagen zu mieten. Ganz anders aber der Single, der unter der Woche mal im Homeoffice ist oder kurzfristig zum Kunden fährt, und am Wochenende eine Radtour mit Freunden im Mittelgebirge macht. Er braucht an manchen Tagen kein Auto, an anderen einen kleinen Stadtflitzer oder Taxi und am Wochenende einen 9-Sitzer…  Beide Beispiele stellen für die “Ressource Auto” eine völlig unterschiedliche Workload dar und münden damit in unterschiedlichen Bezugsmodellen (Kauf versus Miete). 

Dies kann man genauso auch auf die IT-Workload übertragen. Warum sollte der Betrieb einer Anwendung, 1:1 aus einem traditionellen Rechenzentrum in ein Cloud-Rechenzentrum transferiert, also mit den gleichen Ressourcen-Parametern an CPU, Speicher und 24×7-Betrieb in einem Mietmodell günstiger werden? Um in einer Cloud tatsächlich auch kostengünstiger zu werden und damit die Kostenfalle zu vermeiden, brauche ich Workload, die die Stärken von Cloud Services nutzt, u. a.: 

• Reduzierung der Fertigungstiefe durch Standardisierung 
  Das fängt mit dem Nutzen der Cloud-Standards hinsichtlich der notwendigen Hard- und Software sowie der Service-Level an. Wenn ich etwas umständlich oder individuell nachbauen muss, wird es in der Regel teuer und je weiter ich meine eigene Fertigungstiefe reduzieren kann, desto günstiger wird es (SaaS vs PaaS vs IaaS vs Baremetal). 
• Flexible Abbildung des tatsächlichen Ressourcenbedarfs 
  Variabler Ressourcenbedarf ist ein weiterer Gesichtspunkt: von ganz viel über wenig bis hin zu ungenutzt. Ein Beispiel wäre eine Workload für User Management oder Mail, die typischerweise im Tagesbetrieb viele Ressourcen, in der Nacht oder am Wochenende dagegen oftmals deutlich weniger Ressourcen benötigen. Hier kann man durch automatische Skalierung die Ressourcenkosten reduzieren. Ein etwas anderes Beispiel sind Entwicklungs- und Testsysteme, die nicht permanent benötigt werden. Durch sehr kurze Bereitstellungszeiten, noch dazu im Selfservice, können Entwickler diese in der Cloud bei tatsächlichem Bedarf bestellen und nach Gebrauch wieder löschen. Dagegen sind sie in traditionellen Umgebungen oftmals permanent vorhanden, da Bestellung und Bereitstellung viel zu lange dauern. Und nicht vergessen: Je nach Fertigungstiefe sind hierbei nicht nur Kosten für CPU und Speicher, sondern auch Softwarekosten enthalten und lassen sich damit optimieren. 

Erst mit der Erweiterung der eindimensionalen Workload-Analyse nach „cloud readiness“ um den Aspekt des „cloud benefits“ vermeide ich Kostenfallen bei einer Cloud-Migration, da damit auch Betriebskosten und Nutzen berücksichtigt werden. Ideale Migrationskandidaten weisen hohe „cloud readiness“ und „cloud benefit“ auf und werden in der Wellenplanung entsprechend priorisiert. Workload, die sich im Quadranten links oben einsortiert, kann vermutlich mit gleichem Aufwand, aber geringerem Nutzen in die Cloud migriert werden, ist aber immer noch ein guter Migrationskandidat. Die Workload rechts unten würde zwar von Cloud Services profitieren, bedarf aber üblicherweise eines höheren Migrationsaufwandes und damit oft auch mehr Zeit, da z. B. ein „Re-Architecture“ der darunter liegenden Anwendung notwendig ist. Links unten findet sich die Workload mit geringem Cloud-Nutzen und geringer Cloud-Reife, diese verbleibt zunächst im Data Center oder es gibt andere Gründe für eine Cloud-Migration. Ich rate dazu, diese Workload-Analyse und Priorisierung regelmäßig zu überprüfen, da sich Anwendungsportfolio und -architektur wie auch Cloud Services ständig weiterentwickeln.