So klappt es mit der Cloud-Migration

Cloud 2019 Technology & Services Conference

 | Autor / Redakteur: Dr. Dietmar Müller / Florian Karlstetter

Am 10. September startet die Cloud 2019 Technology & Services Conference im Kameha Grand in Bonn. Die Verfasser sprachen im Vorfeld der Veranstaltung mit Dr. Sven Seiler, Manager Cloud Computing, Storm Reply über die schwierige Lage, in der sich Unternehmen bei der Migration von Anwendungen in die Cloud befinden. Mehrere komplizierte Entscheidungen müssen dabei getroffen werden.

Herr Dr. Seiler, in Ihrer Keynote „Ihre Reise in die Cloud – A Cloud Journey“ auf der Cloud 2019 werden Sie eine „bewährte Vorgehensweise zur Cloud-Adoption“ vorstellen? Welche Techniken haben sich denn Ihrer Erfahrung nach bereits bewährt?

Dr. Seiler: Bei Reply setzen wir auf das „Reply Cloud Adoption Framework“, welches das bekannte und bewährte „AWS Cloud Adoption Framework“ (CAF) um unsere Erfahrungen aus mehr als 500 erfolgreich umgesetzten Cloud-Projekten ergänzt und erweitert. Initialer Schritt der Anwendung unseres Reply Cloud Adaption Frameworks ist ein Workshop, der gemeinsam mit und bevorzugt auch direkt bei dem Kunden vor Ort abgehalten wird. Dieser Workshop dient der Klärung der Bedürfnisse des Kunden, und hat insbesondere das Ziel zu klären, wie der individuelle Fokus des Kunden bezüglich seiner Cloud Journey ist. Das Ziel kann dabei zum Beispiel „nur“ sein, einen Data Lake aufzubauen oder eine Chatbot-Lösung umzusetzen. Gleichzeitig gibt es aber ebenfalls auch Kunden, die bereits die Entscheidung getroffen haben „all in“ in die Cloud zu gehen. In einem solchen Fall sind dann jeweils zunächst die Schwerpunkte der Betrachtung zu definieren, somit den für den Kunden optimal passenden Fokus zu setzen, und diese Schwerpunkte entsprechend weitergehend zu analysieren, um die passenden Lösungen entwickeln und umsetzen zu können.

Hierfür erstellen wir im Folgenden auf Basis der Ergebnisse des Workshops und gegebenenfalls weiteren flankierenden Gesprächen einen individuell auf den Kunden zugeschnittenen Aktionsplan, der insbesondere Betrachtungen der folgenden geschäftlich relevanten Aspekte „Business“, „Mitarbeiter“ und „Governance“ umfasst. Daneben beinhaltet dieser Aktionsplan ebenfalls noch eher „technische“ Aspekte. Hierbei werden insbesondere die Aspekte „Plattform“, „Sicherheit“ und „Betriebsablauf“ mit in das Kalkül gezogen.

Im Vorfeld der Veranstaltung haben Sie erklärt, dass auf dem Weg in die Cloud „neue Fähigkeiten aufgebaut und bestehende Prozesse angepasst werden müssen“ – an was haben Sie dabei konkret gedacht?

Dr. Seiler: Der Prozess einer Cloud Adoption unterscheidet sich von der Art und Vorgehensweise, die früher über Jahrzehnte hinweg im Rahmen der „klassischen“ Softwareentwicklung und des „klassischen“ Betriebs einer Softwarelösung Anwendung fand beziehungsweise „gelebt wurde“. Zu den elementaren Punkten der Softwareentwicklung im Cloud-Zeitalter gehören für mich:

  • Die agile Entwicklung, das heißt kürzere Produkt- beziehungsweise Release-Zyklen, und somit eine deutlich schnellere Innovation.
  • Der Aufbau von neuer Software auf Basis bestehender, teilweise millionenfach eingesetzter und somit bewährter Services, hier wäre die „Service-Orchestrierung“ zu nennen.
  • Die Virtualisierung erlaubt den Aufbau von Testumgebungen, welche eins zu eins der späteren Produktivumgebung entsprechen können, und somit ein sehr viel „realitätsnäheres“ Testen der umgesetzten Lösung, ohne die Gefahr – oder zumindest mit einer deutlich verringerten Gefahr – von „Fallstricken“, die sich in früheren Zeiten oftmals aus Unterschieden zwischen einer Test- und Produktivumgebung ergeben haben.
  • Die Test- und Referenzumgebungen können bei Nichtgebrauch flexibel hoch- oder insbesondere auch heruntergefahren werden, was die massive Einsparung von Infrastruktur- und Betriebskosten ermöglicht.

Zu den elementaren Punkten des Betriebs im Cloud-Zeitalter gehören:

  • Die Virtualisierung von Hardware ermöglicht es, diese binnen extrem kurzer Zeit zu provisionieren, wir sprechen von Sekunden bis Minuten, und nimmt nicht mehr wie zuvor sehr lange Zeiten in Anspruch – Tage, Wochen oder vielleicht sogar Monate -, da keine umfangreichen und somit langwierigen Bestell- und insbesondere Lieferprozesse mehr existieren.
  • Es gilt das „Pay per use“-Prinzip, das heißt es erfolgt nur eine Bezahlung der tatsächlich genutzten Ressourcen als da wären Rechenzeit, Speicherplatz, etc.. Insbesondere entfällt hierbei auch die zuvor notwendige, jahrelange Abschreibung von physikalisch angeschaffter Hardware, was zuvor auch immer das Risiko beinhaltete, auf der einen Seite diese anfallenden Kosten tragen zu müssen, auf der anderen Seite die Hardware oder Infrastruktur, die diese Kosten verursacht, möglicherweise nicht oder nicht vollständig beziehungsweise permanent zu nutzen. Der im Cloud-Zeitalter verfolgte Ansatz lautet somit eher „Aufsetzen, evaluieren, und bei festgestellter Nichteignung einfach und ohne Zukunftskosten wieder verwerfen”.
  • Möglichkeit zur Ausnutzung vieler bereits direkt durch den jeweiligen Cloud-Anbieterbereitgestellter Mechanismen und Services, die einen hochverfügbaren und skalierbaren Betrieb „out-of-the-box“ ermöglichen, ohne die Notwendigkeit, sich selbst bis in die technischen Details dieser Lösungen einarbeiten zu müssen, beziehungsweise selbst entsprechende Lösungen auszuarbeiten und umsetzen zu müssen. Beispielsweise bietet AWS mit Amazon Aurora eine Datenbanklösung an, für die neben einem sehr viel höheren Datendurchsatz – verglichen mit Standard-MySQL- oder PostgreSQL, zu denen diese Lösung dennoch kompatibel ist – ebenfalls noch eine Verfügbarkeit von 99,99 Prozent und eine konstante Leistungsfähigkeit durch für den Benutzer transparente Speicherskalierung im Hintergrund zugesichert wird.

Dr. Seiler: Oftmals gilt es in einem ersten Schritt, eventuell vorhandene „Skepsis“ der Teams beziehungsweise Teammitglieder gegenüber „der Cloud“ abzubauen. Dieses findet sich nicht nur, aber zumindest doch gehäuft im Bereich des Betriebs von Software in der Cloud wieder, und ist zumeist in mangelnder Kenntnis ob der Möglichkeiten – und vor allem der Vereinfachungen, welche ein Betrieb in der Cloud mit sich bringt – begründet.

Eine sehr gut bewährte Strategie zum Abbau derartiger Vorbehalte gegenüber der Cloud ist das Veranstalten von sogenannten „Hackathons“, das heißt von Veranstaltung, in denen optimalerweise heterogen aufgestellte Teams versuchen, gemeinsam und in kurzer Zeit exemplarisch eine Lösung für ein gestelltes Problem zu entwickeln, und dabei auch „spielerisch“ die von der Cloud bereitgestellten Möglichkeiten zu erleben und ebenfalls auch auszuprobieren. Erfahrungsgemäß wird dem einzelnen Beteiligten so eine eventuell anfänglich vorhandene Skepsis gegenüber der auf den ersten Blick in der Tat nur sehr schwer greifbaren Cloud und den durch diese bereitgestellten Möglichkeiten genommen, es werden erste praktische Erfahrungen gesammelt und erste Fähigkeiten gewonnen, welche sich in einem zukünftigen Projektverlauf sukzessive weiter auf- und ausbauen lassen.

Cloud Computing hat sich auch in Deutschland flächendeckend durchgesetzt, dessen ungeachtet gibt es aber jede Menge Hindernisse für den Einsatz. Was sind aus Ihrer Sicht die größten technischen Hürden auf dem Weg in die Cloud?

Dr. Seiler: Die oftmals größte Hürde, welche auf dem Weg in die Cloud überwunden werden muss, ist zugleich ebenfalls meist die erste Hürde, die es zu überwinden gilt – nämlich die Analyse von in der Regel meistens bereits bestehenden Systemlandschaften. Erfahrungsgemäß sind bereits bestehende Systemlandschaften in der Regel über eine lange Zeit hinweg sukzessive gewachsen, dieser Zeitraum kann Jahre, teilweise abhängig von der Branche auch Jahrzehnte umfassen, so dass es oftmals der Fall ist, dass keine vollständigen beziehungsweise keine vollständig korrekten Dokumentationen dieser Systemlandschaften existieren. Infolgedessen ist das Zusammenspiel der einzelnen Komponenten in einem solchen System teilweise nur äußerst schwer zu erkennen, was das Übertragen einer solchen Systemlandschaft in die Cloud oftmals herausfordernd macht.

Daher ist einer der ersten – und zugleich einer der elementarsten – Schritte in einem derartigen Fall in der Regel die Analyse der bestehenden Systemlandschaft, und hierbei insbesondere die Identifikation der voneinander abhängigen Systemkomponenten. Das Ergebnis einer solchen Analyse ist dementsprechend die Dokumentation des aktuellen „Ist-Zustands“ des Systems. Sobald diese Analyse abgeschlossen ist, und der Ist-Zustand des Systems somit bekannt und dokumentiert ist, ist die häufig größte Hürde auf dem Weg in die Cloud bereits überwunden, und einer technischen Umsetzung stehen in der Regel keine signifikanten Hindernisse mehr im Weg.

Was ist Ihrer Erfahrung nach beim Weg in die Cloud auf organisatorischer Ebene zu beachten?

Dr. Seiler: Auf arbeitsorganisatorischer Ebene ist zu beachten, dass möglichst sämtliche Ebenen eines Unternehmens mit eingebunden sein sollten, um eine erfolgreiche Cloud Journey gewährleisten zu können. Offensichtlich ist es, dass für eine solche Journey Software Entwickler, Cloud Architekten und im Bereich des Software-Betriebs angesiedelte mit einzubinden und für diese zu begeistern sind. Daneben muss aber zum Beispiel eine entsprechende Strategie auch die Personalabteilung entsprechend durchdringen, damit dort bekannt ist, dass die für eine erfolgreiche Umsetzung einer solche Strategie auf dem Markt die entsprechenden Fachkräfte gewonnen werden müssen, da diese erfahrungsgemäß zu dem Zeitpunkt des Einstiegs in die Cloud Journey noch nicht im Unternehmen vorhanden sind, da sie bis dato nicht benötigt wurden.

Dieses gilt gegebenenfalls analog ebenfalls für den Einkauf eines Unternehmens, sofern ein solches die initial benötigen Ressourcen beziehungsweise Fachkräfte nicht selbst einstellen will, sondern bevorzugt auf externe Unterstützung zurückgreifen möchte. Nicht zuletzt ist es so, dass ebenfalls auf „C-Level-Executive“-Ebene ein entsprechendes Bewusstsein vorhanden sein oder geschaffen werden muss, um eventuellen intern auftretenden Widerständen zu begegnen, organisatorische „Steine“ aus dem Weg zu räumen – „das haben wir aber immer so gemacht“ ist hier ein häufig gehörter Einwand -, und sowohl eine personell als auch betriebswirtschaftlich solide Planung der Cloud Journey zu gewährleisten.

Daneben ergeben sich aufgrund der neuen Strukturen und Vorgehensweisen beziehungsweise Vorgehensmodelle, welche oftmals bei der Entwicklung in der Cloud Anwendung finden oder Anwendung finden sollten gewisse Verschiebungen bezüglich „alter“, das heißt lange Zeit vorhandener Zuständigkeiten. Beispielsweise gab es traditionell oftmals eine mehr oder minder harte Trennung zwischen der Entwicklung einer Software einerseits, und dem Betrieb dieser andererseits. Bei der Entwicklung in der Cloud wird hingegen sehr oft dem „DevOps“-Ansatz gefolgt, bei dem das Team, welches eine Software oder eine Softwarekomponente entwickelt hat, ebenfalls auch für den Betrieb dieser zuständig ist – im Englischen oftmals beschrieben als „You build it, you run it!“.

Dementsprechend sind hier dann die gegebenenfalls neuen Zuständigkeiten zu klären, eventuell auch neue Rollen – wie eben zum Beispiel genau die eines DevOps-Engineers – einzuführen, und die diese neuen Rollen besetzenden Personen für ihr potentiell neues Aufgabenspektrum zu begeistern.

[Quelle: CloudComputing Insider]

Schreibe einen Kommentar