Sponsored Post Was ist das?

Move it, move it? Workloads in die Public Cloud umziehen lassen

Der Umzug in die Public Cloud will gut vorbereitet sein. (Foto: Adobe Stock/Worawut)

Anzeige

Den Umzug in die (Public) Cloud erledigt man nicht mal so eben nebenbei – gute Vorbereitung ist, wie so oft, alles. Ein wichtiger Teil davon: die Analyse der Workloads, die in die Cloud verlagert werden sollen.

Wer Workloads in die Cloud verlagern will, sollte die Ausgangssituation gründlich unter die Lupe nehmen (Ist-Analyse) und mit den jeweiligen Anforderungen abgleichen (GAP-Analyse). So können der Umfang des Projekts sinnvoll abgeschätzt und notwendige Anpassungen frühzeitig eingeplant werden.

Die Auseinandersetzung mit dem Umzug in die Public Cloud fängt oft bei den übergeordneten Überlegungen an: Welche Zielsetzung verfolgt mein Unternehmen überhaupt mit seiner (vielleicht noch auszubuchstabierenden) Cloud-Strategie? Auch allgemeine Betrachtungen zu IT- und Datensicherheit, Compliance und organisatorischen Rahmenbedingungen stehen dabei auf der Tagesordnung.

Daneben liegt der Fokus aber vor allem auf den Eigenschaften der einzelnen Workloads, die in die Cloud wandern sollen. Denn: Nicht jeder Workload ist ohne Anpassungen uneingeschränkt public-cloud-tauglich. Verwirrung entsteht gelegentlich, wenn es um den Unterschied zwischen Anwendungen und Workloads geht. Die Begriffe sind eng miteinander verbunden, meinen aber Unterschiedliches: Unter einer Anwendung versteht man Code, der eine vorgegebene Funktion ausführt. Ein Workload beinhaltet eine solche Anwendung, aber auch die dazugehörigen Daten, Prozesse, (Netzwerk-)Ressourcen und User.

Mit der passenden Vorbereitung lassen sich auch komplexe Workloads sicher in die Public Cloud bringen. (Adobe Stock/Sergey Nivens)

Unter welchen Gesichtspunkten sollten die einzelnen Workloads analysiert werden?

claranet
claranet

Claranet unterstützt Unternehmen auf ihrem Weg in die (Public) Cloud.

  • Architektur und Umfang: Individual- und Legacy-Anwendungen sind in der Regel in ihrer Struktur schwerer zu erfassen und müssen teilweise umfangreich auf Code-Ebene untersucht werden, bevor sie migriert werden können, da die Dokumentation gegebenenfalls unvollständig oder veraltet ist, und der Aufbau teilweise historisch statt logisch gewachsen ist. In manchen Fällen müssen die Anwendungen auch grundlegend umstrukturiert werden, um effizient in der Public Cloud betrieben werden zu können. Container-basierte Workloads und Microservices-Architekturen sind hingegen recht unkompliziert in der Handhabung. Interessant ist dann gegebenenfalls auch die Größe des Workloads, also etwa die Anzahl der virtuellen Maschinen oder Container. An dieser Stelle kann auch überlegt werden, ob der gesamte Workload oder nur Teile davon in die Public Cloud umziehen sollen.
  • Operations: Für die Vorbereitung des Umzugs und die Abschätzung der „Public Cloud Readiness“ ist auch von Bedeutung, wo der Workload aktuell betrieben wird – ob im organisationseigenen Rechenzentrum, bereits bei einem Hosting- oder gegebenenfalls schon Cloud-Hosting-Provider. Wird der Workload schon extern betrieben, sind in der Regel bereits sicherheits- und datenschutzrelevante Vorkehrungen getroffen und Prozesse angepasst worden.
  • Integrationstiefe: Hier gilt grundsätzlich: Je mehr Schnittstellen und geteilte Prozesse mit anderen Anwendungen/Workloads bestehen, desto planungsintensiver ist die Cloud-Migration. Stand-alone-Anwendungen beziehungsweise -Workloads sind entsprechend am unkompliziertesten in der Handhabung, während bei voll in ihre Umgebung integrierten Workloads zahlreiche Abhängigkeiten berücksichtigt werden müssen.
  • Release-Management, Deployment: Ebenfalls interessant ist, in welchen Rhythmen die zum Workload gehörige Anwendung mit neuen Features/Codeänderungen versehen wird. Das Spektrum ist groß und reicht von wenigen Anpassungen jährlich bis zu mehreren Deployments pro Tag, wenn mit Continuous Delivery gearbeitet wird. Warum ist das wichtig? Abhängig von der Deployment-Häufigkeit und -Methode variieren auch die Anforderungen an die Automatisierbarkeit der jeweiligen Prozesse.
  • Datenbanktechnologie: Die Migration von Datenbanken kann ausgesprochen zeitintensiv sein. Insbesondere, wenn es sich um eine sogenannte heterogne Migration, zum Beispiel von Oracle SQL auf Microsoft SQL, handelt. In diesen Fällen ist es gegebenenfalls sinnvoll, spezielle Tools zu nutzen, die Ausfallzeiten während der Datenbankmigration minimieren oder sogar ganz verhindern.

Eine vollständige Cloud-Strategie braucht ein Operations-Konzept

Aus der detaillierten Beschäftigung mit den einzelnen Workloads erhält man wertvolle Hinweise für die Gestaltung des Migrationsprozesses und natürlich auch für das Design der Zielarchitektur. Doch neben der Frage, wie die neue Cloud-Architektur aussehen muss und wie man den Weg dorthin schafft, ist es auch wichtig, zu beleuchten, wie der Betrieb in der Praxis geregelt werden soll. Hierfür muss ein eigenes Konzept erstellt werden, das Rollen und Verantwortlichkeiten klärt – intern und zwischen Organisation und IT-Dienstleister. Denn der Bereich der Cloud-Operations umfasst zahlreiche komplexe Aufgaben wie Monitoring, Security-Management, Compliance- und Audit-Management, die sorgfältig definiert und koordiniert werden müssen. Insofern ist bei der Workload-Analyse längst nicht Schluss!

Du willst wissen, wo dein Unternehmen bei der Verlagerung seiner Workloads in die Public Cloud steht und hättest gern darauf aufbauende Tipps? Dann mach fix den Public Cloud Transition Check von Claranet oder lass dich direkt von den Claranet-Profis bei dem Umzug in die Public Cloud unterstützen!

Jetzt den Cloud-Check machen!
Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 65 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Stephan Dörner (Chefredakteur t3n.de) & das gesamte t3n-Team

Anleitung zur Deaktivierung