Kostenfallen bei der Cloud-Workload-Selektion vermeiden

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. 

Abbildung 1: Analyse der Data Center Workload im 5-Phasenmodell

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. 
Abbildung 2: Data Center Workload Analyse nach „cloud readiness” und “cloud benefit”

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. 

Tobias Kreis
Tobias Kreis

Unser Autor Tobias Kreis verantwortet als Executive IT Architect  die technische Entwicklung, Implementierung und den Betrieb von komplexen IT Architekturen und Servicelösungen für Hybrid Multi Cloud Umgebungen. Ausgehend von den spezifischen Anforderungen seiner Kunden berücksichtigt er dabei über den kompletten IT Lifecycle alle notwendigen Elemente aus Hardware, Software, Cloud und Services unterschiedlicher Hersteller und Partner, um passgenaue, innovative Kundenlösungen zu erzeugen. Dazu kann Tobias auf mehr als 20 Jahre Erfahrung in unterschiedlichen Funktionen in Vertrieb, Consulting, Enterprise Architecture und Solution Design zurückgreifen. 

Wie man die Komplexität hybrider IT in den Griff bekommt 

Dies ist der zweite Teil unseres Beitrags zum Thema „Komplexe IT“. Im ersten Teil hatten wir die Komplexität heutiger IT-Infrastrukturen beschrieben und klar gemacht, warum digitale Monokulturen keine Lösung sein sollten. in diesem zweiten Teil beantworten wir die Frage, welcher der bessere Weg ist, um komplexe hybride IT-Umgebungen in den Griff zu bekommen. 

Eine (zu) einfache Antwort auf eine komplexe Herausforderung zu geben, scheint also nicht die beste Strategie zu sein, um für Wachstum in der heutigen, durch einen starken Wettbewerb geprägten Welt zu sorgen. Daher sollten Unternehmen ihre Bandbreite an Ressourcen definieren und für ein geeignetes Management dieser Ressourcen sorgen. Eine solche einzigartige Kombination von Fähigkeiten kann dann zu einem echten Wettbewerbsvorteil werden. 

Leitfaden in vier Schritten

Wir bei Kyndryl empfehlen Unternehmen, dass sie die Herausforderung, diese Komplexität aktiv zu steuern, annehmen und dann mit dem Aufbau ihres individuellen Sets an Business- und IT-Fähigkeiten beginnen, die Sie von ihren Mitbewerbern abheben. Auf der Grundlage unserer Erfahrungen skizzieren wir einen vierstufigen Ansatz, der die wesentlichen Phasen zur Erreichung eines teilautonomen IT-Betriebsmodells beschreibt:

„Wie man die Komplexität hybrider IT in den Griff bekommt “ weiterlesen

Komplexe IT: Digitale Monokulturen sind keine Lösung 

Wie können Unternehmen die Herausforderung komplexer, heterogener Hybrid-IT-Umgebungen annehmen und in einen Wettbewerbsvorteil umwandeln? In diesem Beitrag geht es zunächst um die Frage, wo Unternehmen derzeit stehen und welche Lösung(en) zur Reduzierung der Komplexität bisher nicht funktionieren. In einem zweiten Teil geht es um die Frage, welcher Weg nun der bessere ist, um komplexe hybride IT-Umgebungen in den Griff zu bekommen. 

Jedes Unternehmen wird ein Technologieunternehmen 

Digitalisierung und Technologie dominieren die Geschäftsmodelle von Unternehmen immer stärker. Unabhängig davon, ob Sie die Nachrichten verfolgen, die Aktienmärkte analysieren oder sich mit Kollegen aus Ihrer Branche austauschen: Die Digitalisierung hat bereits viele Unternehmen und Branchen dauerhaft verändert und wird dies auch weiterhin tun. Laut einer Analyse des Weltwirtschaftsforums werden bis zum kommenden Jahr 2022 über 60 % des globalen Bruttoinlandsprodukts digitalisiert sein. Dies bedeutet: Unternehmen sollten sich nicht nur auf die Einführung von Technologie konzentrieren, sondern sie müssen immer die Kunden dabei im Blick haben. Wie wollen die Kunden Technologie und damit Dienstleistungen oder Produkte von Unternehmen nutzen? 

Bei Kyndryl sehen wir mehrere Herausforderungen, denen sich Unternehmen stellen müssen. Durch die wachsende Anzahl von grundlegenden Technologien steigt die Komplexität der Prozesse. Hierbei geht es etwa um die gleichzeitige Verwaltung von traditioneller und virtualisierter IT sowie verschiedener Clouds. Zusätzlich steigen die Risiken. Es muss ein Augenmerk auf die IT-Sicherheit gelegt, Datenverluste vermieden und rechtliche Vorgaben eingehalten werden. Hinzu kommt die Bedrohung der eigenen Position durch neue Wettbewerber. Der schnelle technologische und demografische Wandel führt zu fehlenden Skills bei den Mitarbeitern der Unternehmen. Und schließlich gibt es vielfach unsichere Richtlinien, etwa keine klare Anleitung für die Nutzung von Geschäftsanwendungen, eine unterschiedliche Auslegung der Nutzungsmöglichkeiten sowie ein fehlendes Bewusstsein für neue Risiken und Regeln. 

„Komplexe IT: Digitale Monokulturen sind keine Lösung “ weiterlesen