So quantifizieren und qualifizieren Sie die Vorteile der Cloud-Migration

Es ist eine ausgemachte Sache, dass die Zukunft des Unternehmensgeschäfts in der Cloud liegt. Dies gilt insbesondere, wenn man bedenkt, welche große Rolle die Cloud-Migration in den letzten Jahren im Unternehmensbereich gespielt hat:

Die Ausgaben für Cloud Computing sind seit 2009 um das 4,5-Fache der IT-Ausgaben gestiegen und werden bis 2020 voraussichtlich um mehr als das Sechsfache steigen.

Forbes Cloud Computing-Zusammenfassung

Dies wird durch die neuesten Daten von Oracle untermauert, dessen Prognose Nummer zwei für 2019 lautete, dass 80 Prozent aller Enterprise-Workloads – einschließlich der als „geschäftskritisch“ eingestuften – in den nächsten 12 Monaten in die Cloud verschoben werden.

Trotz der nahezu allgegenwärtigen Cloud im gesamten Unternehmen (und der zunehmenden Vertrautheit mit Cloud-Technologien für IT-Experten und Laien gleichermaßen) ist die Verlagerung von Workflows in die Cloud keine leichte Aufgabe. Dies gilt insbesondere, wenn es darum geht, Erwartungen zu erfüllen und tatsächlich Verbesserungen zu erzielen – sei es in Bezug auf Kosten oder Leistung –, wenn die Migration abgeschlossen ist.

Um sicherzustellen, dass Teams keine Versprechen machen, die sie nicht halten können, benötigen sie Transparenz in jeder Phase ihrer Cloud-Migration. Denn "Sie können nicht verwalten, was Sie nicht messen können, “ lautet das alte Mantra, und daher müssen IT-Teams in jeder Phase der Migration Transparenz haben, um genaue Erwartungen zu setzen und Problemen einen Schritt voraus zu sein, bevor sie das gesamte Unternehmen zum Scheitern bringen.

Annehmbare Leistungsziele definieren

Zunächst müssen Teams vollständig verstehen, welche Anwendungen, Netzwerkinfrastrukturen oder Prozesse am häufigsten ausfallen. Die IT wird wahrscheinlich funktionsübergreifende Interviews führen müssen, um Informationen und Zustimmung im gesamten Unternehmen zu erhalten.

Die Argumentation für die Cloud-Migration kann einfach sein, wenn die IT in Allgemeinheit denkt. Sicherlich wird es für preisbewusste Entscheidungsträger attraktiv erscheinen, die Wartung von Netzwerkhardware zu entlasten, aber wie viel Vorabinvestitionen sind erforderlich, bevor das Unternehmen diese Einsparungen erzielen kann?

Auch die Kosten allein reichen möglicherweise nicht aus, um alle Entscheidungsträger zu überzeugen. Wenn die Cloud-Migration die Leistung mehrerer Apps verbessert, die als geschäftskritisch gelten, wird dies zu Lasten der an anderer Stelle eingesetzten Tools gehen? Wird die App-Leistung während der Migration beeinträchtigt und für wie lange? Ist eine neue Schulung für Benutzer erforderlich?

Teams müssen all diese Fragen verstehen, bevor sie ihre Migrationsvorschläge an das Führungsteam übermitteln. Dies erfordert, dass die IT ernsthaft über den aktuellen Zustand des Netzwerks nachdenkt, um eine Basis für die vorhandene Leistung zu schaffen. Auf diese Weise können Teams die Meinungen der Entscheidungsträger bestätigen oder informieren, wo am meisten Verbesserungsbedarf besteht, und die Lösung in den Kontext der Cloud stellen.

Baselining-Leistung vor der Migration

Mit der Endbenutzererfahrung beginnt diese Grundeinstellung. Schließlich wird die IT nicht erfolgreich sein, wenn sich die Endbenutzererfahrung der Mitarbeiter nach der Cloud-Migration nicht verbessert oder sogar merklich verschlechtert. Sogar Entscheidungsträger, die sich ausschließlich auf das Endergebnis konzentrieren, werden zustimmen, da eine schlechte Benutzererfahrung einen Dominoeffekt auf die Leistung des größeren Unternehmens haben kann. Die IT muss sich daher mit dem „aktuellen Zustand“ des Netzwerks (zusammen mit der Benutzerzufriedenheit) auseinandersetzen, bevor Architekturen entwurzelt werden.

Für Anwendungen erfordert dies synthetische Webtests, die der IT eine lokale Perspektive auf die tatsächlichen Erfahrungen der Benutzer an den Standorten, an denen sie arbeiten, sowie eine klare Transparenz über den gesamten Bereitstellungspfad geben. Mit diesen Informationen kann die IT „Akzeptanzkriterien“ festlegen, die sie während und danach . erfüllen müssen Cloud-Migration, um sicherzustellen, dass die Benutzer zufrieden bleiben. Einige Beispielkriterien könnten wie folgt aussehen:

• Die Reaktionszeit sollte innerhalb von 5 % des Niveaus vor der Migration liegen
• Dienstfehlerraten sollten gleich oder niedriger als das Niveau vor der Migration sein
• Die Anwendungsverfügbarkeit sollte gleich oder niedriger als das Niveau vor der Migration sein
• Infrastrukturkosten sollten im Zuge der Migration um mindestens X % gesenkt werden

Teams müssen daher einen Pulscheck erhalten, wie schnell Apps derzeit an Benutzer bereitgestellt werden, Latenz zwischen Servern (sowohl intern als auch extern, DNS usw.), Fehlerraten, Fehlerarten und browserspezifische Leistungsprobleme. Nur mit all diesen Daten kann sich die IT über den Status des Netzwerks vor der Migration informieren.

Weitere Überwachung während der Migration

Nachdem die Teams Baselines festgelegt haben, ist es wichtig, dass sie ihre Akzeptanzkriterien während des gesamten Migrationsprozesses weiter überwachen. Teams sollten in der Lage sein, Dashboards und Warnungen zu erstellen, die melden können, wenn das Netzwerk die Kriterien nicht erfüllt, idealerweise mit den gleichen Metriken, wenn nicht mit der Überwachungslösung, die sie auf die Basisleistung bezogen haben.

• Verfügbarkeit - Bei Cloud-Anwendungen sollte die IT damit rechnen, dass die Ausfallzeit während einer bestimmten Woche auf Minuten beschränkt ist. Die meisten öffentlichen Apps streben nach 99,9 % oder besser (ca. 7 Minuten in jeder Geschäftswoche).
• DNS - Für Apps, die sich jetzt in der Cloud befinden, verfügt die IT wahrscheinlich über einen lokalen DNS-Server oder einen öffentlichen DNS-Dienst, der die IP-Adresse bereitstellt. Dies sollte aktiv überwacht werden, da es Verbindungen für alle Benutzer an einem bestimmten Standort verhindert.
• Latenz, RTT - Da die Dienste nun außerhalb des Rechenzentrums oder außerhalb des Büros stattfinden, kann die Zeit, die der Datenverkehr vom Client zum Server benötigt, erheblich unterschiedlich sein. Spitzen hier könnten mit LAN-, ISP- oder App-Problemen zusammenhängen.
• Kapazität - Die Zahlung für die Bandbreite von einem ISP ist eine Sache, aber die End-to-End-Kapazität eines Netzwerks zwischen dem Standort des Benutzers und dem App-Server wird wahrscheinlich einen anderen Engpass haben. Anhand dieser Messung kann die IT erkennen, wann sich eine Überlastung auf die Verbindungsgeschwindigkeiten auswirkt.

Spitzen und Sprünge sind nützliche Indikatoren für migrationsbezogene Fehler, die sofort angegangen werden müssen – sogar vor neuen Geschäftsanfragen –, um Probleme zu stoppen, bevor sie sich ausbreiten. Durch die Lösung von Problemen ist der Blick der IT direkt auf das Problem gerichtet, sodass Teams eher die am besten geeignete Lösung implementieren.

Nutzen Sie die Überwachung, um den Erfolg zu qualifizieren

Das Baselining, das die Teams vor der Migration durchgeführt haben, muss zu Vergleichszwecken wiederholt werden, sobald die neue Netzwerkarchitektur implementiert ist. Der Schlüssel hier ist, dieselben Prozesse (Nutzung, Muster, Zeit usw.) zu verwenden, die über das alte Netzwerk getestet wurden.

Bei allen Cloud-Migrationen geht ein gewisses Maß an Kontrolle verloren. Ob auf Bare-Metal-, Betriebssystem- oder Zugriffsebene, es ist auch wichtig, dass Teams moderne Überwachungslösungen verwenden, die die gleiche Transparenz in das neue Cloud-unterstützte Netzwerk bieten. Wenn die Infrastruktur nicht mehr im Besitz der IT ist, wird die Sichtbarkeit mit alten Überwachungstools beeinträchtigt. Dies ist von entscheidender Bedeutung, da viele Überwachungslösungen keine Transparenz in Cloud-Umgebungen oder sogar außerhalb von IT-Firewalls bieten können.

Ohne Einblicke über die Firewall hinaus ist es für die IT schwierig, Probleme zu erkennen, die auf die Infrastruktur von ISPs oder Drittanbietern zurückzuführen sind, und diese schnell zu beheben. Dies kann sowohl die Migration während der Ausführung verzögern als auch Benutzer außerhalb der IT in Nostalgie für die Tage vor der Cloud versetzen, wenn die Leistung ständig behindert wird.