High-Level-Strategie
Sobald ein Unternehmen festgestellt hat, dass es für den Wechsel in die Cloud bereit ist, müssen eine Reihe kontextspezifischer Entscheidungen getroffen werden. Eine allgemeine Leitstrategie ist von entscheidender Bedeutung.
Wenn Sie Ihre Ziele und die Probleme darlegen, die Sie mit Ihrer Cloud-Migrationsstrategie angehen möchten, können Sie sicherstellen, dass Ihre Geschäfts- und Technologiestrategien aufeinander abgestimmt sind. Was hoffen Sie zu erreichen?
- Versuchen Sie, Kosten zu senken oder die Markteinführungszeit zu verkürzen?
- Haben Sie Schwierigkeiten, qualifiziertes Personal zu gewinnen und zu halten?
- Versuchen Sie, die Qualität Ihrer Produkte oder Dienstleistungen zu verbessern?
- Sind diese Ziele dringend oder langfristig?
- Gibt es Compliance-Anforderungen, die beim Umzug in die Cloud erfüllt werden müssen?
Diese Faktoren sind entscheidend für die Festlegung, wie Ihre Cloud-Migrationsstrategie aussehen sollte.
Händlerwahl
Für eine relativ kleine Organisation mit homogenen Workload-Anforderungen könnte eine Cloud-Strategie mit einem einzigen Anbieter am besten geeignet sein, da kaum die Notwendigkeit besteht, in mehrere Cloud-Anbieter zu investieren, um technische Redundanz zu gewährleisten oder eine Anbieterbindung zu vermeiden.
Eine viel größere Organisation, beispielsweise eine globale Bank mit vielfältigen Arbeitslasten und unterschiedlichen technischen Anforderungen, würde eher eine Multi-Cloud-Strategie verfolgen, da dies jedem Projektteam die Flexibilität geben würde, den Anbieter auszuwählen, der seinen Anforderungen am besten entspricht . Darüber hinaus müssen größere Unternehmen eher interne und externe Compliance-Anforderungen erfüllen, und diese erfordern möglicherweise die Fähigkeit, Arbeitslasten relativ kurzfristig zwischen Cloud-Anbietern zu verschieben.
Eine Hybridstrategie, bei der sowohl ein klassisches Rechenzentrum als auch ein oder mehrere Cloud-Anbieter beteiligt sind, kann auch für mittlere bis große Unternehmen sinnvoll sein, insbesondere wenn sich der Übergang zur Cloud über mehrere Jahre erstreckt. Diese Strategie kann auch relevant sein, wenn Sie Ihre Cloud-Migrationstaktiken dynamischer weiterentwickeln müssen, während Sie mehr über die Implementierung von Cloud-Technologien in Ihrem Unternehmen erfahren.
Die Six R's
Sobald Sie Ihre Cloud-Migrationsziele und die Anbieterstrategie festgelegt haben, besteht der nächste Schritt darin, zu entscheiden, wie Sie bei der Migration Ihrer Workloads in die Cloud vorgehen.
Zunächst sollten Sie eine Prüfung Ihrer bestehenden Anwendung durchführen. Dies kann Ihnen einen Eindruck vom Umfang und der Art der Arbeit vermitteln, die für den Wechsel in die Cloud erforderlich ist. Bei diesem Audit können Sie Ihre Anwendung anhand des Ansatzes klassifizieren, den die dafür verantwortlichen Teams bei der Cloud-Migration verfolgen sollen. AWS skizziert sechs „gemeinsame Migrationsstrategien“. Diese können flächendeckend angewendet werden, oder jedes Team kann je nach Größe der Organisation und Komplexität die Strategie wählen, die zu diesem Zeitpunkt am besten zu seiner jeweiligen Struktur passt.
1. Rehosten
Die erste und einfachste Strategie ist das Rehosten Ihrer Anwendung (auch bekannt als „Lift and Shift“). Dabei werden sie von physischen Servern, die in einem Rechenzentrum laufen, auf virtuelle Server verschoben, die in der Cloud laufen. Im Allgemeinen sind hierfür keine Codeänderungen und relativ wenige Änderungen an Prozessen und umgebenden Technologien wie Netzwerken erforderlich. Es kann Ihrem Unternehmen auch ermöglichen, die Cloud-Kenntnisse und -Erfahrung zu entwickeln, die für andere Cloud-native Praktiken erforderlich sind.
2. Ersetzen Sie die Plattform
Dieser auch als „Lift, Tinker and Shift“ bekannte Ansatz ähnelt dem Rehosting, geht jedoch noch einen Schritt weiter, indem er eine Reihe grundlegender Cloud-Dienste auf Anwendungsebene integriert. Beispielsweise könnte AWS IAM (Identity and Access Management) in Ihre Anwendung integriert werden, um traditionellere, auf Rechenzentren ausgerichtete IAM-Systeme zu ersetzen oder zu ergänzen.
3. Rückkauf
Bei diesem Ansatz, der auch als „Drop and Shop“ bezeichnet wird, wird eine vorhandene lokale Anwendung durch einen lizenzierten Cloud-basierten Dienst ersetzt. Dies kann eine Änderung des von Ihrem Unternehmen verwendeten Lizenzmodells, eine Senkung der Wartungskosten und möglicherweise die Ermöglichung eines schnelleren und einfacheren Upgrades umfassen.
4. Refactor/Rearchitect
Ein eher Cloud-nativer Ansatz besteht darin, Ihre vorhandenen Codebasen zu übernehmen und sie zu ändern oder zu erweitern, um in moderneren Cloud-Diensten zu funktionieren. Ein Beispiel ist die Containerisierung Ihres Anwendungscodes, die Ausführung der Konfiguration und die Ausführung innerhalb eines Cloud-basierten Kubernetes-Dienstes wie Amazons EKS oder Azure AKS. Dies kann erhebliche Umschreibungen Ihrer vorhandenen Codebasis erfordern, damit diese funktioniert und die Skalierbarkeit erhöht wird. Möglicherweise ist sogar eine vollständige Neufassung erforderlich, um wirklich Cloud-native Tools (z. B. serverlose Tools wie AWS Lambda oder Azure Functions) zu verwenden.
5. In den Ruhestand gehen
Bei den letzten beiden „passiven“ Strategien werden die Workloads überhaupt nicht in die Cloud verlagert. Bei Ihrer Workload-Prüfung können Systeme aufgedeckt werden, die entweder redundant sind oder sich nicht mehr warten lassen. Diese Anwendung kann eingestellt werden.
6. Behalten
Die letzte „passive“ Strategie, die Aufbewahrung, besteht darin, Ihre Anwendung am Laufen zu halten und sich dafür zu entscheiden, sie auf absehbare Zeit nicht in die Cloud zu migrieren. Es gibt eine Reihe möglicher Gründe, Ihre Anwendung außerhalb der Cloud zu behalten, darunter:
- Regulatorische Einschränkungen, wo Anwendungen ausgeführt werden können, oder hohe interne Compliance-Anforderungen an die Sicherheit
- Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
- Es gibt keinen Business Case für die durch die Verschiebung der Anwendung verursachte Störung
- Legacy-Systeme werden in Cloud-Umgebungen nicht unterstützt
Wo soll ich anfangen?
Zusätzlich zur Festlegung Ihrer Gesamtstrategie und der Klassifizierung des taktischen Ansatzes pro Workload benötigen Sie einen Plan zum Aufbau Ihrer Cloud-Infrastruktur, um die Bewegung von Workloads zu unterstützen. Ein Ansatz besteht darin, jedes Team selbst entscheiden zu lassen, wie es seine eigenen Systeme in der Cloud aufbaut. Dieser Ansatz hat jedoch mehrere Nachteile, da Teams möglicherweise Anti-Implementierungsmuster duplizieren und sich gegenseitig Fehler wiederholen oder gegen interne/externe Compliance-Regeln verstoßen.
Ein alternativer Ansatz besteht darin, eine Art zentralisiertes „Center of Excellence“ oder Cloud-Infrastrukturteam einzurichten. Dieses Team kann die Kernsysteme festlegen, auf denen andere Teams ihre Arbeitslasten ausführen können.
Bei der Einrichtung dieser Leitplanken gibt es bestimmte Gestaltungselemente, die Vorrang vor anderen haben sollten.
Konten
Die grundlegendste Einheit Ihrer Cloud-Architektur ist das Cloud-Konto. Die Verwendung eines einzigen Kontos in Ihrem Unternehmen lässt sich fast immer nicht skalieren, da Sie letztendlich an die Kontolimits stoßen. Daher ist es wichtig, die Kontogrenzen festzulegen. Wird das Konto zur Darstellung einer bestimmten Geschäftseinheit, eines einzelnen Teams oder einer Gruppierung von Softwarediensten verwendet? Wie wird das in Ihrer Finanzabteilung funktionieren? Wer soll die Rechnung erhalten? Es ist wichtig, dies frühzeitig herauszufinden, da die Kosten schnell in die Höhe schnellen können.
IAM
Die nächstgrundlegende Einheit der Architektur ist das Identitäts- und Zugriffsverwaltungssystem . Wenn Ihre Cloud-Infrastruktur wächst, müssen Sie die Sicherheitsauswirkungen des Benutzerzugriffs auf die verschiedenen Cloud-Dienste und -Daten berücksichtigen – je früher, desto besser. Es kann kompliziert sein, diese Regeln nachträglich auf bereits laufende Systeme anzuwenden.
Netzwerk
Die Migration in die Cloud beinhaltet entweder die Virtualisierung Ihres bestehenden Netzwerks oder eine komplette Neugestaltung. Mit dem VPC- (AWS) oder VNet- (Azure) Dienst können Sie ein isoliertes Netzwerk einrichten, um einen separaten Satz von Diensten innerhalb Ihres Kontos auszuführen. Die Internetkommunikation zwischen den Diensten Ihrer Organisation und grundlegenden Netzwerkressourcen wie IP-Adressen muss sorgfältig geprüft werden.
Datenmigration
Während es einfach ist, Rechendienste in die Cloud zu verlagern, kann die Migration von Daten etwas schwieriger sein. Bei großen Datenspeichern kann es sich um große, komplexe Infrastrukturen handeln, deren Umzug sorgfältig geplant werden muss. Dies erfordert ein ausreichend tiefes Verständnis dafür, wie Sie Ihre Daten in die Cloud verschieben und dabei den Leistungs-, Compliance- und Betriebsstandards Ihres Unternehmens entsprechen.
Fazit
Sobald Sie sich über Ihre übergeordnete Cloud-Strategie im Klaren sind, erfordert die Entwicklung einer erfolgreichen Cloud- Migrationsstrategie eine sorgfältige Planung und Berücksichtigung aller Aspekte Ihres Unternehmens. Der nächste Schritt besteht darin, die richtige Cloud-Anbieter-Strategie für Sie auszuwählen – sei es eine einfache Migration auf einen einzelnen Anbieter, ein Multi-Cloud-Anbieter-Ansatz oder eine Hybridstrategie. Schließlich sollten Sie Ihre Cloud-Migration entwerfen, indem Sie zunächst die wichtigsten Infrastrukturkomponenten berücksichtigen, bevor Sie mit der Integration der Anwendung beginnen.
Ich hoffe, dieser Blogbeitrag war interessant und wertvoll.
Bitte halten Sie Ausschau nach kommenden Blogbeiträgen zu Containern/Kubernetes und serverlosen Diensten.
Wenn Sie Ihre Reise in die Cloud beginnen, möchten Sie vielleicht mein neues Whitepaper über „Fünf Best Practices für eine sichere Cloud Migration“ lesen.
Hier können Sie mehr über die Cloud-Sicherheitslösungen von Check Point lesen oder hier eine Demo mit einem der Cloud-Sicherheitsingenieure von Check Point vereinbaren.
Um zu verstehen, wie Sie sichere Cloud-Architekturen entwerfen und implementieren, lesen Sie dieses Whitepaper.
Feedback