Apps in die Cloud migrieren? Lesen Sie zuerst das hier.
Einführung
Cloud-Computing-Umgebungen prägen heute die IT-Landschaft. Immer mehr Unternehmen verlagern ihre bestehenden On-Premises-Anwendungen in die Cloud. Die Migration einer Anwendung in die Cloud umfasst jedoch mehr, als sie lediglich auf eine virtuelle Maschine bei einem Cloud-Anbieter zu verschieben. Unternehmen verfolgen mit der Cloud-Migration unterschiedliche Ziele. Dennoch gibt es zentrale Faktoren, die jedes Unternehmen berücksichtigen sollte, sowie bewährte Vorgehensweisen, die zu einer erfolgreichen Cloud-Migration beitragen. Um die Vorteile der Cloud-Migration optimal auszuschöpfen, ist eine vorausschauende Planung erforderlich – sowohl bei der Anwendungsarchitektur als auch beim Übergang von der lokalen Infrastruktur in die Cloud.
Überblick
Cloud vs. On-Premises: die wichtigsten Unterschiede
Eine Cloud-Umgebung verhält sich anders als eine lokale Umgebung. Einige Unterschiede zwischen den beiden Umgebungen liegen auf der Hand, etwa dass die Rechenressourcen einem anderen Unternehmen gehören und von diesem verwaltet werden, anstatt sich im eigenen Besitz zu befinden und intern verwaltet zu werden. Einige der wichtigsten Unterschiede sind jedoch nicht technologisch bedingt. Grundsätzlich ist jede Technologie, die bei einem Cloud-Anbieter verfügbar ist, auch lokal verfügbar. Die Cloud bietet ein alternatives Nutzungsmodell, keine alternative Technologie. Anders ausgedrückt: Die Vorteile eines Wechsels zu einem Cloud-Anbieter liegen in der Art und Weise, wie die Rechenressourcen genutzt werden, nicht in den Rechenressourcen selbst.
Cloud-Anbieter können zwangsläufig nicht alle Funktionen lokaler Umgebungen nachbilden, etwa Richtlinien zur Einhaltung von Datenprüfungsanforderungen, die für lokale Hardware konzipiert wurden. Da Cloud-Komponenten geografisch verteilt sind, ist die Latenz bei Cloud-Bereitstellungen in der Regel höher. Cloud-Anbieter unterliegen zudem weiteren Einschränkungen. Da sie kundenübergreifende Standards einhalten, sind der Anpassung von Computing-Umgebungen klare Grenzen gesetzt. Beispielsweise stellen nur wenige Cloud-Anbieter seltene und exotische Computing-Hardware bereit.
Wenn ein Unternehmen jedoch innerhalb dieser Grenzen arbeiten kann, bietet ein Cloud-Anbieter Nutzungsmöglichkeiten, die für die meisten Unternehmen unerreichbar sind. Ein Cloud-Anbieter kann weltweit Rechenzentren betreiben und Unternehmen die Wahl lassen, in welchem Rechenzentrum sie ihre Rechenressourcen bereitstellen möchten. Zudem kann ein Cloud-Anbieter Fixkosten übernehmen, sodass ein Unternehmen nur für die tatsächlich genutzten Ressourcen bezahlt. Da ein Cloud-Anbieter Skaleneffekte erzielt, mit denen die meisten Unternehmen nicht mithalten können, kann er umfangreich in Systeme zur Verwaltung und Automatisierung von Bereitstellungen investieren. Dabei ist zu beachten, dass keiner dieser Vorteile technischer Natur ist. Die Vorteile eines Cloud-Anbieters liegen vielmehr in den Wahlmöglichkeiten und der Kostenstruktur, die den Kunden zur Verfügung stehen.
Um die Einschränkungen eines Cloud-Anbieters abzumildern und seine Vorteile zu nutzen, muss eine IT-Abteilung die Art und Weise ändern, wie sie Anwendungen bereitstellt. Dazu müssen Arbeitsabläufe so angepasst werden, dass die jeweiligen Stärken eines Cloud-Anbieters bestmöglich genutzt und zugleich Abhängigkeiten von Eigenschaften vermieden werden, bei denen eine Cloud-Umgebung im Nachteil ist, etwa bei der Latenz.
Gründe für die Cloud-Migration
Kosteneinsparungen werden häufig als Hauptgrund für den Wechsel in die Cloud genannt, doch die tatsächlichen Beweggründe sind meist vielschichtiger. Die meisten lassen sich in drei Kategorien einteilen: Planungssicherheit, Produktivität und Agilität.
Public-Cloud-Anbieter erhöhen die Planungssicherheit, indem sie Technologien so bündeln, dass sie leichter nutzbar sind, und dabei einen Teil des IT-Betriebsrisikos übernehmen. Da die Anbieter die Infrastruktur warten und die Verantwortung dafür tragen, muss sich ein Unternehmen nicht um diese Aspekte kümmern. Ebenso stellen Cloud-Anbieter in der Regel Tools bereit, die Einblicke in den IT-Betrieb ermöglichen und so die Transparenz erhöhen. Da sich die Kosten für die Public Cloud im Allgemeinen nach der Nutzung richten, kann ein Unternehmen den Nutzen einer Anwendung (beispielsweise den Umsatz) enger mit deren Betriebskosten verknüpfen. Mit zunehmender Nutzung der Anwendung steigen zwar die Kosten, aber auch der Nutzen. Durch die Verlagerung von Investitions- zu Betriebsausgaben müssen bei Kaufentscheidungen weniger Kapazitätsreserven für künftiges Wachstum eingeplant werden. Die Steuerung dieser Unsicherheiten auf Ebene des Cloud-Anbieters bringt messbare Vorteile.
Ein weiterer Grund für die Einführung der Public Cloud ist die höhere Produktivität. Die von den Anbietern bereitgestellten Tools für Zusammenarbeit und Automatisierung gehören zu den fortschrittlichsten auf dem Markt. Da die IT-Mitarbeiter zudem nicht mehr die Infrastruktur verwalten müssen, können sie sich auf geschäftsstrategische Aufgaben konzentrieren. Gleichzeitig steigern optimierte Abläufe, die sich von überall aus verwalten lassen, ihre Produktivität.
Der letzte Grund für die Einführung einer Public Cloud ist vielleicht der überzeugendste: Agilität. Da der Cloud-Anbieter den Eindruck vermittelt, dass jederzeit unbegrenzte Ressourcen zur Verfügung stehen, sind Geschwindigkeit und Ausrichtung geschäftlicher Vorhaben nicht mehr an die Einschränkungen der IT-Bereitstellung gebunden. Ressourcen können innerhalb von Sekunden oder Minuten bereitgestellt werden. Ein Projekt kann für kurze Zeit eine komplexe Computing-Umgebung nutzen, ohne dass man sich Gedanken über die Außerbetriebnahme der Hardware nach Projektende machen muss. Anwendungen können schnell bereitgestellt, skaliert und entfernt werden, ohne dass dabei Hardware-Ressourcen berücksichtigt werden müssen.
Hindernisse bei der Cloud-Migration
Eine Cloud-Migration bietet zwar viele Vorteile, ist jedoch auch mit einigen Herausforderungen verbunden. Die Hindernisse und Risiken unterscheiden sich je nachdem, an welcher Stelle des Migrationsprozesses sie auftreten: vor, während oder nach der Migration. Werden diese Hindernisse und Risiken frühzeitig berücksichtigt, erhöht sich die Wahrscheinlichkeit einer erfolgreichen Migration.
Die Planung vor der Migration ist möglicherweise der wichtigste Teil des Migrationsprozesses. Migrationsvorhaben können scheitern, wenn die Anwendungsarchitektur nicht so umgestaltet wird, dass sie die Möglichkeiten der Cloud nutzt. Dies ist auch ein guter Zeitpunkt, um die Komplexität der Anwendung zu erfassen und mit deren Verwaltung zu beginnen. Auch IT-Schulungen sollten zu Beginn des Vorhabens stattfinden. Cloud-Bereitstellungen neigen zu einer isolierten Umsetzung und einer zunehmenden Anzahl von Tools. Eine frühzeitige Planung kann daher zu einem reibungsloseren Migrationsprozess beitragen.
Die Migration von Anwendungen in die Cloud dauert in der Regel länger und ist komplexer als ursprünglich geplant. Um mögliche Probleme zu minimieren, sollten Sie mit einer kleinen, relativ unabhängigen Anwendung beginnen, damit auftretende Probleme möglichst geringe Auswirkungen haben. Die bei der ersten Migration einer kleinen Anwendung gewonnenen Erkenntnisse können bei zukünftigen Migrationen genutzt werden.
Langfristige Probleme bei Migrationen werden oft erst nach Abschluss der Migration sichtbar. Es können Sicherheits- und Compliance-Bedenken auftreten, häufig weil sich der Sicherheitsperimeter in einer Cloud-Umgebung schwieriger definieren lässt. Die Unterstützung von Altsystemen kann schwieriger sein, wenn sich alte und neue Systeme nicht nur in unterschiedlichen Umgebungen befinden, sondern auch unter unterschiedlichen kulturellen Voraussetzungen entwickelt wurden. Einige Unternehmen haben Bedenken hinsichtlich einer Abhängigkeit von einem bestimmten Cloud-Anbieter, insbesondere angesichts der zunehmenden Verbreitung von Containern. Schließlich können auch Budgetfragen problematisch sein, da sich variable Cloud-Kosten für die einzelnen Quartale nur schwer prognostizieren lassen.
So wählen Sie aus, welche Anwendungen migriert werden sollen
Eine Methode zur Bewertung von Anwendungen ist die Reifegrad-Standort-Matrix. Prüfen Sie Ihre Anwendungen, um den erforderlichen Reifegrad zu bestimmen. Anwendungen, die einen Wettbewerbsvorteil bieten oder Nischenanforderungen erfüllen, sind möglicherweise am besten in einer lokalen Umgebung aufgehoben. Am anderen Ende des Spektrums eignen sich kostengünstige oder auf Kostenführerschaft ausgerichtete Anwendungen – insbesondere im Hinblick auf Änderungskosten – häufig gut für eine Cloud-Umgebung. Ein weiterer zu berücksichtigender Faktor ist die Skalierbarkeit. Angenommen, eine neue Anwendung wurde bereitgestellt und muss möglicherweise irgendwann auf das Hundertfache der aktuellen Last skaliert werden. Um bei einer lokalen Bereitstellung mit dem Wachstum Schritt zu halten, müsste die Infrastruktur mit erheblichen Überkapazitäten ausgestattet werden. Dies würde zusätzliche Investitionskosten für ungenutzte Ressourcen verursachen. Würde dieselbe Anwendung hingegen in einer Cloud-Umgebung bereitgestellt, würden die Kosten entsprechend dem Wachstum steigen, und eine Überdimensionierung wäre nicht erforderlich.
Auch Netzwerkaspekte können bei der Entscheidung, welche Anwendungen in eine Cloud-Umgebung migriert werden sollen, eine Rolle spielen. Wenn eine Anwendung einen hohen Anteil verteilter Benutzer aufweist, etwa ein weitläufiges Händlernetz oder eine beträchtliche Anzahl von E-Mail-Benutzern an entfernten Standorten, wird bei einer lokalen Bereitstellung der gesamte Datenverkehr zum Rechenzentrum geleitet. Da der Datenverkehr ohnehin bereits über das Internet läuft, sind diese Anwendungen nicht latenzempfindlich. Werden solche Anwendungen in einer Cloud-Umgebung bereitgestellt, ändert sich die Netzwerklatenz nicht. Gleichzeitig wird jedoch Bandbreite in den lokalen Rechenzentren freigegeben, die andernfalls von den verteilten Benutzern beansprucht würde.
Gleichzeitig gibt es Gründe dafür, einige Anwendungen weiterhin lokal zu betreiben. Bei Anwendungen mit einer kürzeren voraussichtlichen Lebensdauer lohnen sich die Risiken und Kosten einer Migration möglicherweise nicht. Einige Anwendungen sind auf geringe Netzwerklatenzen und hohe Speichergeschwindigkeiten angewiesen und könnten in einer Cloud-Umgebung deutlich schlechter funktionieren. Auch Compliance- und Sicherheitsbedenken sprechen häufig dafür, Anwendungen lokal zu belassen. Manche Prüfverfahren setzen zur Verifizierung der Daten einen physischen Zugriff auf die Systeme und Daten voraus, während andere erfordern, dass die Anwendung und das Betriebssystem direkt auf physischer Hardware ausgeführt werden (d. h. nicht auf einer virtuellen Maschine). Im Laufe der Zeit werden Compliance-Verfahren an Cloud-Umgebungen angepasst werden, doch in vielen Fällen ist dies bislang noch nicht geschehen. Statt das Risiko einzugehen, dass Anwendungen in der Cloud Compliance-Prüfungen nicht bestehen, kann es vorerst sinnvoller sein, diese sensiblen Anwendungen lokal zu betreiben. Einige Anwendungen müssen Altsysteme und bestehende Prozesse unterstützen und können daher nicht ohne Weiteres für den Betrieb in einer Cloud neu konzipiert werden. Auch diese Anwendungen könnten lokal verbleiben. Aus diesen Gründen sollte die Migration mancher Anwendungen eine geringere Priorität haben als die von Anwendungen, die sich besser für eine Cloud-Umgebung eignen.
Anwendungen, die besser lokal betrieben werden sollten
- Apps mit kurzer Lebenserwartung
- Apps, die eine geringe Latenz erfordern
- Apps, bei denen Compliance-Bedenken bestehen
- Apps zur Unterstützung von Altsystemen
Überlegungen zur Umstellung
Viele Organisationen müssen während des Migrationsprozesses Herausforderungen bewältigen. Eine wichtige Frage, die beantwortet werden muss, lautet: Wie soll die eigentliche Umstellung erfolgen? Ein möglicher Ansatz besteht darin, die DNS-Auflösung so lange auf die lokale Anwendung zu verweisen, bis die Cloud-Anwendung gründlich getestet wurde, und anschließend die DNS-Einträge so zu ändern, dass sie auf die Cloud-Anwendung verweisen. DNS enthält einen TTL-Wert (Time to Live), der es Clients ermöglicht, die DNS-Antwort für einen bestimmten Zeitraum zwischenzuspeichern. Vor der Umstellung kann es sinnvoll sein, eine niedrige TTL von vielleicht nur wenigen Sekunden festzulegen, damit Clients nach der Umstellung schnell die neuen Anwendungen auflösen. Dieser Ansatz birgt jedoch einige Risiken. Eine niedrigere TTL kann den DNS-Datenverkehr und die Belastung der Server erheblich erhöhen. Eine Organisation könnte die TTL ignorieren und Daten länger als angegeben zwischenspeichern, sodass die DNS-Auflösung für einige Benutzer noch lange nach der Umstellung auf die lokale Anwendung verweist. Erwägen Sie, die Robustheit Ihrer DNS-Infrastruktur zu testen, bevor Sie diesen Ansatz verwenden.
Beim Übergang können auch Probleme mit der neuen Anwendung zutage treten, die bei den Tests nicht erkannt wurden. Um sich gegen Probleme mit der Anwendung abzusichern, kann ein Rückfallplan vorgesehen werden, der es ermöglicht, die Verarbeitung bei auftretenden Schwierigkeiten wieder auf die lokale Anwendung zurückzuverlagern. Leider erschwert ein bidirektionaler Übergang die Datensynchronisierung und erfordert daher erheblich mehr Planung und Tests im Vorfeld. Ein ausgefeilterer Ansatz besteht in einem teilweisen Übergang, dem sogenannten Canary Testing. Dabei wird ein Teil der Benutzer auf die Cloud-Anwendung umgestellt, während diese überwacht wird. Mit zunehmendem Vertrauen in die Anwendung können nach und nach weitere und schließlich alle Benutzer umgestellt werden. Tritt hingegen ein Problem auf, können die bereits umgestellten Benutzer wieder zur lokalen Anwendung zurückkehren. Canary Testing kann mithilfe eines programmierbaren Application Delivery Controllers (ADC) über F5® iRules® durchgeführt werden. Dadurch werden Risiken minimiert und zugleich die Handlungsmöglichkeiten des Betriebsteams während der Übergangsphase erweitert.
Empfehlungen
Apps für die Cloud anders entwickeln
Einer der größten Fehler, den Unternehmen bei der Migration von Anwendungen machen, besteht darin, diese nicht für die Cloud neu zu konzipieren. Wenn genügend Zeit eingeplant wird, um die Struktur der Anwendung so anzupassen, dass sie die Besonderheiten einer Cloud-Umgebung optimal nutzt, kann dies erhebliche Vorteile bringen.
Beispielsweise ist die Skalierung in einer Cloud-Umgebung im Vergleich zur Skalierung in einer lokalen Infrastruktur ein Kinderspiel. Statt die Anwendung für die höchstmögliche Last auszulegen und entsprechend zu testen, sollte sie schlank, aber skalierbar konzipiert werden. Es ist nicht nötig, den Mehraufwand für eine umfangreiche Infrastruktur in Kauf zu nehmen, wenn die Auslastung der Anwendung stark schwankt. Beginnen Sie stattdessen mit einer kleinen Lösung und sorgen Sie dafür, dass sie bei Bedarf skaliert werden kann. Ebenso sind bestimmte Ausfälle, etwa Stromausfälle, in einer Cloud-Umgebung weniger wahrscheinlich, sodass diese bei der Architektur weniger berücksichtigt werden müssen.
Andererseits bringen Cloud-Umgebungen neue Einschränkungen mit sich, die bei lokalen Infrastrukturen normalerweise nicht auftreten. Cloud-Architekten weisen darauf hin, dass ein System so konzipiert sein sollte, dass der Ausfall einer beliebigen VM-Instanz jederzeit als Teil des regulären Betriebs eingeplant ist. Auch die Datenspeicherung unterscheidet sich in einer Cloud-Umgebung. Lokale Architekturen verwenden häufig lokalen Blockspeicher. Diese Option ist auch in Cloud-Umgebungen verfügbar, kann dort jedoch nicht gemeinsam genutzt werden. Die Kombination aus lokalem, nicht gemeinsam genutztem Zustand und dem Ausfall einer Instanz könnte verheerende Folgen haben. Es gibt weitere Speicherparadigmen, beispielsweise objektbasierte Speicher- oder Schlüssel-Wert-Speicherdienste. Den Einschränkungen einer Cloud-Umgebung lässt sich durch eine Neugestaltung der Anwendungsarchitektur begegnen.
Überlegen Sie, was lokal verbleiben soll
Bei einigen Anwendungen oder Steuerungssystemen ist es sinnvoll, sie lokal zu betreiben. Viele Unternehmen behalten Active Directory lokal bei und nutzen gleichzeitig die Föderation, um Identitäten auf eine Cloud-Umgebung auszuweiten. Ebenso stellt ein ADC zahlreiche Sicherheitsdienste zur Unterstützung der Anwendungsbereitstellung bereit, darunter Firewalls, Web Application Firewalls, DDoS-Schutz und SSL/TLS-Interception sowie Service Chaining. Darüber hinaus bietet ein ADC ein erweitertes Datenverkehrsmanagement und einen programmierbaren Proxy sowie Funktionen für das Identitäts- und Zugriffsmanagement.
Unternehmen haben diese Anwendungsdienste üblicherweise außerhalb der Anwendung gebündelt, da die Dienste nicht Teil der Geschäftslogik sind, sondern betriebliche Belange betreffen. Um betriebliche Änderungen unabhängig von den Veröffentlichungszyklen der Anwendungen zu ermöglichen, bündeln viele Unternehmen Fachwissen, das mithilfe eines ADC als strategischem Kontrollpunkt auf alle Anwendungen angewendet werden kann. Cloud-Umgebungen verändern dieses Modell jedoch.
Ein früher Ansatz für die Anwendungsbereitstellung in Cloud-Umgebungen bestand darin, ADC-Dienste mithilfe nativer Tools in jeder Cloud-Umgebung nachzubilden. Schon bald zeigte sich, dass die Cloud-Anbieter nicht dasselbe Maß an nativen Funktionen boten. Unternehmen standen daher vor der Wahl, entweder unterschiedliche Standards für die Anwendungsbereitstellung in Cloud- und On-Premises-Umgebungen beizubehalten oder alle Anwendungen auf den kleinsten gemeinsamen Nenner auszurichten.
Als Unternehmen ihre Aktivitäten auf mehrere Cloud-Umgebungen ausweiteten, wurden beide Optionen zunehmend unattraktiv. Angenommen, ein Unternehmen nutzt drei Cloud-Anbieter und betreibt zusätzlich ein lokales Rechenzentrum. Es musste entweder vier Teams mit SSL/TLS-Fachwissen, vier Teams mit DDoS-Fachwissen und so weiter vorhalten oder sich auf eine zunehmend uneinheitliche (und eingeschränkte) Auswahl grundlegender Dienste beschränken. Schon die Bereitstellung einer einzigen neuen Anwendung in einer zusätzlichen Cloud-Umgebung verursachte erhebliche Zusatzkosten – entweder für ein weiteres Team von Fachleuten oder für neue Standards, die auf alle bestehenden Anwendungen angewendet werden mussten.
Es gibt jedoch eine dritte Möglichkeit, konsistente Dienste in allen Umgebungen bereitzustellen. Mit F5 Application Connector kann ein einziges Team von Fachleuten sämtliche Anwendungen verwalten, unabhängig davon, wo diese ausgeführt werden. Durch den Einsatz vorhandener BIG-IP® Hardware- oder Software-Appliances kann ein Unternehmen jeder Anwendung unabhängig von ihrem Standort umfassende, fortschrittliche Anwendungsdienste vorschalten. Dadurch erhalten alle Anwendungen einen strategischen Kontrollpunkt, der von einem einzigen Team von Fachleuten verwaltet wird. Darüber hinaus erhöht Application Connector die Sicherheit, indem alle sichtbaren öffentlichen IP-Adressen beseitigt und so die Angriffsflächen reduziert werden. Da Verschlüsselungsschlüssel zentral und nicht in den Cloud-Instanzen gespeichert werden, können Unternehmen darauf vertrauen, dass ihre kritischen kryptografischen Informationen vertraulich bleiben. Schließlich steigert Application Connector die Effizienz Ihrer Cloud-Bereitstellung, da neue Workload-Knoten automatisch von der Proxy-Instanz erkannt werden können.
Speicher sorgfältig abwägen
Einer der größten Unterschiede zwischen On-Premises- und Cloud-Anwendungen besteht in der Speicherung des Anwendungszustands. On-Premises-Architekturen verwenden überwiegend lokalen Blockspeicher, beispielsweise eine Festplatte oder ein Solid-State-Laufwerk. Eine Cloud-Anwendung kann ebenfalls Blockspeicher nutzen, dieser ist jedoch lokal an die jeweilige Instanz gebunden, und bei der Architektur sollte mit dem Ausfall von Instanzen gerechnet werden. Wenn Unternehmen beim Umzug einer Anwendung in die Cloud sonst nichts an deren Architektur ändern, sollten sie zumindest den Umgang mit dem Anwendungszustand anpassen.
Ein gängiger Cloud-Speichertyp ist Objektspeicher, bei dem jedes Objekt im Wesentlichen eine Datei ist, auf die jedoch über einen Namen zugegriffen wird. Im Allgemeinen weist der Speicher höchstens eine Hierarchieebene auf (d. h. einen Ordner oder ein Verzeichnis), sodass die Abbildung eines herkömmlichen Dateisystems auf Objekte problematisch sein kann. Da Objekte nicht bearbeitet, sondern nur erstellt, gelesen und gelöscht werden können, eignet sich Objektspeicher gut für statische Inhalte wie Bilder, nicht jedoch für Zustandsdaten. Viele Anwendungen setzen voraus, dass Dateien geändert werden können, weshalb diese Anwendungen nicht mit Objekten funktionieren.
Weitere Speicheroptionen sind Schlüssel-Wert-Speicher und herkömmliche Transaktionsdatenbanken. Sie sind zwar keine Speicherlösungen im Sinne eines Dateisystems, speichern jedoch Daten und werden als zusätzlicher Dienst bereitgestellt. Bei einer geeigneten Architektur kann der Zustand in einem Schlüssel-Wert- oder Datenbankdienst gespeichert werden.
Fazit: Bereiten Sie sich vor der Migration vor
Cloud-Computing-Umgebungen bieten Vorteile, allerdings nur, wenn zentrale Anwendungen neu konzipiert werden, um die Funktionen der Cloud zu nutzen und gleichzeitig die Auswirkungen ihrer Einschränkungen zu minimieren. Cloud-Umgebungen weisen andere Ausfallszenarien und häufig eine höhere Netzwerklatenz auf, ermöglichen jedoch eine schnelle Skalierung und die Auswahl von Rechenzentren weltweit. Bei der Cloud-Migration muss unter anderem entschieden werden, welche Anwendungen migriert und welche weiterhin lokal betrieben werden sollen.
Auch der Übergangsprozess selbst sollte sorgfältig durchdacht und geplant werden. Dazu gehört auch ein Rückfallplan für den Fall, dass sich die Cloud-Anwendung nicht wie erwartet verhält. Im Rahmen der Planung behalten einige Unternehmen einen ADC vor Ort als strategischen Kontrollpunkt für alle Anwendungen bei – unabhängig davon, wo diese gehostet werden. Planen Sie außerdem sorgfältig, wie die Cloud-Anwendung Daten und Zustandsinformationen speichern soll. Unabhängig davon, wie Sie Ihre Anwendungen – und Ihr Unternehmen – in die Cloud verlagern möchten, sollten Sie einen erfahrenen Cloud-Partner hinzuziehen.
VERÖFFENTLICHT AM 16. AUGUST 2017