Apps in die Cloud migrieren? Lesen Sie dies zuerst.

Cloud-Computing-Umgebungen sind heute ein dominierendes Merkmal der IT-Landschaft, da Unternehmen ihre älteren lokalen Applications immer häufiger in die Cloud verlagern. Die Migration einer Application in die Cloud erfordert jedoch mehr, als die Application lediglich auf eine virtuelle Maschine bei einem Cloud-Anbieter zu verschieben. Die Beweggründe für die Migration in die Cloud sind unterschiedlich und können von verschiedenen Organisationen unterschiedlich ausfallen. Es gibt jedoch Schlüsselfaktoren, die jede Organisation berücksichtigen sollte, und sicherlich auch Best Practices für die Gewährleistung einer erfolgreichen Migration in die Cloud. Um den größtmöglichen Nutzen aus der Cloudmigration zu ziehen, planen Sie voraus – sowohl hinsichtlich der Application als auch des Übergangs von lokalen Umgebungen zur Cloud.

Eine Cloud-Umgebung verhält sich anders als eine lokale Umgebung. Einige der Unterschiede zwischen den beiden Umgebungen liegen auf der Hand, etwa die Tatsache, dass die Computerressourcen im Besitz eines anderen Unternehmens sind und von diesem verwaltet werden, anstatt intern im Besitz und unter der Verwaltung zu sein. Einige der wichtigsten Unterschiede sind jedoch nicht auf die Technologie zurückzuführen. Grundsätzlich ist jede Technologie, die bei einem Cloud-Anbieter verfügbar ist, auch vor Ort verfügbar. Was die Cloud bietet, ist ein alternatives Verbrauchsmodell, keine alternative Technologie. Anders ausgedrückt: Die Vorteile einer Migration zu einem Cloud-Anbieter liegen in der Art und Weise, wie die Rechenressourcen genutzt werden, und nicht in den Rechenressourcen selbst.

Cloud-Anbieter können nicht zwangsläufig alle lokalen Funktionen duplizieren, wie etwa Compliance-Richtlinien zur Datenprüfung, die für lokale Hardware entwickelt wurden. Da die Cloud-Komponenten geografisch verteilt sind, ist die Latenz bei Cloud-Bereitstellungen im Allgemeinen höher. Cloud-Anbieter sind auch mit weiteren Einschränkungen konfrontiert. Da die Anbieter für alle Kunden Standards einhalten, sind der individuellen Anpassung von Computerumgebungen tatsächlich Grenzen gesetzt. Beispielsweise stellen nur wenige Cloud-Anbieter seltene und exotische Computerausrüstung bereit.

Aber wenn ein Unternehmen innerhalb dieser Grenzen agieren kann, kann ein Cloud-Anbieter Nutzungsmöglichkeiten bereitstellen, die für die meisten Firmen unerreichbar sind. Ein Cloud-Anbieter kann Rechenzentren auf der ganzen Welt betreiben und Unternehmen die Wahl lassen, in welchem ​​Rechenzentrum sie ihre Rechenressourcen unterbringen möchten. Darüber hinaus kann ein Cloud-Anbieter Fixkosten übernehmen, so dass ein Unternehmen nur für die tatsächlich genutzten Ressourcen zahlt. Da ein Cloud-Anbieter über Skaleneffekte verfügt, die die meisten Unternehmen nicht erreichen, kann er massiv in Systeme zur Verwaltung und Automatisierung von Bereitstellungen investieren. Beachten Sie, dass keiner dieser Vorteile technischer Natur ist. Die Vorteile eines Cloud-Anbieter liegen vielmehr in den Auswahlmöglichkeiten und der Kostenstruktur, die dem Verbraucher zur Verfügung stehen.

Um diese Beschränkungen zu mildern und die Vorteile eines Cloud-Anbieter zu nutzen, muss eine IT-Abteilung die Art und Weise ändern, wie sie Applications bereitstellt. Sie muss Arbeitsabläufe anpassen, um die relativen Stärken eines Cloud-Anbieter optimal zu nutzen und gleichzeitig Abhängigkeiten von Eigenschaften zu vermeiden, bei denen eine Cloud-Umgebung im Nachteil ist, wie etwa Latenz.

Kosteneinsparungen werden häufig als Hauptgrund für die Migration in die Cloud genannt, die wahren Gründe sind jedoch meist differenzierter. Die meisten Motivationen fallen in drei Kategorien: Sicherheit, Produktivität und Agilität.

Öffentliche Cloud-Anbieter erhöhen die Sicherheit, indem sie die Technologie bündeln, um sie besser nutzbar zu machen, und absorbieren so einen Teil des IT-Betriebsrisikos. Da die Anbieter die Infrastruktur warten und die Verantwortung dafür übernehmen, kann ein Unternehmen diese Bedenken ignorieren. Ebenso stellen Cloud-Anbieter im Allgemeinen Tools zur Verfügung, die einen Einblick in den IT-Betrieb ermöglichen und so die Transparenz erhöhen. Da die Kosten einer öffentlichen Cloud im Allgemeinen eine Funktion des Verbrauchs sind, kann ein Unternehmen den Nutzen einer Application (z. B. den Umsatz) enger mit den Betriebskosten dieser Application verknüpfen. Mit zunehmender Nutzung der Application steigen zwar die Kosten, jedoch auch der Nutzen. Durch die Verlagerung der Ausgaben vom Kapital- in den Betriebsbereich besteht weniger Bedarf, bei Kaufentscheidungen Spielraum für zukünftiges Wachstum zu lassen. Die Bewältigung dieser Unsicherheiten auf der Ebene des Cloud-Anbieter bietet messbare Vorteile.

Ein weiterer Grund für die Einführung der öffentlichen Cloud ist die gesteigerte Produktivität. Die Kollaborations- und Automatisierungstools der Anbieter gehören zu den fortschrittlichsten auf dem Markt. Da die IT-Mitarbeiter nicht mehr auf die Verwaltung der Infrastruktur angewiesen sind, können sie sich auf geschäftsstrategische Aufgaben konzentrieren. Gleichzeitig steigern optimierte, von überall aus verwaltbare Abläufe die Produktivität der IT-Mitarbeiter.

Der letzte Grund für die Einführung einer öffentlichen Cloud ist vielleicht der überzeugendste: Agilität. Da der Cloud-Anbieter die Illusion jederzeit verfügbarer, unbegrenzter Ressourcen erzeugt, sind Geschwindigkeit und Ausrichtung der Geschäftsbemühungen nicht mehr an Beschränkungen bei der Bereitstellung der IT gebunden. Ressourcen können in Sekunden oder Minuten bereitgestellt werden. Ein Projekt kann für einen kurzen Zeitraum eine komplexe Computerumgebung nutzen, ohne dass man sich Gedanken über die Außerbetriebnahme der Hardware nach Projektende machen muss. Applications können schnell bereitgestellt, skaliert und entfernt werden, ohne dass man sich um die Hardwareressourcen kümmern muss.

Eine Migration in die Cloud bietet zwar viele Vorteile, doch mit der Migration sind auch mehrere Herausforderungen verbunden. Die Barrieren und Risiken variieren, je nachdem, wo im Migrationsprozess sie auftreten: vor der Migration, während der Migration und nach der Migration. Wenn diese Hindernisse und Risiken im Vorfeld angegangen werden, erhöht sich die Wahrscheinlichkeit einer erfolgreichen Migration.

Die Planung vor der Migration ist möglicherweise der kritischste Teil des Migrationsprozesses. Migrationsbemühungen können fehlschlagen, weil die Application nicht so umgestaltet wird, dass sie die Vorteile der Cloud-Funktionen nutzt. Dies ist auch ein guter Zeitpunkt, um eine Bestandsaufnahme der Komplexität der Anwendung zu machen und mit der Bewältigung dieser zu beginnen. Auch eine IT-Schulung sollte zu Beginn der Maßnahme erfolgen. Bei Cloud-Bereitstellungen kommt es häufig zu isolierter Ausführung und einer großen Anzahl von Tools. Eine Planung in den frühen Phasen kann den Migrationsprozess vereinfachen.

Die Migration von Applications in die Cloud dauert in der Regel länger und ist komplexer als ursprünglich geplant. Um Probleme zu minimieren, beginnen Sie mit einer kleinen und relativ unabhängigen Application , damit auftretende Probleme minimale Auswirkungen haben. Die aus der ersten Migration einer kleinen Application gewonnenen Erkenntnisse können auf zukünftige Migrationen angewendet werden.

Langfristige Probleme mit Migrationen werden erst nach Abschluss der Migration sichtbar. Es können Sicherheitsbedenken und Bedenken hinsichtlich der Einhaltung von Vorschriften auftreten, häufig weil der Sicherheitsbereich in einer Cloud-Umgebung schwieriger zu definieren ist. Die Unterstützung von Altsystemen kann schwieriger sein, wenn sich alte und neue Systeme nicht nur in unterschiedlichen Umgebungen befinden, sondern auch in unterschiedlichen Kulturen entwickelt wurden. Einige Organisationen haben Bedenken hinsichtlich der Bindung an die Cloud, insbesondere angesichts der zunehmenden Verbreitung von Containern. Schließlich können auch Budgetbedenken ein Problem darstellen, da sich die variablen Cloud-Kosten für jedes Quartal nur schwer prognostizieren lassen.

Eine Methode zur Bewertung von Applications ist die Reifegrad-Standort-Matrix. Prüfen Sie Ihre Applications , um festzustellen, wie viel Reife Sie benötigen. Applications , die eine Wettbewerbsdifferenzierung ermöglichen oder Nischenanwendungen sind, werden möglicherweise am besten vor Ort bereitgestellt. Am anderen Ende des Spektrums passen kostengünstige oder kostenführende Applications (insbesondere im Hinblick auf die Änderungskosten) oft gut in eine Cloud-Umgebung. Zu den weiteren zu berücksichtigenden Faktoren gehört die Skalierbarkeit. Nehmen wir an, dass eine neue Application bereitgestellt wurde und diese möglicherweise irgendwann auf das Hundertfache der aktuellen Last skaliert werden kann. Um mit dem Wachstum bei der Bereitstellung vor Ort Schritt zu halten, müsste die Infrastruktur deutlich überdimensioniert werden, was zusätzliche Kapitalkosten für ungenutzte Ressourcen mit sich bringt. Würde dieselbe Application jedoch in einer Cloud-Umgebung eingesetzt, würden die Kosten mit dem Wachstum steigen und es wäre keine Überbereitstellung erforderlich.

Auch Netzwerkprobleme können bei der Entscheidung eine Rolle spielen, welche Applications in eine Cloud-Umgebung migriert werden sollen. Wenn eine Application über einen großen Anteil verteilter Benutzer verfügt, wie etwa ein ausgedehntes Händlernetzwerk oder eine beträchtliche Anzahl Remote-E-Mail-Benutzer, wird bei einer Bereitstellung vor Ort der gesamte Datenverkehr an das Rechenzentrum weitergeleitet. Da der Datenverkehr bereits über das Internet läuft, reagieren die Applications nicht empfindlich auf Latenzzeiten. Wenn derartige Applications in einer Cloud-Umgebung platziert werden, ändert sich die Netzwerklatenz nicht, es wird jedoch Bandbreite in den Rechenzentren vor Ort freigegeben, die sonst von den verteilten Benutzern verbraucht würde.

Gleichzeitig gibt es Gründe, einige Apps vor Ort zu belassen. Bei Applications mit kürzerer Lebenserwartung sind die Risiken und Kosten einer Migration möglicherweise nicht gerechtfertigt. Manche Apps sind auf geringe Netzwerklatenz und Speichergeschwindigkeiten angewiesen und ihre Leistung könnte in einer Cloud-Umgebung deutlich schlechter sein. Compliance- und Sicherheitsbedenken sind häufig Gründe dafür, Apps vor Ort zu belassen. Einige Prüfverfahren setzen einen physischen Zugriff auf die Systeme und Daten voraus, um die Daten zu überprüfen, während andere erfordern, dass die Application und das Betriebssystem auf Bare Metal ausgeführt werden (d. h. sie können nicht auf einer virtuelle Maschine ausgeführt werden). Mit der Zeit werden die Compliance-Verfahren an die Cloud-Umgebung angepasst, in vielen Fällen ist das jedoch noch nicht geschehen. Anstatt bei Applications in der Cloud das Risiko einzugehen, Compliance-Audits nicht zu bestehen, ist es möglicherweise sinnvoller, diese sensiblen Apps vorerst vor Ort zu belassen. Manche Apps müssen Altsysteme und -prozesse unterstützen und können daher nicht für den Betrieb in einer Cloud umgestaltet werden. Diese Apps könnten auch Kandidaten dafür sein, vor Ort zu belassen. Aus diesen Gründen sollte einigen Apps eine niedrigere Migrationspriorität eingeräumt werden als Apps, die besser für eine Cloud-Umgebung geeignet sind.

Applications sollten besser vor Ort bleiben

• Apps mit kurzer Lebenserwartung
• Apps, die eine geringe Latenz erfordern
• Apps, bei denen Compliance-Bedenken bestehen
• Apps, die Legacy-Systeme unterstützen

Viele Organisationen müssen während des Migrationsprozesses Herausforderungen bewältigen. Eine wichtige Frage, die beantwortet werden muss, ist, wie die tatsächliche Umstellung durchgeführt werden soll. Ein Ansatz besteht darin, DNS für die Auflösung zur lokalen Application zu verwenden, bis die Cloud- Application gründlich getestet wurde, und dann die DNS-Einträge so zu ändern, dass eine Auflösung zur Cloud- Application erfolgt. DNS enthält einen Time-to-Live-Wert (TTL), der es Clients ermöglicht, die DNS-Antwort für einen bestimmten Zeitraum zwischenzuspeichern. Vor der Umstellung kann es sinnvoll sein, einen niedrigen TTL-Wert von beispielsweise nur wenigen Sekunden festzulegen, damit die Clients nach der Umstellung schnell auf die neuen Applications umsteigen können. Dieser Ansatz birgt jedoch einige Risiken. Durch die Verringerung des TTL-Werts kann es zu einer deutlichen Erhöhung des DNS-Verkehrs und der Serverbelastung kommen. Eine Organisation könnte TTL und Cache für längere Zeiträume als angegeben ignorieren, was dazu führen könnte, dass einige Benutzer noch lange nach der Umstellung auf die lokale Application zurückgreifen. Erwägen Sie, die Robustheit Ihrer DNS-Infrastruktur zu testen, bevor Sie diesen Ansatz verwenden.

Der Übergangsprozess kann auch Probleme mit der neuen Application zutage fördern, die beim Testen nicht erkannt wurden. Eine Möglichkeit zum Schutz vor einer problematischen Application ist ein Fallback-Plan, der im Problemfall eine Rückkehr zur lokalen Application ermöglicht. Leider erschwert ein bidirektionaler Übergang die Datensynchronisierung und erfordert daher im Vorfeld weitaus mehr Planung und Tests. Bei einem ausgefeilteren Ansatz wird eine teilweise Umstellung mit dem Namen „Canary Testing“ durchgeführt, bei der ein Teil der Benutzer unter Überwachung auf die Cloud- Application umgestellt wird. Mit zunehmendem Vertrauen in die Application können weitere und schließlich alle Benutzer umgestellt werden. Umgekehrt können die umgestellten Benutzer bei Auftreten eines Problems wieder zur lokalen Application zurückkehren. Canary-Tests können von einem programmierbaren Application Delivery Controller (ADC) über F5® iRules® durchgeführt werden, wodurch Risiken minimiert und gleichzeitig die Anzahl der Optionen erhöht wird, die dem Betriebsteam während der Übergangsphase zur Verfügung stehen.

Einer der größten Fehler, den Unternehmen bei der Migration von Applications machen, besteht darin, dass sie diese nicht für die Cloud neu strukturieren. Es kann erhebliche Vorteile bringen, wenn Sie sich die Zeit nehmen, die Struktur der Application so zu ändern, dass sie die Unterschiede einer Cloud-Umgebung nutzt.

Beispielsweise ist die Skalierung in einer Cloud-Umgebung im Vergleich zur Skalierung vor Ort trivial. Anstatt die Application für den schlimmsten Belastungsfall zu entwerfen und zu testen, entwerfen Sie die Application lieber schlank, aber skalierbar. Wenn die Anwendungsnutzung ein breites Spektrum abdeckt, besteht keine Notwendigkeit, einen großen Platzbedarf an Gemeinkosten beizubehalten. Bauen Sie stattdessen klein und seien Sie bereit für die Skalierung. Ebenso sind bestimmte Fehler, wie z. B. Stromausfälle, in einer Cloud-Umgebung weniger wahrscheinlich, so dass für diese weniger Architektur erforderlich ist.

Andererseits führen Cloud-Umgebungen neue Einschränkungen ein, die vor Ort normalerweise nicht auftreten. Cloud-Architekten weisen darauf hin, dass bei einem Entwurf der jederzeitige Ausfall einer VM-Instanz als Teil der regulären Verarbeitung berücksichtigt werden sollte. Auch die Speicherung ist in einer Cloud-Umgebung anders. On-Premise-Designs verwenden regelmäßig lokalen Blockspeicher. Dieselbe Option ist in Cloud-Umgebungen verfügbar, kann jedoch nicht geteilt werden. Die Kombination aus einem lokalen, nicht freigegebenen Status und einem Instanzfehler könnte ein Rezept für eine Katastrophe sein. Es gibt andere Speicherparadigmen, beispielsweise objektbasierte Speicherung oder Schlüssel-Wert-Speicherdienste. Die Einschränkungen einer Cloud-Umgebung können durch eine Neustrukturierung der Application vermieden werden.

Bei manchen Applications oder Steuerungssystemen ist es sinnvoll, sie vor Ort zu behalten. Viele Organisationen behalten Active Directory vor Ort bei, nutzen jedoch die Föderation, um die Identität auf eine Cloudumgebung auszuweiten. Ebenso bietet ein ADC viele Sicherheitsdienste zur Unterstützung der Application , wie Firewalls, Web Application Firewalls, DDoS-Schutz und SSL/TLS-Intercept zusammen mit Service Chaining. Ein ADC bietet darüber hinaus erweitertes Verkehrsmanagement und einen programmierbaren Proxy sowie Identitäts- und Zugriffsverwaltung.

Organisationen haben diese Application normalerweise extern zur Application konsolidiert, da die Dienste nicht Teil der Geschäftslogik, sondern betrieblicher Belange sind. Um betriebliche Änderungen unabhängig von den Veröffentlichungszeitplänen der Application zu ermöglichen, konzentrieren viele Unternehmen ihr Fachwissen, das auf alle Applications angewendet werden kann, indem sie einen ADC als strategischen Kontrollpunkt verwenden. Cloud-Umgebungen ändern dieses Modell jedoch.

Ein früher Ansatz zur Application in Cloud-Umgebungen bestand darin, ADC-Dienste mithilfe nativer Tools in jeder Cloud-Umgebung zu replizieren. Schon bald wurde klar, dass die Cloud-Anbieter nicht das gleiche Maß an nativen Funktionen anboten. Die Unternehmen standen daher vor einer Wahl: Entweder sie hielten heterogene Standards für die Application zwischen den Cloud- und den lokalen Umgebungen aufrecht oder sie überarbeiteten alle Applications auf den kleinsten gemeinsamen Nenner.

Als Unternehmen ihre Aktivitäten auf mehrere Cloud-Umgebungen ausweiteten, wurden beide Optionen weniger attraktiv. Angenommen, eine Organisation nutzt die Dienste von drei Cloud-Anbietern und unterhält außerdem ein Rechenzentrum vor Ort. Die Organisation musste entweder vier Sätze SSL/TLS-Expertise, vier Sätze DDoS-Expertise usw. vorhalten oder sich auf einen zunehmend unzusammenhängenden (und begrenzten) Satz grundlegender Dienste standardisieren. Die Bereitstellung nur einer neuen Application in einer zusätzlichen Cloud-Umgebung war mit erheblichen Grenzkosten verbunden, entweder für einen weiteren Satz Fachexperten oder für einen neuen Satz von Standards, die auf alle vorhandenen Applications anzuwenden sind.

Für die Bereitstellung konsistenter Dienste in allen Umgebungen gibt es jedoch eine dritte Möglichkeit. F5 Application Connector ermöglicht einer Gruppe von Domänenexperten die Verwaltung aller Applications, unabhängig davon, wo sich diese Applications befinden. Durch die Verwendung vorhandener BIG-IP®-Hardware- oder Software-Geräte kann ein Unternehmen vollständige erweiterte Application vor jede Application stellen, egal wo sie sich befindet. Dadurch erhalten alle Applications einen strategischen Kontrollpunkt, der von einem einzigen Satz Domänenexperten verwaltet wird. Darüber hinaus erhöht Application Connector die Sicherheit, indem es alle sichtbaren öffentlichen IP-Adressierungen eliminiert und so die Angriffsfläche verringert. Durch die zentrale Speicherung der Verschlüsselungsschlüssel und nicht in Cloud-Instanzen können Unternehmen sicher sein, dass ihre kritischen kryptografischen Informationen vertraulich bleiben. Schließlich erhöht Application Connector die Effizienz Ihrer Cloud-Bereitstellung, indem er die automatische Erkennung neuer Workload-Knoten durch die Proxy-Instanz ermöglicht.

Einer der größten Unterschiede zwischen lokalen Applications und Cloud- Applications ist die Speicherung des Application . In den meisten Fällen wird bei On-Premise-Designs lokaler Blockspeicher wie eine Festplatte oder ein Solid-State-Laufwerk verwendet. Eine Cloud Application kann ebenfalls Blockspeicher verwenden, der Speicher befindet sich jedoch lokal bei der Instanz und bei der Entwicklung sollte mit Fehlern bei Instanzen gerechnet werden. Wenn Unternehmen beim Verschieben einer App in die Cloud nichts anderes im Application umstellen, sollten sie die Statusbehandlung ändern.

Ein gängiger Cloud-Speichertyp ist der Objektspeicher, bei dem jedes Objekt im Wesentlichen eine Datei ist, die jedoch über einen Namen adressiert wird. Im Allgemeinen verfügt der Speicher über höchstens eine Hierarchieebene (d. h. Ordner oder Verzeichnis), sodass die Zuordnung eines herkömmlichen Dateisystems zu Objekten problematisch sein kann. Da Objekte nicht bearbeitet, sondern nur erstellt, gelesen und gelöscht werden können, eignet sich die Objektspeicherung gut für statische Inhalte wie Bilder, jedoch nicht für Statusinformationen. Viele Applications gehen davon aus, dass eine Datei geändert werden kann, daher funktionieren diese Applications nicht mit Objekten.

Zu den weiteren Speicheroptionen gehören Schlüssel-Wert-Speicher und herkömmliche Transaktionsdatenbanken. Dabei handelt es sich nicht um Speicher wie ein Dateisystem, sie speichern jedoch Daten und werden als zusätzlicher Dienst bereitgestellt. Mit einem effektiven Design kann der Status in einem Schlüssel-Wert- oder Datenbankdienst gespeichert werden.

Cloud-Computing-Umgebungen bieten Vorteile, allerdings nur, wenn die wichtigsten Applications neu konzipiert werden, um die Vorteile der Cloud-Funktionen zu nutzen und gleichzeitig die Auswirkungen der Cloud-Einschränkungen zu mildern. Cloud-Umgebungen weisen unterschiedliche Ausfallszenarien auf und weisen häufig eine erhöhte Netzwerklatenz auf, ermöglichen jedoch eine schnelle Skalierung und die Auswahl von Rechenzentren auf der ganzen Welt. Zu den Überlegungen bei der Migration in die Cloud gehört die Entscheidung, welche Applications migriert werden sollen und welche vor Ort verbleiben sollen.

Auch der Übergangsprozess selbst sollte sorgfältig durchdacht und geplant werden. Außerdem sollte ein Backout-Plan für den Fall erstellt werden, dass sich die Cloud- Application nicht wie erwartet verhält. Als Teil des Planungsprozesses unterhalten einige Organisationen einen ADC vor Ort als strategischen Kontrollpunkt für alle Applications , unabhängig davon, wo diese gehostet werden. Planen Sie abschließend sorgfältig, wie die Cloud- Application Daten und Status speichern wird. Wie auch immer Sie Ihre Applications– und Ihr Unternehmen – in die Cloud verlagern, ziehen Sie in Erwägung, einen erfahrenen Cloud-Partner mit einzubeziehen.