Wie kommt man in die Cloud?

Dieser Handlungsleitfaden will Ihnen den Umstieg in die Cloud erleichtern, indem er wichtige Aspekte und Schritte hervorhebt und näher beschreibt. Selbstverständlich kann er keinen Anspruch auf Vollständigkeit erheben, Unternehmen sind zu unterschiedlich strukturiert und aufgestellt – aber er kann Ihnen wertvolle Anregungen für Ihren Schritt in die Cloud geben.

Eine Migration in Cloud-Umfelder muss strukturiert und mit Planung angegangen werden. Es handelt sich dabei keinesfalls nur um einen rein technischen, sondern einen sehr stark auch administrativen und prozessualen Vorgang, der für Unternehmen in Bezug auf Zusammenarbeitsmodelle und Herangehensweisen ein großes Veränderungspotenzial birgt. Ebenfalls müssen Folgeaktivitäten, etwa Kostenmanagement, umfassende Governance und nachhaltiger Betrieb von Infrastrukturen konzeptioniert, geplant und aufgesetzt werden.

Als strategische Entscheidung planen und behandeln

Ganz generell ist es notwendig, sich darüber klar zu werden, dass der Wechsel in ein Cloud-Umfeld eine strategische, keine taktische Entscheidung ist. Deshalb sollte dieses Thema auch organisatorisch in Form einer Top-Down-Strategie angegangen werden.

Bevor Sie „in die Cloud“ migrieren, sollten Sie sich darüber klar werden, dass es DIE CLOUD gar nicht gibt: Es gibt verschiedene Ansätze und Anbieter für Infrastrukturen und Software-Lösungen, es gibt verschiedene Service- und Delivery-Modelle. Es ist somit ganz wesentlich, zu verstehen, WAS überhaupt gewünscht und / oder benötigt wird.

Für ein Infrastruktur-Modell entscheiden

Die erste Entscheidung, die Sie treffen müssen, ist, welches Infrastruktur-Modell für Sie überhaupt in Frage kommt: Public Cloud, Private Cloud, Hybrid Cloud oder Multi Cloud?

Public Cloud

Dieser Ansatz ist der, der am ehesten mit „Cloud“ assoziiert ist. Hier stellt ein Anbieter geteilte Infrastrukturen in einem seiner Rechenzentren bereit. Diese Infrastrukturen werden vollautomatisch zur Verfügung gestellt und können in aller Regel bei Bedarf um zusätzliche Komponenten (virtuelle Maschinen, Datenbanken, etc.) erweitert werden. Die großen Public Cloud-Anbieter Microsoft, Google, Amazon, und mit etwas Abstand Oracle, Alibaba und Tencent, werden auch als „Hyperscaler“ bezeichnet, da sie in ihren Rechenzentren nahezu beliebig große Mengen an Infrastrukturen bereitstellen können.

Es ist jedoch wichtig zu wissen, dass es neben diesen Hyperscalern auch eine Vielzahl an regionaleren, auf bestimmte Märkte fokussierte Anbieter, wie etwa OVH, Ionos, oder Noris Cloud gibt. Diese können oftmals wesentlich besser mit lokalen Anforderungen im Hinblick auf Governance, Datensicherheit (DSGVO) und Datenmanagement umgehen.

In jedem Fall gilt für alle Public Cloud-Angebote: Die zugrundeliegenden Infrastrukturen sind zwischen mehreren Kunden geteilt, Ressourcen sind üblicherweise virtualisiert. Dies bedeutet einen Leistungsverlust, verglichen mit der Bereitstellung von Ressourcen auf Infrastrukturen, die ungeteilt zur Verfügung stehen.

Private Cloud

Private Cloud-Umfelder bezeichnen Infrastrukturen, die ihren Anwenderinnen und Anwendern ungeteilt und exklusiv zur Verfügung stehen. Sie können von großen Cloud-Anbietern zur Verfügung gestellt werden, existieren aber auch in Form von dediziert bereitgestellter Hardware in Rechenzentrum oder auch als klassischer Server-Raum.

Im Unterschied zu Public Cloud-Umfeldern können nutzende Organisationen davon ausgehen, maximale Leistung zur Verfügung zu haben. Nachteilig ist jedoch, dass eine Skalierung in Bezug auf zusätzliche Hardware stets aufwändig und in aller Regel nicht kurzfristig umzusetzen ist.

Aufgrund dessen, dass die zugrundeliegenden Infrastrukturen nicht mit anderen Organisationen, Nutzern und Applikationen geteilt werden, lassen sich in Private Cloud-Umfeldern Workloads mit deutlich höherer Leistung und unabhängig von Dritten besonders datenschutzkonform und compliant betreiben.

Hybrid Cloud

Mischformen aus Public- und Private Cloud-Umgebungen, werden als Hybrid Cloud bezeichnet. Derartige Mischformen versuchen, die Vorteile der verschiedenen Ansätze miteinander zu kombinieren, ohne die Nachteile ebenfalls kombinieren zu müssen.

Hybrid Cloud-Ansätze stellen ein sehr vielversprechendes Instrument in Bezug auf Cloud-Szenarien dar – haben aber ihrerseits ebenfalls einen nicht zu unterschätzenden Nachteil: Die Komplexitäten in Bezug auf das Management von Ressourcen, Governance und Kosten steigen nahezu exponentiell an.

Multicloud

Multicloud stellt im Grunde das äquivalent zu einem Hybrid Cloud-Ansatz dar. Der Unterschied besteht darin, dass mehrere Public Clouds miteinander kombiniert werden. Dies kann beispielsweise in Bezug auf Lizenzkosten von Datenbanksystemen o.ä. sehr viel Sinn ergeben, da es hier fundamentale Unterschiede zwischen den Cloud-Anbietern gibt.

Die Nachteile von Hybrid Cloud-Ansätzen treffen auch hier zu: Das Management von Ressourcen, Governance und Kosten wird um ein Vielfaches komplexer, als wenn nur eine Cloud-Umgebung gemanagt werden muss.

OpEx vs. CapEx

Public Cloud-Umfelder werden üblicherweise als OpEx, Operational Expenses, verstanden. Dies bedeutet, dass Infrastrukturen gemietet sind und nicht vorab bezahlt werden müssen. Bei Private Cloud-Umfeldern kann alternativ auch ein CapEx (Capital Expenses) – Ansatz genutzt werden, bei dem die zugrundeliegende Infrastruktur gekauft und abgeschrieben wird. Langfristig lassen sich so zusätzliche Einsparungen erzielen, jedoch sind initiale Aufwände offensichtlich deutlich höher.

Für ein Service-Modell entscheiden

Neben dem Delivery-Modell gilt es, sich für jeden einzelnen Workload (also jede Applikation, die im Cloud-Umfeld betrieben werden soll) für ein geeignetes Service-Modell zu entscheiden. Dabei gilt, dass es gewaltige Unterschiede zwischen den Modellen in Bezug auf eigene Verantwortlichkeiten und Aufgabenstellungen in Abgrenzung zu den Verantwortlichkeiten des jeweiligen Cloud-Anbieters bzw. Dienstleistern gibt.

In modernen (Cloud-) Umfeldern wird dies als as-a-Service-Ansatz bezeichnet. Der Kunde kauft dabei einen Service ein, die Verantwortlichkeiten der Erbringung des Services liegen beim Anbieter. Derartige Ansätze können auf verschiedenen Ebenen aufgesetzt und genutzt werden, wobei die Ebenen in aller Regel aufeinander aufbauen. Der Anbieter gewährt bestimmte SLAs und KPIs, anhand derer sich die Service-Qualität bemisst.

Infrastructure-as-a-Service

Hier übernimmt der Anbieter die automatisierte Bereitstellung und den Basisbetrieb der Infrastruktur. Das bedeutet, dass er bspw. automatisiert virtuelle Maschinen (und sämtliche dafür benötigte Basisinfrastrukturen) bereitstellt. Der Dienstleister übernimmt die Pflege der Automatisierungen und betreibt die darunterliegende Plattform. Aufgabe des Kunden ist, seine Infrastrukturen (ab Oberkante VMs) selbst zu betreiben – er bekommt sie im IaaS-Modell lediglich bereitgestellt.

Plattform-as-a-Service

Beim PaaS-Ansatz übernimmt der Anbieter die Bereitstellung und den Betrieb von ganzen Applikations- und Infrastrukturplattformen und deren jeweiligen Unterbauten. Dabei kann es sich beispielsweise um Datenbanken, Kubernetes-Infrastrukturen oder Mailsysteme handeln. Die Verantwortung des Kunden beschränkt sich beim PaaS-Ansatz auf das Bereitstellen seiner Workloads (also seiner Applikationen und seiner Daten), die auf der jeweiligen Plattform ausgeführt werden sollen. PaaS-Dienste können – je nachdem, welche Plattform betrieben werden sollen – auch als DBaaS (Database-as-a-Service) oder CaaS (Containerplatform-as-a-Service) bezeichnet werden.

Software-as-a-Service

Beim SaaS-Ansatz übernimmt ein Anbieter den Betrieb von kompletten Ende-zu-Ende-Stacks, d.h., Infrastruktur, Plattform und Applikation. Die Verantwortung des Kunden beschränkt sich im Falle von selbstgeschriebenen Applikationen auf deren Bereitstellung. Im Falle von Standardsoftware (beispielsweise Microsoft 365 oder Atlassian JIRA) hat der Kunde sogar noch weniger Verantwortung: Hier kauft er sich in die jeweilige Software im Sinne von Lizenzen oder Subscriptions ein, ohne sich in irgendeiner Art und Weise um die Leistungserbringung kümmern zu müssen.

Für ein Ziel-Betriebsmodell entscheiden

Beim Umzug in Cloud-Umfelder gilt es ebenfalls, sich für ein Ziel-Betriebsmodell zu entscheiden. Diese Entscheidung, die nicht endgültig sein muss und die vom aktuellen Stand der Applikationen und Infrastrukturen ausgeht, entscheidet darüber, welche Effekte, Kosteneinsparungen und Synergien sich erzielen lassen werden.

Lift & Shift mit traditionellem Applikations- und Infrastrukturbetrieb

Lift & Shift ist der einfachste Weg in Cloud-Umfelder hinein. Hierbei werden lediglich bisherige Infrastrukturen durch Cloud-Infrastrukturen ersetzt, es werden virtuelle Maschinen und beispielsweise DBaaS-Angebote genutzt. Lift & Shift funktioniert am besten mit einer weitestgehenden Infrastruktur- und Bereitstellungsautomatisierung, erfordert aber keine grundlegend neuen Betriebsmodelle verglichen mit traditionellen Rechenzentrumsansätzen. Die Einsparpotenziale beschränken sich hier auf günstigere und flexiblere Infrastrukturkosten und die Verwendung verschiedener Dienste. Größter Vorteil ist in aller Regel die wesentlich schnellere und flexiblere Infrastruktur-Bereitstellung.

Cloud-nativer Betrieb

Wenn Sie alle Mehrwerte von Cloud-Umfeldern ausschöpfen wollen, müssen Sie ganzheitlicher agieren, um Prozesse, Einstellungen und Zusammenarbeitsmodelle anzupassen. Applikationen und Workloads müssen so aufgebaut sein, dass sie kleinteilig und unabhängig voneinander betrieben werden können (Stichwort: Microservices). Ebenfalls müssen sie Metriken exponieren, sodass zentrale Management-Systeme proaktiv mit ihnen umgehen können. Sie müssen automatisch bereitstell- und verwaltbar sein, sodass bei Bedarf neue Instanzen hinzugefügt und auch wieder heruntergefahren werden können. Sie müssen horizontal skalieren können und resilient (im Sinne von angepasst an ständig wechselnde Umfelder) sein.

Daneben muss ein cloud-nativer Betrieb auf eine vollumfängliche Automatisierung eingestellt sein. Das Idealbild ist ein Betrieb, der selbständig auf Änderungen im Vergleich zum gewünschten Zielbild reagiert, Probleme selbständig beseitigt und proaktiv mitigiert. Handarbeit darf nicht mehr vorkommen, Konfigurationen sind versioniert, Infrastrukturen und Workloads werden vollautomatisch bereitgestellt, überwacht und betrieben.

Diese Erwartungshaltungen lassen sich bereits heute in Cloud-Umfeldern umsetzen – und da sprechen wir noch nicht einmal von KI-unterstützten Ansätzen, die noch viel mehr Betriebsintelligenz ermöglichen. Mit einem vollimplementierten cloud-nativen Betrieb lassen sich Kosteneinsparungen von 60%, 70% oder sogar noch mehr, verglichen mit einem traditionellen IT-Betriebsansatz, erzielen!

Cloud als Prozess

Aber: Diese Einsparungen und diese Betriebsansätze lassen sich nicht „einfach mal so“ implementieren. Sie wirken ganzheitlich – und sie müssen auch ganzheitlich wirken, denn wir reden davon, dass sich letztlich nicht nur der Betrieb, sondern auch der Weg zum Betrieb und die Zusammenarbeit zwischen Betrieb, Entwicklung, Sicherheit und Fachbereichen ändern müssen. In Cloud-Umfeldern skalieren wir letztlich nicht nur unsere Workloads und Infrastrukturen, sondern auch unsere Probleme, Sicherheitslücken und manuellen Arbeitsaufwände.

Cloud ist, gerade wenn die möglichen Vorteile im Hinblick auf Einsparungen, Qualitäts- und Effizienzverbesserungen genutzt werden sollen, als disruptiv zu betrachten. Das bedeutet, dass sich Organisationen, deren IT-Umfeld und das Mindset im Umgang mit IT und Infrastrukturen in ihrer Gänze verändern müssen, um eventuelle Vorteile auch tatsächlich zu realisieren.

Aus diesem Grund darf eine Transformation in die Cloud nicht ausschließlich von Technik, Technikern und Technologien gesteuert werden, sondern muss moderiert und orchestriert werden. Und das kann nur mit Unterstützung übergeordneter Hierarchieebenen stattfinden. Dementsprechend ist es nötig, das Thema mit angemessener Aufmerksamkeit und Unterstützung von Seiten des Managements anzugehen. Auch muss die Bereitschaft bestehen, tradierte und bekannte Vorgehensweisen und Modelle zumindest infrage zu stellen und anzupassen, gegebenenfalls sogar durch neue, agilere Ansätze zu ersetzen.

Treffen Sie also zunächst die Grundsatzentscheidung, das Thema „Cloud“ konsequent und ergebnisoffen anzugehen.

Bestandsaufnahme in Bezug auf Cloud-Fähigkeit

Nachdem Sie die grundsätzliche und strategische Entscheidung getroffen haben, sich mit einer Migration in die Cloud zu befassen, muss eine schonungslose Bestandsaufnahme in Bezug auf die Cloud-Fähigkeit ihrer existierenden Infrastrukturen und Software-Lösungen vorgenommen werden.

Dabei sind mindestens folgende Fragen zu beantworten:

  • Welche Systeme können technisch überhaupt in die Cloud migriert werden?
  • Welche Abhängigkeiten haben diese Systeme und können diese Abhängigkeiten in Cloud-Umfeldern abgebildet werden?
  • Wie kommunizieren diese Systeme miteinander?
  • Ist der Zugriff auf diese Systeme in Cloud-Umfeldern überhaupt sinnvoll technisch möglich?
  • Sind die Systeme in einem Cloud-Umfeld in ihrer derzeitigen Form rechtskonform und rechtssicher zu betreiben?
  • Lässt sich Auditing- und Dokumentationspflichten in Cloud-Umfeldern nachkommen?
  • Passen die vorhandenen Lizensierungen noch zu einem Wechsel in Cloud-Umfelder?
  • Sind die Systeme in sich so abgesichert und absicherbar, dass sie sicher in Cloud-Umfeldern betrieben werden können?
  • Welchen Anpassungsaufwand gibt es für diese Systeme und können die Systeme überhaupt angepasst werden?
  • Ist die eigene Infrastruktur (Netzwerke, Firewalls, etc.) auf einen Cloud-Betrieb ausgelegt?
  • Kann ein reiner Cloud-Betrieb erreicht werden oder ist eine hybride Lösung realistischer?
  • Sind Ihre Mitarbeiter in der Lage, die Systeme in Cloud-Umfeldern aufzusetzen und zu betreiben?
  • Lassen Ihre Prozesse und Vorgehensweisen überhaupt eine Migration in Cloud-Umfelder zu?

Üblicherweise werden Sie feststellen, dass sich nicht alle Systeme problemlos in Cloud-Umfelder verlagern lassen. Es kann durchaus auch ein Ergebnis sein, dass das aktuelle Ökosystem weder technisch noch rechtlich oder fiskalisch sinnvoll in ein Cloud-Umfeld transferierbar ist. Das ist per se noch kein KO-Kriterium, sondern ein akzeptabler Zwischenstand, mit dem man arbeiten kann – man würde dann versuchen, eine Migration mittelbar über Neuentwicklungen oder Erweiterungen von existierenden Applikationen anzustoßen.

Identifikation von Pilotapplikationen und -systemen

Im Anschluss an eine erste Bestandsaufnahme sollten Sie Pilotapplikationen und -systeme identifizieren, die als Leuchtturmprojekte dienen können. Deren Aufgabe besteht darin, stellvertretend und exemplarisch typische Probleme bei Migrationen in Cloud-Umgebungen zu lösen.

Es empfiehlt sich, Applikationen und Systeme auszuwählen, die technisch sehr gut für eine Migration geeignet sind, denn erfahrungsgemäß werden dennoch Probleme in Bezug auf Compliance, technische Transformation und Betrieb auftreten. Diese sind aber dann aufgrund der Eignung der Kandidaten mit deutlich geringerem Aufwand zu lösen. Dabei erarbeitete Lösungen können dann später für andere zu migrierende Komponenten genutzt werden, wodurch sich auch dort die Komplexitäten einer Migration verringern lassen.

Es empfiehlt sich in jedem Fall, die Migration existierender Systeme und Applikationen in Cloud-Umfelder als Prozess und nicht als einmaligen Vorgang zu betrachten. Dementsprechend sollten bereits in dieser Phase realistische Erwartungshaltungen kommuniziert und vorgelebt werden.

Identifikation und Beschreibung realistischer Servicelevel und Betriebsprozesse

Bestandsaufnahme und Auswahl von Leuchtturmapplikationen und -systemen versetzen Sie in die Lage, darauf zu schließen, welches Servicelevel (IaaS, PaaS, SaaS) in der Cloud Ihre Applikationen nutzen können.

In aller Regel werden Sie den Einstieg in ein Cloud-Umfeld auf einem IaaS-Servicelevel beginnen. Ihr Ziel muss es strategisch ein, eine tiefere Integration mit der Plattform zu erreichen, sich also auf das PaaS-Level oder das SaaS-Level zu begeben. Dies ist aber meist als ein mittel- bis langfristiger Prozess zu verstehen.

In aller Regel betreiben Cloud-Anbieter keine Applikationen und beschränken ihre Services auf die Oberkanten von Betriebssystemen oder Middleware-Komponenten. Alle darüberhinausgehenden Betriebsprozesse müssen für Cloud-Umfelder angepasst und aufgesetzt werden. Die angebotenen Basis-Level müssen deshalb Ihrem Umfeld in Bezug auf Betrieb und Prozesse angepasst werden, wofür sich erneut das Konzept der Leuchtturmapplikationen und -systeme bewährt, denn hier können in vergleichsweise überschaubarem Rahmen Prozesse und Automatisierungen aufgesetzt werden, die dann später als Blaupause für andere Migrationen dienen können.

Auch hier gilt: Der Weg ist das Ziel – Prozesse und Automatisierungen müssen wachsen und können nicht zwingend unverändert aus klassischen Rechenzentren in Cloud-Umfelder verlegt werden.

Einbinden nichttechnischer Stakeholder

Bevor Sie auch nur die erste Applikation tatsächlich in ein Cloud-Umfeld verschieben und dort betreiben, empfiehlt es sich dringend, auch nichttechnische Stakeholder – also Fachabteilungen und auch den Betriebsrat – mit einzubeziehen.

Dies kann vordergründig durchaus als nachteilig in Bezug auf Migrationsgeschwindigkeiten und Tiefe der in die Cloud zu verlagernden Leistungen empfunden werden, jedoch sollten Sie eventuelle Beharrungskräfte und die Möglichkeiten des aktiven bzw. passiven Widerstands gegen diese, oftmals als Bedrohung empfundenen, Veränderungen keinesfalls unterschätzen.
Es ist deshalb ratsam, Stakeholder schon im Rahmen der Bestandsaufnahme zu identifizieren und regelmäßig einzubeziehen. Somit können Verstimmungen und eventuelle Probleme zeitnah erkannt und mit genügend Vorlauf mitigiert werden.

Iteratives Vorgehensmodell etablieren

Eine nachhaltige Migration in Cloud-Umfelder lässt sich nicht ad-hoc bewerkstelligen. Gleiches gilt für Betriebs- und Interaktionsprozesse. Setzen Sie deshalb iterative Prozesse auf, die kleine Schritte mit definierten Start- und Endszenarien umfassen. Diese Prozessschritte sollten für jede Applikation durchlaufen werden und umfassen in aller Regel folgende Teilprozessschritte:

  • Detailanalyse der Applikation und ihrer Abhängigkeiten
  • Erstellen eines Migrationsplans
  • Aufsetzen automatisierter Infrastrukturprovisionierungen
  • Aufsetzen von Infrastruktur- und Konfigurationsversionierungen
  • Aufsetzen automatisierter Applikations- und Systembereitstellungen
  • Aufsetzen bzw. Anpassen von automatisierten Betriebsprozessen
  • Aufsetzen bzw. Anpassen automatisierter Logging- und Monitoringprozesse inklusive Definition von Schwell- und Grenzwerten
  • Durchführen des automatisierten Deployments – Schrittweise Inbetriebnahme der Applikation
  • Schulungen und Einweisungen
  • Inbetriebnahme der Applikation

Derartige Vorgehensmodelle lassen sich für eine Vielzahl von Applikationen und Systemen nutzen und sollten gleich mit den ersten Leuchtturmprojekten etabliert werden.

Angepasste und agile Betriebsmodelle entwickeln und umsetzen

Cloud-Umfelder bieten hochgradig automatisierte und agile Umgebungen für Applikationen und Systeme. Diese dann nach klassischen ITIL-Prozessen zu betreiben, bedeutet in aller Regel Handarbeit und langwierige Entscheidungs- und Abstimmungsprozesse – und führt somit die Vorteile, die Cloud-Umfelder bieten können, ad absurdum.

Entsprechend ist es wichtig, agile und angepasste Betriebsmodelle zu entwickeln, die stark auf autonome Expertenteams, Automatisierung und Versionierung im Betrieb sowie eine effektive Wissensverteilung setzen. Wenn Sie versuchen, Cloud-Lösungen analog zu klassischen Lösungen zu betreiben, werden Sie feststellen, dass sich die Gesamtkosten nicht verringern, sondern im Gegenteil sogar erhöhen können.

Ein entscheidender Aspekt für den Erfolg von agilen Betriebsmodellen ist die Einführung von DevOps-Prozessen. Dabei geht es weniger um technologische Aspekte, sondern viel eher um Zusammenarbeitsmodelle, die nicht nur auf Entwicklung und Betrieb beschränkt sind, sondern alle Stakeholder involvieren. DevOps-Teams sind viel enger miteinander integriert als dies bei herkömmlichen Zusammenarbeitsmodellen der Fall ist und können so Wissen deutlich besser aufbauen und verteilen, effektiver auf Probleme und Herausforderungen reagieren und auf diese Art Kosten, Iterations- und Bereitstellungszeiträume bei gesteigerter Qualität deutlich verringern.

Etablieren Sie bewusst agile und auf DevOps basierende Betriebs- und Interaktionsmodelle, da Sie andernfalls keineswegs substanzielle Einsparungen im Betrieb von Applikationen und Infrastrukturen erzielen können! Betrachten Sie auch dies als agilen und iterativen Prozess, der eigentlich niemals so richtig abgeschlossen sein wird.

Angepasste und modularisierte Applikationen entwickeln

Weiterentwicklungen an in Cloud-Umfeldern laufenden Applikationen sollten cloud-nativ gestaltet und betreibbar sein. Dies bedeutet, dass sie in PaaS-Umfeldern laufen sollten und sich tief mit diesen Infrastrukturen integrieren, die Bereitstellung der Applikationen und der benötigten Infrastrukturen muss automatisiert erfolgen und die Applikationen geben über sich selbst und ihren Zustand über definierte Schnittstellen Auskunft.

Somit können automatische Skalierungs- und Verfügbarkeitsmechanismen genutzt werden, Weiterentwicklungen sind technologieunabhängig möglich und Änderungen werden beherrschbar. Ziel muss es langfristig sein, entweder alle Applikationen entsprechend dieser Prinzipien aufzubauen oder zumindest Neu- und Weiterentwicklungen derartig zu gestalten. Applikationen, die nicht in Cloud-Umfeldern lauffähig sind oder dort aus Sicherheits- oder Compliance-Gründen nicht ausgeführt werden sollen, können somit um in Cloud-Umfelder integrierte Komponenten erweitert werden und mittelbar von den Cloud-Vorteilen profitieren.

Auch hier gilt im Hinterkopf zu behalten, dass Entwicklung, Migration und Anpassung von Applikationen für Cloud-Umfelder iterative und langfristig angedachte Schritte sind. Keinesfalls sollten alle Applikationen kurzfristig umgestellt oder gar neu geschrieben werden!

Fazit: In die Cloud mit Commitment und Planung!

Die wichtigsten Erfolgsfaktoren für das Erschließen von Cloud-Umfeldern sind Commitment und strukturierte Planung. Commitment ist deshalb so wichtig, weil eine Migration in eine Cloud-Welt immer problematisch ist. Gewohnte Vorgehensweisen und Ansätze müssen aufgegeben, neue Prozesse etabliert, Automatisierung und andere Zusammenarbeitsmodelle müssen eingeführt werden. Dies gelingt nur mit entsprechender Unterstützung, Forderung und Förderung durch die Entscheidungsträger.

Strukturierte Planung im agilen, iterativen Sinne ist unverzichtbar, da Komplexitäten und Schwierigkeiten von Migrationen in Cloud-Umfelder enorm sein können. Ein Wasserfallansatz wäre dabei kontraproduktiv, sinnvoll sind definierte, abgrenzbare und sinnvoll geplante Teilschritte, die iterativ aufeinander aufgebaut sind.

Sehen Sie eine Migration in Cloud-Umgebungen als Prozess, als Summe vieler kleiner Teilschritte, die keinesfalls nur technische Aspekte beinhalten, sondern stark auf angepasste Zusammenarbeits- und Interaktionsmodelle angewiesen sind und auch tradierte und über Jahrzehnte erprobte Vorgehensweisen infrage stellen und durch moderne, agile, auf DevOps-Prinzipien basierende Alternativen ersetzen können und sollen.

Auf Cloud muss man sich einlassen – in Organisation, Prozessen und Technik. Cloud ist ganzheitlich, entsprechend muss auch Ihre Herangehensweise sein!

 

Karsten Samaschke
Gründer und Geschäftsführer der Cloudical Deutschland GmbH

karsten.samaschke@cloudical.io