Schlagwort: Kyndryl | Seite 4

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“.

Ein Lob auf die Faulheit

Ich muss etwas gestehen. Ich neige zur Faulheit!

Nicht immer und nicht überall, soviel sollte ich am Anfang klarstellen. Ich mache gerne Sport und auch bei meiner Arbeit, die ich wirklich liebe, hänge ich mich rein. Aber ich hasse manuelle und sich wiederholende Tätigkeiten, da fallen mir automatisch immer gleich die Augen zu.

Meine erste steile These ist, dass ich in der IT nicht der Einzige bin, dem es so geht. Und meine zweite These ist: Genau dieser Umstand hat der Entwicklung von Automatisierungstools einen großen Schub gegeben und wird das auch weiterhin tun. Während die erste These eher ein Bauchgefühl und Erfahrungswert aus vielen Gesprächen und Projekten ist, werde ich die zweite These gleich erläutern.

Als ich vor über 20 Jahren in der IT angefangen habe, war es noch üblich, dass man neben Kundenprojekten auch zusätzlich “Betrieb macht”. So etwas wie DevOps, nur eben ProOps. Irgendwann habe ich entdeckt, dass das Ticket-System eine Mailschnittstelle hat, und man mit etwas Geschick (und viel Kaffee für das Security-Team) das System entsprechend füttern kann, um so viele Aufgaben zu automatisieren.

Aber warum hat es erst in den letzten Jahren diesen Schub gegeben?

Weil viele Branchen unter einem gewaltigen Kostendruck stehen und sich digital neu aufstellen müssen, wenn sie auch in Zukunft noch auf dem Markt bestehen wollen. Laut einer Umfrage von IDC ist für 86% der befragten Unternehmen Automation mission-critical für ihre Transformations-Strategie. (IDC InfoBrief, DevOps Agility Demand Advanced Management and Automation – March 2018)

Weil es zwar schon eine gefühlte Ewigkeit Script-Sprachen gibt, die auch exzessiv genutzt werden (Perl seit 1987, JavaScript seit 1995 und Python tatsächlich schon seit Anfang der 1990er), aber Frameworks auf Enterprise-Level erst seit einigen Jahren. Und genau diese sind notwendig für die Orchestrierung, damit alle Zahnräder ineinandergreifen.

Weil die meisten Applikationen oder Tools nicht über eine Schnittstelle von außen angesprochen werden konnten. Heute sind wir einen beträchtlichen Schritt weiter und sprechen bereits von Software-Defined Everything (SDx), also der Möglichkeit, abstrahierte Workloads unabhängig von der darunterliegenden Hardware nutzen zu können. Bei vielen Firmen ist diese Fähigkeit inzwischen Voraussetzung bei der Auswahl von Software.

Zu den bekanntesten Frameworks gehört sicherlich Ansible Automation Plattform von RedHat, das seine Stärken in vielen kritischen Bereichen ausspielen kann, wie zum Beispiel bei Security & Compliance oder bei der Runbook und Event-Automatisierung.

Wir bei Kyndryl setzen nicht nur stark auf Ansible, unser Community-Modell erlaubt es unseren Mitarbeiterinnen und Mitarbeitern auch, vorhandene Skripte (sogenannte Playbooks) zu teilen oder auf die jeweiligen Kundenbedürfnisse anzupassen. Damit wird es so einfach wie nie zuvor, mit unseren Kunden zusammen eine Automations-Roadmap zu erstellen, damit diese sich ganz auf ihr Business konzentrieren können.

Was bedeutet das nun für meine oben aufgestellte These?

Der IT-Betrieb wird sich stark wandeln und diese Entwicklung ist in vielen Firmen auch bereits in vollem Gange. Mitarbeiter werden sich nicht mehr um die Abarbeitung manueller Aufgaben kümmern müssen, sondern die Automation in alle Bereiche tragen und vorhandene Ineffizienzen aufspüren und weiter reduzieren. Zusätzlich werden durch die Automatisierung Kapazitäten frei für Aufgaben, die langfristigen Nutzen für das Business bringt. Die Arbeit wird insgesamt anspruchsvoller – und deshalb auch viel spannender und abwechslungsreicher. Dann fallen mir und vielen anderen Kollegen in Zukunft bei der Arbeit auch nicht mehr die Augen zu!

Stefan Mayer

Stefan Mayer war über 20 Jahre in unterschiedlichen technischen nationalen und internationalen Positionen bei IBM Schweiz beschäftigt. Seit dem 1. Oktober 2021 ist er Chief Technology Officer und Mitglied des Leadership Teams bei Kyndryl Schweiz.

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

Kyndryl & Microsoft – Gemeinsame Expertise für gemeinsame Kunden

Kurz nach dem Börsengang von Kyndryl gibt es spannende Neuigkeiten: Das Unternehmen hat eine „globale strategische Partnerschaft“ mit Microsoft bekanntgegeben. In einem Gespräch mit Stefan Pfeiffer erläutert Klaus Stephan, Verantwortlicher für das Cloud-Geschäft von Kyndryl in Deutschland, wie die beiden Unternehmen ihre Expertise bei Cloud-Plattformen und IT-Infrastruktur-Services vereinen und welche Synergien dadurch für gemeinsame Kunden möglich sind. Im Fokus stehen dabei beispielsweise Anwendungen in den Bereichen Sicherheit, KI, Cloud-Migration, unternehmenskritische Workloads und Anwendungsmodernisierung. Und auch die Anwenderfreundlichkeit hat oberste Priorität: Nutzer werden diese Anwendungen nahtlos in ihre Umgebung integrieren können.

Auch für den Aufbau der entsprechenden Kenntnisse bei den Kyndryls ist durch eine spezielle Microsoft-University gesorgt, auf der sich Kyndryl-Mitarbeiterinnen und Mitarbeiter weiterbilden können. In einem Co-Creation-Lab werden gemeinsam wiederverwendbare Assets und Lösungen erarbeitet und entwickelt, die dann allen gemeinsamen Kunden zur Verfügung stehen.

Die neue Partnerschaft zeigt beispielhaft, wie sich Kyndryl nun frei im Markt bewegt und mit Technologieführern zusammenarbeitet. Durch solche Partnerschaften lässt sich der Bedarf von Unternehmen an Multi-Cloud- und Hybrid-Cloud-Umgebungen optimal adressieren, diese integrieren und für Kunden betreiben. So soll im Interesse der Kunden ein breites Ökosystem mit den besten Partnern und deren Lösungen entstehen, die den Ansprüchen der Kunden an eine moderne IT-Infrastruktur und die digitale Transformation gerecht wird – mit Kyndryl als weltweit agierendem Anbieter, der die Umgebungen betreiben kann.

Mehr Entrepreneurship wagen

Gerade im letzten Jahr hat sich die Art, wie wir alle zusammenarbeiten, grundlegend verändert. Absprachen mit Kollegen, Projektmanagement und Meetings mit Kunden – vieles ist (noch) virtueller geworden. Umso wichtiger ist es, dass Mitarbeiter von den Vorgesetzten unterstützt werden, und dass ihnen auch größere Freiräume – und auch mehr Verantwortung zugestanden werden.

Ich hatte bis vor kurzem das Privileg, als Chief Architect für einen großen Kunden in Kanada zu arbeiten, und im Rahmen dieser Tätigkeit habe ich mich regelmäßig mit dem Leadership-Team zu Strategien und aktuellen Projekten ausgetauscht. In einer Kaffeepause hat mir ein Mitarbeiter des Kunden über das Betriebsklima bei seinem ehemaligen Arbeitgeber erzählt. Dieses war, gelinde gesagt, verbesserungswürdig. Der Vorgesetzte verlangte von den Service-Mitarbeitern, dass sie sich ganz genau an das vorgegebene «Runbook» halten, in dem alle Schritte für definierte Probleme genau aufgelistet waren.

Das Leben ist aber weder ein Ponyhof, noch eine Liste von Runbooks, und es kann oft Unvorhergesehenes geschehen – deshalb hatten die Mitarbeiter Initiative und Eigenverantwortung übernommen, um ihrem Kunden den bestmöglichen Service zu liefern. Durch das Verhalten des Managers ist jedoch genau das passiert, was er eigentlich verhindern wollte: Die Mitarbeiter haben wieder stur nach den Regeln gearbeitet, die ungelösten Tickets häuften sich, die Service-Qualität und damit die Zufriedenheit des Kunden gingen dramatisch zurück.

Die Kultur bei meinem Arbeitgeber IBM war dagegen von großem gegenseitigem Respekt und Offenheit geprägt, was mir und vielen anderen ein sehr produktives Arbeiten ermöglicht hat.

Ein Team, das eigenverantwortlich und mit gegenseitigem Respekt zusammenarbeitet, liefert auch für die Kunden beste Ergebnisse.

Wir bei Kyndryl wollen noch einen Schritt weitergehen und noch mehr Entrepreneurship wagen. Ich bin überzeugt, dass wir alle davon profitieren werden:

Die Mitarbeiter, weil sie mehr Verantwortung haben und unternehmerisch arbeiten können
HR, weil der «War for Talent» speziell in der IT immer dramatischere Züge annimmt und Eigenverantwortung gerade bei jungen Leuten weit oben auf der Liste der Kriterien steht
Am meisten profitieren davon unsere Kunden, weil sie jemanden an ihrer Seite wissen, der ihre Herausforderungen kennt und ihre Probleme so behandelt, als wären es die eigenen

In meiner neuen Rolle als CTO für Kyndryl Schweiz fördere und fordere ich diese neue Art des Arbeitens. Wir wollen in jeder Phase, sei es im Consulting, bei der Implementierung oder später im Betrieb als vertrauensvoller Partner an der Seite unserer Kunden stehen, als wären wir Teil seiner Firma.

Stefan Mayer