Kategorie: Cloud & Cloud Managed Services | Seite 5

Cloud Workloads – Kostenfallen im Betrieb vermeiden

Zum Abschluss meiner Artikelserie rund um Kostenfallen in den verschiedenen Phasen der Cloud-Einführung möchte ich auf die Phase des Cloud-Workload-Betriebs eingehen. Trotz Selektion geeigneter Workloads und Berücksichtigung der Unternehmensanforderungen an Migration und Zielplattform finden gibt es auch hier Fallstricke, die häufig zu unerwarteten Cloud-Kosten führen:

Komplexitätssteigerung im Betriebsmodell und bei Service-Integration
Unkontrollierte und ineffiziente Cloudnutzung
Hoher Aufwand durch mangelnde Transparenz

Komplexitätssteigerung im Betriebsmodell und bei der Service-Integration

Hier entstehen unerwartete Kosten vornehmlich aus der Komplexitätssteigerung im Betrieb. Die bisherige IT wird nicht einfach durch einen Cloud-Provider ersetzt, sondern Cloud entsteht parallel. Zudem bleibt es für viele Unternehmen nicht bei einem Cloud-Provider. Die meisten meiner Kunden sind heute schon bei mindestens zweiProvidern -Tendenz steigend.Von daher brauchen Unternehmen ein neues Service-Integrations-und Governance-Modell, das in der Lage ist, die Provider -so wie sie kommen -möglichst nahtlos in das eigene IT-Business zu integrieren.

Dafür braucht man neue Rollen, neue Skills und neue Prozesse. Als Beispiel sei hier der Managed Service erwähnt. „Cloud is an all managed service“ ist so absolut formuliert und zumindest bisher nicht zutreffend. Selbst wenn man einen Container-Service aus der Cloud bezieht, kann es sein, dass man noch immer selbst für die Konfiguration und das Patching der Workernodes verantwortlich ist, ganz abgesehen von der Integration in eigeneUmsysteme.Cloud Services sollen nicht isoliert irgendwo im Unternehmen benutzt werden, sondern gliedern sich idealerweise nahtlos in ein übergreifendes Monitoring, Eventmanagement, Incident/Problem/Change-Management etc. ein. Ein solches Modell zu schaffen, bedeutet zunächst einmal neue Tools und neue Integrationen und kann in unterschiedlichen Varianten umgesetzt werden.

Abbildung 1: Organisationsmodelle zur Service Integration

Zusätzlich zum bisherigen ITIL Betrieb der traditionellen Umgebungen entstehen neue DevSecOps-Ansätze zum Betrieb der Cloud-Services mit eigenen Tools, Verfahren und Skills. Egal für welches der obigen Organisationsmodelle man sich entscheidet, es werden weiterhin Menschen in ausreichender Zahl und mit entsprechendem Know-How benötigt. Man erlebt immer wieder, dass dies zu Beginn einer Cloud-Transformation nicht klar ist und in der Regel erst spät zu bösem Erwachen führt.

Auch dies lässt sich an der bereits genutzten Auto-Analogie aus den vorherigen Artikeln sehr gut verdeutlichen. Wenn man sich ein Auto kauft und in die Garage stellt, hat man genau einen Beschaffungsweg. Aus Kaufpreis, Steuer und Versicherung ergeben sich feste, planbare monatliche Kosten. Mit einem Blick in die Garage stellt man fest, ob das Auto verfügbar ist und der Blick auf das Tachometer verrät den Kilometerstand. Bei Nutzung verschiedener Transportservices ergeben sich bereits unterschiedlichste Beschaffungswege wie z. B. der Telefonanruf bei der Taxizentrale, Flug-bzw. Zugbuchung im Webportal oder die Nutzung einer Handy-App für Car Sharing. Um dieVerfügbarkeit einzelnerServices oder deren aktuelle Auslastung festzustellen, sind ebenso viele unterschiedliche Wege notwendig. Als Vorgriff auf die beiden folgenden Abschnitte: Wenn man sich einen Überblick über monatliche Transportkosten verschaffen möchte, muss manRechnungen aus unterschiedlichsten Quellen und unterschiedlichster Formate zusammenführen.Wäre es nicht großartig, wenn man eine Anlaufstelle hätte, die zu einem gewünschten Zielort den optimalen Transportservice unter Abwägung von Geschwindigkeit, Zeit, Kosten, etc. vorschlägt?Damit ist man dann beim „Multi-Cloud-Management“ bzw. einer „Cloud-Management-Plattform“.

Unkontrollierte und ineffiziente Cloud-Nutzung

Der gewollt leichte Zugang zu Cloud Services führt zu einem Wiederaufleben des alt-bekannten Phänomens „Shadow IT“und damit zu unkontrollierter Cloudnutzung. Wer IT-Ressourcen benötigt, kann sie einfach in der Cloud beziehen. „Sourcing“ erfolgt nun plötzlich dezentral mit der Folge, dass IT-Budgets nicht mehr zentral, sondern ebenfalls dezentral („projekt-orientiert“)verwaltet werden.Das sorgt zwar vielfach für mehr Geschwindigkeit, allerdings bleiben Synergien und Kontrolle damit auf der Strecke:

Keine zentralen Einkaufskonditionen
Kein einheitliches Kontrollinstrument, um Kosten zu überwachen
Kein übergreifendes Know-How, wie Cloud Services möglichst effizient genutzt werden
Kein Überblick und damit keine Steuerungsmöglichkeit auf Unternehmensebene
„Multi-Single“-Cloud: Abhängigkeit von einzelnen Cloud Providern in unterschiedlichen Fachbereichen wird erhöht

Ineffiziente Cloud-Nutzung entsteht im Wesentlichen aus zwei ebenfalls alt-bekannten Verhaltensmustern:

„Was ich habe –behalte ich und gebe es so schnell nicht mehr her“: In traditionellen Umgebungen war es nicht leicht und häufig langsam, Zugriff auf dringend notwendige IT-Ressourcen zu erhalten. Wenn sie dann endlich verfügbar waren, wurden sie nicht mehr freigegeben. Die Rahmenbedingungen haben sich mit Cloud zwar geändert: Systeme können einfach bestellt werden und sind in kürzester Zeit verfügbar. Aber das Verhalten hat sich häufig (noch) nicht geändert und den neuen Möglichkeiten angepasst.
Im Artikel zur Selektion geeigneter Workloads für die Cloud wurde auf „Variabilität“ als eine Stärke von Cloud-Services hingewiesen. Nur, das muss natürlich auch (aus)genutzt werden und passiert erfahrungsgemäß häufig nicht. Durch die Flexibilität von Cloud-Services ist kein initiales Sizing auf eine „vermutete“ Spitzenlast mehr notwendig. Man fängt klein an und wächst analog zum tatsächlichen Bedarf mit.Besser noch, bei rückläufigem Ressourcen-Bedarf lassen sich ungenutzte Kapazitäten wieder zurückgeben („right-sizing“) und nicht mehr benötigte Services sogar ganz abschalten. Bei einigenKunden fanden sich bis zu 60% Überkapazitäten in der Cloud. Bei monatlich teilweise über 2 Millionen Euro Cloudkosten stellt dies ein relevantes Einsparpotential dar, auch wenn am Ende nur 20-30% Kapazitäten eingespart werden können. Diese Betrachtung schließt im Übrigen auch sogenannte „Zombie“ Services ein. Gerade bei Cloud Services gibt es häufig ein Geflecht von Services, die voneinander abhängig sind. Wenn ein Service nicht mehr gebraucht und abgekündigt wird, kann es dazu führen, dass einzelne Services (z.B. anhängende Storage Services) „vergessen“ werden und dann weiter Kosten verursachen, obwohl sie nicht mehr genutzt werden.

Letztendlich gilt es den Überblick zu behalten und Transparenz zu schaffen, womit man beim dritten Punkt wäre.

Hoher Aufwand durch mangelnde Transparenz

Eine häufig mit Kunden diskutiertesProblem ist die verursachergerechte Weiterverrechnung von Cloudkosten. Dabei geht es noch nicht um das Optimieren der Cloudkosten, sondern darum die anfallenden (nicht optimierten) Kosten zunächst einmal richtig zu zuordnen. Warum ist das ein Problem?

Anfänglich ist das ggf. noch mit Tabellenkalkulationen handhabbar, aber irgendwann wird es unübersichtlich, vor allem wenn mehrere Cloud-Service-Provider genutzt werden. Die Fragmentierung der Datenquellen wird dadurch weiter verstärkt. Zudem verwenden die Provider sehr unterschiedliche Rechnungsformate, benennen und klassifizieren ihre Services bzw. „Line Items“unterschiedlich. Mit zunehmender Cloudnutzung enthalten die Rechnungen dann viele „Line Items“mit durchschnittlich geringenBeträgen. Die Rechnung eines Kunden mit monatlich rund1,5Millionen Euro Cloudkosten erstreckte sich beispielsweise über 500.000 „Line Items“. Dies war mit der Tabellenkalkulation nicht mehr handhabbar und wurde einfach bezahlt.Diese hohe Kleinteiligkeit verursachte nicht nur einen hohen Aufwand bei der Zuordnung zu den Kostenverursachern, sondern führte auch dazu, dass Reports zu spätverfügbar sind, um z. B. als aktives Steuerungselement bei dynamischen Kostenverläufen eingesetzt werden zu können (also z. B. zur frühzeitigen Eindämmung von unkontrollierter oder ineffizienter Cloudnutzung).

Der Aufbau eines Cloud-Service-Provider übergreifenden Data Lakes bildet hier aber lediglich die Basis zur Schaffung der notwendigen Transparenz imCloud Service Betrieb. Es sind intelligente Analyse-Werkzeuge notwendig, die darauf aufsetzen und Auswertungen über beliebige Provider durch die entsprechenden Daten aus dem Data Lake erstellen können. Idealerweise können sie auch die unterschiedlichen Datenformate für Services, Klassen, Tags und Abhängigkeiten so normieren, dass providerübergreifende Analysen möglich sind. Wenn diese Analysen dann noch „ad-hoc“ verfügbar sind, erhält man ein pro-aktives Steuerungselement zur Optimierung der Cloudnutzung.

Der beste DataLake und Analysetools sind jedoch nutzlos, wenn Datenquellen nicht hergeben, was zur Analyse gebraucht wird. Gerade wenn es um eine Zuordnung von Cloud-Ressourcen zu Projekten, Abteilungen, Anwendungen etc. geht, ist ein gutes Tagging, also das Versehen der Ressourcen mit Schlagworten, unabdingbar. Nur mit dem richtigen Tag ging, am besten auf Basis einer unternehmensweitenStrategie, ist eine korrekte Zuordnung und damit bedarfsgerechte Optimierung möglich.

Aktuelle KI-basierte Werkzeuge liefern auf dieser Basis nicht nur einfache Analysen zur Kapazitätsoptimierung z. B. durch die Korrelation von Auslastung und Kosten, sondern z. T. auch Architekturempfehlungen zur Nutzung der Services, wie z. B. die Ablösung von IaaS durch PaaS Bausteine.

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.

Kurz kommentiert: BMW-Deal zeigt neue Möglichkeiten von Kyndryl auf

Kyndryl hat am Montag bekannt gegeben, dass das Unternehmen basierend auf NetApp-Technologie die Enterprise-Storage-Infrastruktur für BMW implementieren und betreiben wird. Die Ankündigung ist unter ganz verschiedenen Aspekten relevant, technologisch und beispielhaft für die neuen Freiheiten von Kyndryl.

Moderne Storage-as-a-Service-Lösung in der Cloud

Managed Storage-as-a-Service ist das zeitgemäße Konzept, um Speichermanagement heutzutage in den Griff zu bekommen, denn laut IDC wächst die weltweite Datenmenge bis zum Jahr 2024 auf 143 ZB an. Ein unvorstellbare Datenmenge. Diese Daten sollten nicht nur sicher gespeichert werden. Eine entsprechende Speicherinfrastruktur in der Cloud, die dann auch noch durch einen erfahrenen Dienstleister betrieben wird, ermöglicht es, das eigene Speichermanagement nach Bedarf nach oben (oder auch nach unten) zu skalieren und vor allem Daten weltweit immer an der Stelle zur Verfügung zu haben, wo sie im Geschäft oder für den Kunden benötigt werden. Eine derartige Lösung ist also zeitgemäß und wird von vielen Unternehmen benötigt.

Freie Wahl der Technologiepartner im Sinne des Kunden

Bei BMW arbeitet Kyndryl in Sachen Enterprise Storage mit NetApp als Partner zusammen. Dies zeigt neue Freiheit, neue Flexibilität in der Auswahl möglicher Partner und Technologien. Kyndryl kann Kunden jetzt die beste technologische Lösung empfehlen und ist keinem Druck ausgesetzt, eigene Software- oder Hardware-Produkte zu „verbauen“. Solche eigenen Produkte hat Kyndryl ganz einfach nicht mehr.

Präferenzen und bestehende Installationen der Kunden unterstützen

Aber man kann auch auf Präferenzen oder bestehende Installationen der Kunden reagieren und die entsprechenden Lösungen und Infrastrukturen sicher und stabil weltweit betreiben, also sich auf die eigenen Stärken im Betrieb fokussieren und diese ausspielen. Beide Szenarien eröffnen Kyndryl höhere Handlungsfreiheit und versprechen einen möglichen breiteren Zugang zu Kunden, wie auch Kyndryl Deutschland-Chef Markus Koerner auf LinkedIn kommentiert.

Enterprise Storage-Lösungen in viel höherem Maße replizieren

Natürlich wird das Unternehmen versuchen, Lösungen zu replizieren, also auch bei anderen Kunden in möglichst ähnlichen Konfigurationen einzusetzen, um so entsprechende Skalierungseffekte für Kyndryl und die Kunden zu erreichen. Es muss nicht immer die hochgradig individualisierte und ganz spezifische Lösung für den individuellen Kunden sein.

All diese Facetten zeigen beispielhaft, wohin die Reise von Kyndryl gehen soll. Lesen Sie dazu auch den Beitrag von Markus Koerner, Präsident von Kyndryl Deutschland.

Stefan Pfeiffer

… arbeitet in Communications bei Kyndryl Deutschland, dem weltweit führenden Anbieter zum Management kritischer IT-Infrastruktur. Den gelernten Journalisten hat seine Leidenschaft für das Schreiben, Beobachten, Kommentieren und den gepflegten Diskurs nie verlassen. Diese Passion lebt er u.a. in seinem privaten Blog StefanPfeiffer.Blog oder auch als Moderator von Liveformaten wie #9vor9 – Die Digitalthemen der Woche und Podcasts aus. Digitalisierung in Deutschland, die digitale Transformation in der Gesellschaft, in Unternehmen und Verwaltung oder die Zusammenarbeit am modernen Arbeitsplatz sind Themen, die ihn leidenschaftlich bewegen.
Vor Kyndryl hat Pfeiffer in der IBM im Marketing in unterschiedlichen internationalen Rollen gearbeitet. Seine weiteren beruflichen Stationen waren FileNet und die MIS AG. Auf Twitter ist er als @DigitalNaiv „erreichbar“.

Green IT: Ressourcenschonende, nachhaltige Cloud Computing-Lösungen in Unternehmen

Nachhaltigkeit steht im Zentrum gesellschaftlicher sowie politischer Diskussionen. Es wird zunehmend zur Pflicht für Unternehmen sich mit ressourcenschonenden Geschäftsmodellen auseinander zu setzen – sei es aufgrund von Forderungen innerhalb von Lieferketten, moralischen Überlegungen, Wettbewerbsdifferenzierung oder auch absehbaren regulatorischen Auflagen und Gesetzen. Das geschieht mitunter auch vor dem Hintergrund einer neuen Regierung in Deutschland¹ oder des 2019 verabschiedeten Green Deal der EU². Daraus leitet sich für die Wirtschaft ab, dass die CO₂-Bilanz von Unternehmen ein immer wichtigerer Wettbewerbsfaktor am Markt ist. Das Interesse „grün zu werden“, steht daher stärker denn je zentral im Fokus.

Neben der Ausstattung der Arbeitsplätze oder den unternehmenseigenen Infrastrukturen trägt auch das Internet mitunter durch den teilweise unsauberen Energieverbrauch enorm zu den CO₂-Emissionen bei³. Viele Unternehmen haben genau diese Herausforderung bemerkt und verfolgen daher die Intension, ihren CO₂-Fußabdruck zu verringern und klimafreundlich oder gar klimaneutral zu wirtschaften.

Lokale On-Premise-Server sind weniger nachhaltig

Ausgerechnet der Einsatz lokaler (on-premise) Server zum Verwalten und Analysieren von Daten erhöht die CO₂-Emissionen erheblich. Dabei kann man beobachten, dass viele lokale Server, ausgelegt auf den PUE-Wert (Power Usage Effectiveness), selten voll ausgelastet sind und viel Energie verbrauchen. Der PUE-Wert gibt an, wie effektiv die zugeführte Energie in einem Rechenzentrum verbraucht wird⁴. Denn der Energieverbrauch eines Servers wird nicht nur durch seine Auslastung bestimmt, sondern ganz wesentlich auch durch seinen Betrieb und die damit verbundenen Betriebsverfahren. Wer viele Server besitzt, diese aber nicht voll umfassend nutzen kann, verbraucht mehr Energie als eigentlich notwendig wäre⁵.

Denn IT-Infrastrukturen (u. a. Netzwerkkomponenten, Storage oder Server) benötigen sowohl Strom für den Betrieb als auch für die Abführung der beim Betrieb entstehenden Abwärme in Form von Lüftung und Kühlung. Außerdem reagieren Server empfindlich auf Temperaturschwankungen, was eine Klimatisierung mit hohem Energieverbrauch unumgänglich macht. Weiterhin findet man immer wieder energieintensive Verfahren (z. B. beim Brandschutz), die mittlerweile nur noch bedingt zukunftsfähig sind. Zusammenfassend kann man feststellen, dass IT-Infrastrukturen enorme Mengen an Ausrüstung sowie kontinuierliche Stromversorgung und Kühlung erfordern, um ein einzelnes Unternehmen mit IT-Services zu versorgen. Dieser Energie- und Ausrüstungsaufwand bindet Kapital und es ist fraglich, ob diese Form der Leistungserbringung wirtschaftlich im Sinne der Wettbewerbsfähigkeit ist.

Energie sparen mit Cloud Services

Cloud Computing kann bei der Veränderung des eigenen CO₂-Footprint unterstützen. In einer Studie der Europäischen Kommission in Zusammenarbeit mit dem deutschen Borderstep Institut für Innovation und Nachhaltigkeit sowie dem österreichischen Umweltbundesamt wird aufgezeigt, wie Unternehmen durch eine geeignete digitale Infrastruktur, umweltfreundlichen und effizienten Cloud-Diensten sowie energieeffizienten Rechenzentren ressourcenschonender wirtschaften können. In der Studie wird auch diskutiert, wie die Förderung des Einsatzes nativer Cloud-Optimierungstools für das Cloud Computing zur Nachhaltigkeit beitragen. Durch die Migration in eine öffentliche Cloud, welche nicht durch das Unternehmen, sondern einen Service-Dienstleister betrieben wird, bieten sich eine Reihe von Potentialen.

Zum Beispiel ein Zugewinn an Flexibilität und Skalierbarkeit bei gleichzeitiger Kostenreduktion für Energie, Wartung sowie Flächenverbrauch. Cloud Datacenter bieten aufgrund ihrer Größenvorteile (Economies of Scale) eine effizientere Nutzung der eingesetzten Ressourcen. Es werden also nicht nur weniger Server verwendet, sondern diese auch effizienter betrieben, was insbesondere die Möglichkeit bietet, den CO₂-Fußabdruck eines Unternehmens zu verringern, ohne auf Leistungen verzichten zu müssen. Das bedeutet, es werden Serverkapazitäten je nach Workload und Anwendungsfall des Unternehmens ausgewählt, zugewiesen und genutzt sowie unterschieden nach Datenverarbeitung, Speicher, Datenbank und Netzwerkanbindung⁶.

Unternehmen, die mit Cloud-Dienstleistern wie IBM oder Google kooperieren, eröffnen sich das Potential eigene Ressourcen einzusparen und effektiver zu arbeiten. Darüber hinaus ist „Green IT“ für Unternehmen auch nicht-monetär ein Vorteil, da dies dem Branding der eigenen Marke inbesondere in der aktuellen Zeit zuträglich ist und hilft das eigene Geschäftsmodell zukunftssicherer zu machen⁷.

Um einen besseren Überblick zu geben, werden im folgenden die Vorteile von Cloud Computing im Zusammenhang mit Nachhaltigkeit grafisch dargestellt.

Auszug – Cloud Computing Vorteile im Rahmen von Green IT
Quelle: Kyndryl (2021)

Green Cloud Computing für die Zukunft

Die Cloud und das damit verbundene Betriebsmodell verändert die IT-Branche in vielerlei Hinsicht. Aus unserer täglichen Arbeit mit unterschiedlichsten Kunden und den damit verbundenen Erfahrungen kann man sagen, dass einerseits das Potential der IT auf dem Weg zum klimaneutralen Unternehmen weder vollständig identifiziert, adressiert oder gar realisiert ist. Ein erster Schritt hin zu einem umweltverträglichen Unternehmen könnte aber in der Nutzung von Cloud-Dienstleisten liegen. Insbesondere wenn diese dem Thema Nachhaltigkeit Priorität einräumen und beispielsweise transparent darstellen, welche CO₂-Belastung die Erbringung der IT-Services bedeutet. Das umfasst Anbieter, die unter anderem erneuerbare Energiequellen nutzen, energieeffiziente Hard- und Software für Rechenzentren entwickeln, energieeffiziente Beleuchtung und Stromversorgung in Gebäude integrieren oder intelligente Kühlsysteme zur Abfallvermeidung entwickeln. Man sieht somit in der Nutzung von Cloud Computing erhebliches Potential, das sich positiv auf die Jahresbilanz, die Reaktionsgeschwindigkeit auf Veränderungen und auch auf die Umwelt auswirkt⁸.

Globale Cloud Service-Dienstleister, wie auch Kyndryl, teilen sich die Verantwortung, ihre Kunden auf ihrem Weg hin zu einer umweltfreundlicheren Cloud zu unterstützen, indem sie möglichst nachhaltige Systeme auswählen, die zur Workload passenden Fähigkeiten bereitstellen und Cloud-Transformationsinitiativen in Unternehmen beschleunigen. So können die identifizierten Mehrwerte früher realisiert werden. Darüber hinaus hat Kyndryl im Bereich der energieeffizienten CO₂-Optimierung von Rechenzentren – insbesondere der nachhaltigen Nutzung der von den Servern erzeugten Abwärme – schon einige Kundenprojekte erfolgreich durchgeführt. Kyndryl unterstützt als unabhängiger Technologiepartner in allen Schritten der Beratung, Implementierung sowie des Betriebs von ganzheitlichen, energieeffizienten und nachhaltigen Lösungen im Kontext des IT Infrastrukturmanagements sowie des Green Cloud Computing.

Quellen:

¹ Tagesschau.de (2021): Koalitionsvertrag zwischen SPD, BÜNDNIS 90/DIE GRÜNEN und FDP. Verfügbar unter: https://www.tagesschau.de/koalitionsvertrag-147.pdf. [Besucht am 06.12.2021]

² Europäische Kommission (2019): Mitteilung der Kommission an das europäische Parlament, den europäischen Rat, den Rat, den europäischen Wirtschafts- und Sozialausschuss und den Ausschuss der Regionen. Verfügbar unter: https://ec.europa.eu/info/sites/default/files/european-green-deal-communication_de.pdf. [Besucht am 06.12.2021]

³ ZDF – Zweites Deutsches Fernsehen (2021): Energiebedarf und Digitalisierung. Verfügbar unter: https://www.zdf.de/nachrichten/heute-journal/energiebedarf-und-digitalisierung-100.html. [Besucht am 06.12.2021]

⁴ The Green Grid (2014): PUE: A comprehensive examination of the metric. Verfügbar unter: https://www.thegreengrid.org/en/resources/library-and-tools/20-PUE%3A-A-Comprehensive-Examination-of-the-Metric [Besucht am 06.12.2021]

⁵ Technogroup IT-Service GmbH (2021): Studie zeigt: Mehr Optimierungs-Potential in der IT als vermutet. Verfügbar unter: https://www.technogroup.com/studie-zeigt-mehr-optimierungs-potential-in-der-it-als-vermutet/. [Besucht am 06.12.2021]

⁶ und ⁸ Montevecchi, F., Stickler, T., Hintemann, R., Hinterholzer, S. (2020). Energy-efficient Cloud Computing Technologies and Policies for an Eco-friendly Cloud Market. Final Study Report. Vienna. Verfügbar unter: https://op.europa.eu/en/publication-detail/-/publication/bf276684-32bd-11eb-b27b-01aa75ed71a1/language-en/format-PDF/source-183168542. [Besucht am 06.12.2021]

⁷ Deloitte (2021): Verantwortung als Chance: das Transformationsthema Sustainability. Verfügbar unter: https://www2.deloitte.com/de/de/pages/risk/articles/sustainability-transformation.html. [Besucht am 06.12.2021]

Kostenfallen bei der Cloud-Workload-Migration

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.

Tobias Kreis

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

Multi-Cloud: Darf es ein bisschen Cloud mehr sein?

Nach dem aktuellen State of the Cloud-Report von Flexera nutzen 92% der großen Unternehmen in Europa ein Multi-Cloud-Modell. Ein Großteil davon kombiniert eine oder mehrere Private Clouds mit einer oder mehreren Public Clouds zu einer Hybrid Cloud.

Diese große Zahl mag zunächst überraschen. Man muss aber bedenken, dass eine Multi-Cloud-Landschaft entweder strategisch gewollt ist, aber auch die Folge einer fehlenden oder unklaren Cloud-Strategie sein kann. In letzterem Fall hat sich ein Teil der IT-Landschaft eines Unternehmens in eine Art Shadow IT verwandelt. Hier definieren und implementieren Fachbereiche ihre eigenen Standards. Die unternehmenseigene IT erscheint ihnen zu langsam oder nicht flexibel genug.

Multi-Cloud kann auch das Ergebnis eines Unternehmenszusammenschlusses sein. Oder es resultiert aus der Einführung von Office 365 und damit verbunden Azure, während bereits Anwendungen in AWS oder GCP laufen.

Im Schnitt nutzen die Unternehmen Cloud Services von zwei bis drei Anbietern.

Da Multi-Cloud die Realität für die meisten Unternehmen ist, ist es umso wichtiger, sich die Vorteile wie auch die Herausforderungen eines solchen Modells bewusst zu machen.

Häufig genannte Vorteile einer Multi-Cloud sind

Verringerter Vendor Lock-in, da man sich unabhängiger von einzelnen Anbietern macht.
Kostenvorteile oder erweiterte Funktionalität, da man Services dort beziehen kann, wo sie am günstigsten sind oder wo man die besten Features erhält.
Katastrophen-Vorsorge, für den Fall, dass ein Provider ausfällt.
Datenschutz, wenn Unternehmen aus Gründen der Datensicherheit Daten in gewissen Regionen halten müssen, die manche Cloud Anbieter unterstützen, andere jedoch nicht.

Der Vorteil der Kostenersparnis in einem Multi-Cloud-Modell lässt sich vermutlich am schwierigsten realisieren. Immerhin benötigt man redundante Netzwerk-Anbindungen an nicht mehr nur eine, sondern zwei oder mehrere Clouds. Zusätzlich benötigt man eventuell noch Anbindungen der Clouds untereinander. Die Aufteilung von Workloads auf mehrere Clouds führt unter Umständen zu schlechteren volumenabhängigen Rabattstaffeln bei den Anbietern. Der Entwicklungs- und Testaufwand steigt, da selbst bei der Verwendung von Terraform und Container-Technologien die Anwendungen auf die Gegebenheiten der unterschiedlichen Clouds angepasst oder zumindest parametrisiert werden müssen.

Aber auch die Katastrophen-Vorsorge in einem Multi-Cloud-Modell sollte man sich genauer betrachten. Alle Cloud-Dienstleister bieten Disaster Recovery Szenarien innerhalb ihres eigenen Cloud-Verbundes. Diese sind erprobt und werden durch Technologie und Automatisierung unterstützt. Die Anbieter achten sorgfältig darauf, dass die verschiedenen Regionen keine gemeinsamen Komponenten teilen, die zum „Single Point of Failure“ werden können. In einem Multi-Cloud-Modell liegt diese Verantwortung dagegen beim Anwender. Es nützt wenig, seine Anwendung auf zwei Provider zu verteilen, wenn diese sich mit ihren Cloud-Rechenzentren im gleichen Gebäude angesiedelt haben oder eine gemeinsame externe Komponente, z.B. einen Netzwerk-Kontenpunkt, teilen.

Multi-Cloud-Modelle bringen aber noch weitere Herausforderungen mit sich

Erhöhte Anforderungen an die Mitarbeiter und damit Schulungsbedarf, um die Technologien mehrere Cloud-Anbieter bedienen zu können.
Management Overhead um Standards, Richtlinien und Verfahren für mehrere Cloud Anbieter zu erstellen und zu pflegen.
Die Verteilung von Daten auf mehrere Anbieter erhöht die potenzielle Angriffsfläche.
Funktionseinschränkungen, wenn man zur Vermeidung des Vendors lock-ins nur auf den kleinsten gemeinsamen Nenner an Funktionalität zwischen den Anbietern setzt.
Erhöhter Administrationsaufwand, Komplexität und Schnittstellen bei der Verwendung von operationalen Tools unterschiedlicher Anbieter.

Um die Herausforderungen zu meistern, bietet sich die Nutzung von entsprechenden Management-Plattformen an, die eine Abstraktionsschicht über die verschiedenen Clouds legen. Darüber hinaus können Service Provider (MSP), die sich auf Cloud Workload spezialisiert haben, bei der Umsetzung der Cloud-Strategie helfen.

Thomas Petzke

Senior Solutions Architect, Kyndryl Deutschland GmbH