News

Cloud Sourcing Lifecycle – Part 4: Cloud Sourcing Transformation

Eine einzelne Cloud in Betrieb zu nehmen, ist relativ einfach. Was es in der Regel braucht, ist ein Anbieter, eine Kreditkarte und ein Internet-Zugang. Hingegen eine Cloud in das Unternehmens-Netzwerk zu integrieren, ein ganzes Datacenter in die Cloud zu verschieben oder neu Applikationen in der Cloud zu entwickeln und bereitzustellen, kann relativ komplex und anspruchsvoll sein, selbst für erfahrene Cloud-Spezialisten.

Was auch immer die Treiber für die Nutzung von Cloud-Services sind, sei es Kostendruck auf bestehende Infrastrukturen oder Nutzung neuer Möglichkeiten und Fertigkeiten (Capabilities) für das Unternehmen, es ist in jedem Fall eine Reise in eine neue Zukunft, welche gut geplant und klug umgesetzt werden will. Im Rahmen einer fünfteilegen Blog-Serie beschreibe ich den Cloud Sourcing LifeCycle, welcher als Leitfaden für eine sichere und erfolgreiche Reise in die Cloud entworfen worden ist. Ein Übersicht des Cloud Sourcing LifeCycle sowie die Bedeutung der Cloud Sourcing Strategie  und die Aspekte des Cloud Sourcing Designs wurden bereits beschrieben. In diesem Blog fokussiere ich mich auf das Cloud Sourcing Transformation.

Wenn die Entscheidung für die Cloud rein kostengetrieben ist, dann ist die Herangehensweise bei der Umsetzung ganz anders, als wenn die Cloud genutzt werden soll, um einen agilen Ansatz und damit eine die Transformation des Unternehmens in die digitale Zukunft ermöglicht werden soll. Bei rein effizienzgetrieben CIOs werden die bestehenden Infrastrukturen in eine IaaS-Lösung umgewandelt und mittels «Lift and Shift» der bestehenden Workload, Applikationen und System-Komponenten quasi 1 zu 1 in die Cloud verschoben. Die darüberhinausgehenden Möglichkeiten der Cloud werden nicht genutzt. Der Betrieb ist abgesehen von zusätzlicher Abhängigkeit externer Provider mehr oder weniger unverändert. Echte Kostenersparnisse sind letztlich nicht zu erwarten.

Wenn die Cloud genutzt werden soll, um eine agile Transformation der IT und der Geschäftsprozesse zu ermöglichen, werden Methoden wie DevOps angewendet, um die Entwicklung von Anwendungen völlig neu auf die Cloud auszurichten (Cloud-Native Computing) und mittels automatisierten Tools und «Infrastruktur as a Code» viel mehr Dynamik und Flexibilität zu gewinnen.

Welchen Weg das Unternehmen und die IT einschlagen, ist immer eine strategische Entscheidung. Es gilt dabei zu klären, welche Auswirkungen die Transformation in die Cloud für die Organisation haben soll, ob neue Skills benötigt werden und wer allenfalls Gewinner oder Verlierer dieser Umstellung sind. Letzteres ist wichtig, um möglichem Widerstand rechtzeitig begegnen und Optionen anbieten zu können.

Wer die Transformation in die Cloud als reine technische Veränderung betrachtet, wird die Umsetzung unterschätzen. Damit dies nicht geschieht ist der Cloud Sourcing LifeCycle entwickelt worden. In der Phase Cloud Sourcing Strategie sind die Ziele geklärt und sollten zu diesem Zeitpunkt nochmals überprüft werden. In der Phase Cloud Sourcing Design sind entsprechend die Lösungen und das Betriebsmodell auf diese neuen Herausforderungen designt worden. In dieser Phase Cloud Sourcing Transformation geht es um die Konkretisierung des Designs bis hin zur Inbetriebnahme.

Ich fokussiere mich in diesem Blog auf folgende Themenbereiche

1. Transformation oder Migration der Applikationen
2. Migration des Datencenters in eine Hybrid-Cloud
3. Migration der Daten
4. Transformation der Organisation

Transformation oder Migration der Applikationen

Viele Unternehmen haben bereits eine Vielzahl von eigenen Applikationen, entweder selber entwickelt oder als Standardlösung eingekauft. Um die Vorzüge der Cloud nun für diese Applikationen zu nutzen, braucht es eine völlig neue Applikations-Architektur. Analog wie beim Wechsel von Desktop-Lösungen in Mobilie-Applikationen muss die Umstellung der Applikation für die Nutzung aus der Cloud neu designt werden. Dieser Umstand wird gerne übersehen und führt insbesondere bei der Phase Cloud Sourcing Transformation zu Überraschungen. Ohne Anpassungen des Designs und der Nutzung der zugrundeliegenden Cloud-Infrastruktur-Dienste kann die Dynamik der Cloud in der Applikation nicht genutzt werden.

Klar, es ist immer auch möglich, eine Applikation praktisch eins zu eins in einer IaaS-Umgebung zu implementieren. Eine soche Migration der Applikation ohne Anpassung ist zu Beginn einfacher und rascher umgesetzt. Wenn eine Applikation jedoch Technologie- oder Topologie-spezifisch entwickelt oder in seinem Code direkt System-, Datenbank- oder Netzwerkkomponenten adressiert, wird die Applikation nicht Cloud-Ready sein. Je schlechter Entwicklungsstandards durchgesetzt wurden, desto schwieriger und aufwendiger wird die Migration in die Cloud.

Cloud basiert auf Opensource-Technologie und bietet aufgrund dieses Ansatzes eine Vielzahl von neuen Möglichkeiten. Um diese Möglichkeiten nutzen zu können, müssen Applikationen Cloud-native entwickelt werden. Letztlich weiss eine Applikation nie, auf welchem physischen Server sie betrieben wird, wo welche Daten bezogen werden und aus welchen Netzwerkzonen zugegriffen wird. Wurden klassischerweise diese Informationen in den verschiedenen Sessions der Applikation weitergereicht, basiert eine Cloud-native Anwendung auf die Verwendung von «Stateless Apps», welche keine Daten weiterreicht sondern die gesamte Verarbeitung vollständig durchführt. Solche Microservices können dann in Container verpackt und betrieben werden ohne dass Abhängigkeiten zu anderen Services entstehen.

Dies führt zu enormer Flexibilität und Unabhängigkeit und damit geeignet für moderne verteilte Systemumgebungen. Die Cloud-native Applikationen sind auch stabiler und können aufgrund ihrer Architektur problemlos wieder gestartet werden. Aufgrund ihrer isolierten Nutzbarkeit können solche Cloud-Applikationen auch schneller und friktionsfreier direkt in die Produktion eingesetzt werden.

Der Weg in die digitale Zukunft führt nur über die Nutzung solcher Cloud-native Applikationen. Daher muss sich das Unternehmen gut überlegen, ob sie eine einfache Migration anstrebt (Mode 1), oder die grundsätzliche Architektur ihrer Anwendungen neu ausrichtet und transformiert (Mode 2). Für neue Applikationen ist klar, dass die Applikationen nach den neuen Architektur-Konzepten entwickelt werden sollen. Bei bestehenden Applikationen muss differenzierter überlegt werden. Welche Applikation lohnt sich neu zu designen und welche werden in einer ersten Phase nur migriert.

Migration des Datacenters in eine Hybrid-Cloud

Der Druck der Anwender und des Business zur Nutzung von einfachen und öffentlichen Cloud-Diensten ist gross und nimmt laufend zu. Andererseits ist das Unternehmen aus Sicherheitsbetrachtungen oder Compliance-Anforderungen gezwungen, weiterhin volle Kontrolle über die Applikationen, Daten und Infrastrukturen zu halten. Hier kommt für das Unternehmen nur eine private Cloud in Frage. Die Kombination nun der privaten Cloud mit den skalierbaren Cloud-Diensten einer Public-Cloud ist daher bestechend und wird auch in Zukunft eines der meist verbreiteten Modelle bleiben.

Das eigene Rechenzentrum in die Cloud zu verschieben bedingt einer sorgfältigen Planung. Mit der Cloud wird die Architektur viel flexibler, als dass dies ein normal virtualisiertes Rechenzentrum bieten kann. Die Cloud-Nutzung ist sehr einfach – wenn aber diese Architektur-Überlegungen nicht zu Beginn klug durchgeführt werden, wird der Nutzen der Cloud später nicht wirklich realisiert werden können.

Das neue Rechenzentrum in der Cloud muss folgende Aspekte klären:

• Welcher Netzwerkbereich soll belegt werden?
• Wie werden die Ressourcen segmentiert hinsichtlich Subnetze, DHCP Blöcke oder separat abrechenbare Accounts
• Wie soll auf das Cloud-RZ zugegriffen werden? Via Internet? von verbleibenden On-Premise-Systemen?
• Wie regle ich den Zugriff und wie stellen wir Identity and Access Management sicher?
• Wie realisieren wir Desaster-Recovery Lösungen?
• Welche Security-Regeln sollen implementiert werden? Je Server, je Subnet
• Wie sollen Applikationen skalieren können?
• Wie werden die Daten-Tiers organisiert? Ein Server pro Datenbank oder ein grosser Server als DB-Cluster?

Dieser RZ-Design muss mit dem IaaS-/PaaS-Provider abgestimmt und umgesetzt werden. Wichtig ist, dass die Zugriffe funktionieren und gemäss Vorgaben gesichert bereitgestellt werden. Der Provider stellt in der Regel ein Cross-Connect-driven Private-Link zur Verfügung (VPN).

Sobald der Zugriff auf die Cloud eingerichtet ist, kann mit dem Einrichten der Accounts und dem Setup des Cloud-RZs begonnen werden. Es ist nun wichtig zu wissen, wo welche Server mit welcher Kapazität eingerichtet werden sollen. Dies hängt sehr zentral von der Applikationslandschaft ab. Es besteht eine gewisse Gefahr, dass hier die Systeme überdimensioniert werden. Eine entsprechende Überwachung muss von Anbeginn eingerichtet werden.

Nach sorgfältiger Umsetzung kann mit der Migration der Applikationen begonnen werden. Wenn Applikationen neu auf Cloud-native designt werden müssen, kann dieser Teil der Transformationen zeitlich länger dauern. Vielfach belasten nun die alte Lösung und die neue Cloud die Budgets der IT-Organisation. Mit guter Planung und strategischer Weitsicht, kann dieses Risiko minimiert werden.

Auf der Basis einer Hybrid Cloud kann das Unternehmen nun beginnen, mit unterschiedlichen Tempos neu Entwicklungen agil voranzutreiben und stabile und weniger flexible Umgebungen auch weiterhin zu betreiben. Es bleiben immer Fragen der Integration, des Datenmanagements und der Umgang mit den Zugriffen.

Migration der Daten

Daten und Informationen sind die Währung des Einundzwanzigsten Jahrhunderts. Der Umzug von lokalen Datenbanken in die Cloud muss daher gut geplant werden, weil es sich um die strategischen Assets des Unternehmens handelt. Es gibt verschiedene Cloud-Anbieter, welche so eine Migration mit wenig Aufwand ermöglichen.

Aber eine Datenbank wird oft nicht bloss von einer Applikation genutzt, sondern von mehreren. Wie die Migration, das Nachvollziehen von Änderungen im Datenbank-Journal sowie die Synchronisation bei mehreren Instanzen der gleichen Datenbank gewährleistet werden soll, muss gut durchdacht sein. Auch wie künftig, nach erfolgter Migration aller Applikationen die Daten kontinuierlich repliziert und damit Ausfall- und Verlustsicher betrieben wird, bedingt ein auf das RZ aus der Cloud abgestimmtes Datenkonzept.

Wichtig ist insbesondere, dass Klarheit über die Vertraulichkeit der Daten herrscht. Entsprechende Schutzmechanismen und Abschottungen von Datenbank-Servern muss gewährleistet werden.  Es lohnt sich auch, Datenbestände zu überprüfen und nicht mehr benötigte Daten zu eliminieren.

Cloud-native Applikationen sollten nun das Cloud Data Management Interface CDMI verwenden, ein Branchenstandard von SNIA. Damit können die Storage-Ressourcen besser verwaltet und Metadaten in den Container der Applikation hinzugefügt werden. Mit dieser Schnittstelle können Domains, Sicherheitszugriffe und Informationen bezüglich Überwachung und Abrechnung verwaltet werden. Ohne dieses Interface lassen sich Applikationen und deren Nutzung nicht über eine Cloud Management Plattform steuern und überwachen.

Transformation der Organisation

Wir haben schon an verschiedenen Stellen darüber diskutiert, dass die Reise in die Cloud ein Veränderungsprojekt darstellt. Dies trifft insbesondere direkt auf die Organisation und die Mitarbeiter zu. Die Art und Weise wie gearbeitet wird, die Technologie, Prozesse, Führung wird völlig neu definiert werden müssen. Es ist wichtig, dass alle betroffenen Mitarbeiter frühzeitig in das Cloud-Projekt involviert werden. Insbesondere in der Phase Cloud Sourcing Transformation müssen die neuen Skills geschult und die Rollen, Aufgaben und Verantwortlichkeiten übernommen werden können.

Cloud ist Voraussetzung für die digitale Transformation des Unternehmens. Die Cloud ist dabei auch ein wesentlicher Treiber für die Neuausrichtung der Organisation und der agilen Software-Entwicklung für Cloud-native Anwendungen. Betriebs- und Entwicklungsteams rücken näher zusammen, um gemeinsam die Dynamik der Cloud in automatisierten, kontinuierlichen Integrations- und Deplyoments-Modelle umzusetzen. DevOps ist derzeit eine der stärksten Bewegungen, welche das Arbeiten in den Teams und den Führungsstil auf diese neu nach Mehrwert gerichtete Kultur schafft. Die Cloud-Infrastruktur wird Teil der Automatisierung: «Infrastructure as a code». Vorbei mit der Manuellen Orchestrierung.

Es wird in der IT Organisation eine Reihe neuer Rollen geben, welche auch Perspektiven für die bestehenden Mitarbeiter eröffnen. Der ISO-Standard ISO17789 ist eine Referenz-Architektur und darin die grundlegenden Rollen im Cloud-Eco-System definiert.

Folgende Rollen sind für eine Cloud-Organisation vorzusehen:

• Business Relationship Manager, ist verantwortlich für die Abstimmung der Anforderungen seitens Business und der Digitalisierungs-Strategie mit der IT-Organisation (Siehe auch Blog: «Business Relationship Management – Navigator zwischen Value Creation und Value Leakage»
• Cloud Solution Architect, er ist verantwortlich für ein effizientes und effektives Cloud-Design, basierend auf den Anforderungen des Business. Er definiert den im Unternehmen eingesetzten Cloud Standard und verantwortet die Cloud Produkt-Stacks
• Cloud Security Manager, er ist verantwortlich für die Definition, Umsetzung, Review und das Testen der Security- und Compliance-Standards, Policies und Kontrollen im Cloud Service Design
• Cloud Engineer, er definiert die Cloud Design Pakete und stellt sicher, dass die Cloud-native entwickelten Anwendungen integriert werden können
• Cloud Administrator, er ist verantwortlich für die Bereitstellung, Installation/Configuration, Orchestrierung, Betrieb und Überwachung der Cloud-Infrastruktur verantwortlich
• Cloud Service Owner, ist verantwortlich für den Cloud-Service während des gesamten Service LifeCycles. Er ist auch Owner der Cloud-Strategie und des Cloud Service Portfolios
• Cloud Service Manager, er ist verantwortlich für die Bereitstellung des Cloud-Services zum Business und zu den Endbenutzern. Er ist verantwortlich für die Einhaltung der SLAs
• CSI Manager, er ist verantwortlich für das Management der kontinuierlichen Verbesserungen im Cloud-Umfeld

Basis für die Transformation der Organisation bildet das Cloud Betriebsmodell, das Cloud Target Operation Modell im letzten Blog Cloud Sourcing Design vorgestellt. Die Transformation bedeutet einen Paradigma Wechsel sowohl für das Unternehmen, die IT-Organisation und für jeden IT-Mitarbeiter. Die IT-Organisation muss eine Cloud-Kultur schaffen und die Reise in die Cloud offen antreten. Dies muss jedem Mitarbeiter und insbesondere dem Management klar sein, wenn sie auch in Zukunft für das Unternehmen relevant bleiben wollen.

Im nächsten und letzten Blog dieser Cloud Sourcing LifeCycle Serie gehe ich auf das Tagesgeschäft mit der Cloud ein: Cloud Sourcing Operation.