Bewertung eines Systems für den Umzug in die Azure Cloud

Einleitung

Anhand eines Beispielsystems erläutere ich die notwendigen Schritte und Optionen für eine Migration in die Azure Cloud sowie deren Vor- und Nachteile. Zum Abschluss beleuchte ich noch einige ergänzende Aspekte, die bei einer Migration beachtet werden sollten.

Migrationsschritte und Migrationsoptionen

Um eine erfolgreiche Migration eines On-Premise Systems in die Azure Cloud zu gewährleisten, schlägt Microsoft vier Schritte vor: 

1. Bewerten
2. Migrieren
3. Optimieren
4. Überwachen 

Der Schritt Bewerten bildet die Grundlage für die anderen Punkte, deshalb konzentriere ich mich in diesem Beitrag auf diesen Schritt.

Als erstes sollten alle Server, Services und Anwendungen identifiziert werden, die Teil der Migration in die Azure Cloud sein sollen. In dieser Bewertungsphase ist es wichtig, die Stakeholder der einzelnen Anwendungen mit einzubeziehen, um die Wahrscheinlichkeit einer erfolgreichen Migration zu erhöhen. 

Nachdem alle Anwendungen und die Abhängigkeiten untereinander erkannt wurden, gibt es für jede dieser Anwendungen fünf Migrations-Möglichkeiten:

Damit die Migration so reibungslos wie möglich abläuft, stellt Microsoft diverse Tools bereit, die die vier Migrationsschritte unterstützen. Eines davon ist der Gesamtkostenrechner, der die monatlichen Kosten in Azure Cloud abschätzt und damit einen groben Überblick über die zu erwartenden Kosten gibt.

Beschreibung des Beispielsystems 

Folgendes Aufrufdiagramm zeigt das System, dass als Beispiel für eine Migration in die Azure Cloud dient:

Das System besteht aus einer Java App, einem Message Broker und einem .NET Core Windows Service. Der Windows Service ruft Informationen aus einer Drittanbieter Anwendung ab. Diese Informationen werden verarbeitet und asynchron über den Message Broker an die Java-App geschickt. 

Für die Analyse und die Bewertung fokussiere ich mich auf den Message Broker und den Windows Service.

Analyse und Migrationsoptionen des Message Broker 

Aktuell wird RabbitMQ als Message Broker auf Windows VMs verwendet. In den meisten Fällen kommt das publish-subscribe model zum Einsatz. Dabei werden die Nachrichten nicht aktiv aus der Queue gelesen, sondern die Nachrichten werden an den Subscriber geschickt. 

Es gibt drei Möglichkeiten für unser System Nachrichten asynchron in der Azure Cloud zu verschicken: 

1. Rehost: RabbitMQ auf Azure VMs
2. Refactoring: RabbitMQ in Azure Kubernetes Service
3. Rearchitect: Azure Service Bus mit Event Grid 

1. Rehost: RabbitMQ auf VMs 

RabbitMQ kann ohne größere Anpassung auf Windows VMs installiert und betrieben werden, da es der aktuellen Konfiguration entspricht. Es besteht die Möglichkeit einer partiellen Migration, da RabbitMQ durch message shoveling das Weiterleiten der Nachrichten in einen anderen Message Broker unterstützt.

Vorteile:

• Wenig bis keine Anpassung an der Konfiguration
• Erfahrung mit der aktuellen Konfiguration
• Möglichkeit einer partiellen Integration mit parallelem RabbitMQ (On-Premise) Betrieb (Message shoveling) 

Nachteile:

• (Windows/Linux) VMs in Azure Cloud sind teuer (man zahlt immer für den CPU/RAM auch ohne Last)
• Skalierung ist schwieriger und dauert länger
• Ohne Skalierung dauerhaft teuer (ohne/wenig Auslastung der VM)
• Message Broker muss selbst up to date gehalten werden

2. Refactoring: RabbitMQ in Azure Kubernetes Service 

RabbitMQ gibt es auch als Docker-Container Variante. In Azure Cloud kann mittels Azure Kubernetes Service (AKS) ein Kubernetes Cluster aufgesetzt und dort ein RabbitMQ Cluster eingerichtet werden. Auch hier besteht die Möglichkeit einer partiellen Migration. 

Vorteile:

• AKS wird als kostenloser PaaS (Platform-as-a-Service) angeboten
• Skalierung innerhalb von AKS sehr einfach
• AKS Cluster kann zusätzlich für andere Container basierte Apps verwendet werden (wenn man schon die VMs bezahlt und AKS kostenlos dazu bekommt)
• Möglichkeit einer partiellen Integration mit parallelem RabbitMQ (On-Premise) Betrieb (Message shoveling). 

Nachteile:

• Für AKS muss man die VMs bezahlen und bekommt nur AKS als PaaS kostenlos bereitgestellt
• (Windows/Linux) VMs in der Azure Cloud sind teuer (man zahlt immer für den CPU/RAM auch ohne Last
• Größe der VMs schwierig zu bestimmen
• Message Broker muss selbst up to date gehalten werden 

3. Rearchitect: Azure Service Bus mit Event Grid 

Anstatt RabbitMQ wird Azure Service Bus mit Event Grid verwendet. Azure Service Bus bietet asynchrone Nachrichtverteilung an, allerdings müssen die Nachrichten aktiv aus der Queue gelesen werden. Zusammen mit Event Grid kann ein System aufgebaut werden, sodass die Queues des Azure Service Bus nicht regelmäßig abgefragt werden müssen (polling), sondern die Subscriber benachrichtigt werden, um dann die Nachricht abzuholen. 

Die Möglichkeit einer partiellen Migration gibt es auch mit dem Azure Service Bus. Die Nachrichten werden von RabbitMQ zum Azure Service Bus geschickt und beim Azure Service Bus von RabbitMQ abgeholt. Dadurch werden Zugriffe von der Cloud in das On-Premise Rechenzentrum vermieden. Im Premium Tier ist der Azure Service Bus zudem ziemlich teuer, dafür wird er aber isoliert betrieben. 

Vorteile:

• Azure Service Bus ist ein PaaS Dienst (Service Level Agreement [SLA]) mit Microsoft)
• Einfache manuelle oder automatische Skalierung möglich
• Infrastruktur und Software (Message Broker) sind immer up to date
• Möglichkeit einer Partiellen Integration mit parallelem RabbitMQ (On-Premise) Betrieb (Message shoveling).
• Sehr günstig im Standard Tier (ca. 15€ / Monat) 

Nachteile:

• Neuer Message Broker muss in allen Anwendungen angebunden werden, die vorher mit RabbitMQ kommuniziert haben (Schrittweise Migration möglich durch message shoveling)
• Teuer im Premium Tier (ca. 600€ / Monat) [1] 

Bewertung der vorgestellten Möglichkeiten für den Message Broker 

Welche der drei Möglichkeiten für den Message Broker sollte wann gewählt werden? 

Möglichkeit eins (Rehost) sollte gewählt werden, wenn man – wie beim Windows Service- schnell in die Cloud möchte / muss und nach der Migration im „Optimierungsschritt“ einige Anpassungen vornehmen möchte. Außerdem kann Möglichkeit eins gewählt werden, wenn die Skalierung der VM unrelevant ist oder wenn die Kosten für Cloud sekundär sind. 

Möglichkeit zwei (Refactoring) sollte gewählt werden, wenn noch weitere Apps in dem Kubernetes Cluster gehostet werden sollen. Allerdings muss der Message Broker selbst gewartet und aktualisiert werden. Wenn die Kosten für Maintenance mit der Migration in die Cloud reduziert werden sollen, ist diese Lösung vermutlich nicht die richtige Wahl. 

Möglichkeit drei (Rearchitect) sollte gewählt werden, wenn man alle Vorteile von PaaS nutzen möchte. Dadurch ist die Infrastruktur abstrahiert und Updates und Wartung müssen nicht selbst gemacht werden. Unter Umständen kann die Lösung im Premium Tier (ca. 600€ / Monat) sehr teuer sein, jedoch wird der Service Bus völlig isoliert betrieben. Hier muss entschieden werden, wie stark der Service isoliert sein muss und ob der Aufpreis notwendig ist. Außerdem ist eine Teilmigration möglich, da RabbitMQ mit Azure Bus zusammen interagieren kann, sodass ein Teil der Softwarelandschaft in der Cloud und der andere On-Premise sein kann. 

Analyse und Migrationsoptionen des Windows Services 

Die Software ist ein .NET 5 Web-API-Projekt mit einem Quartz.net Scheduler und mehreren Jobs. Die Software läuft in einem Windows Service als Container auf einer Windows VM.

Für den Service ergeben sich vier Migrationsmöglichkeiten: 

1. Rehost: Windows Service auf Azure Windows VM
2. Refactoring: Web-App mit Quartz.net Scheduler in einem App Service
3. Refactoring: Web-App mit WebJobs in einem App Service
4. Rearchitect: Web-App ohne Scheduler in einem App Service und zusätzlich Azure Functions als Scheduler benutzen

Replace ist für den Windows Service keine Option, da es eine spezialisierte Eigenentwicklung ist und durch keine Drittanbieter-Software ersetzt werden kann.

1. Rehost: Windows Service auf Azure Windows VM 

Da die Software bereits auf einer Windows VM läuft, kann diese ohne Anpassung auf einer Azure Windows VM installiert und betrieben werden.

 Vorteile:

• Keine Anpassung an der Software 

Nachteile:

• Windows VMs in Azure Cloud sind teuer (man zahlt immer für den CPU/ RAM auch ohne Last)
• Skalierung ist schwieriger und dauert länger
• Ohne Skalierung dauerhaft teuer (ohne/wenig Auslastung der VM)

2. Refactoring: Web-App mit Quartz.net Scheduler in einem App Service 

Die Software kann ohne große Anpassung als App Service in die Azure Cloud deployed und gehostet werden. Um den Windows Service als Container zu entfernen, muss nur eine Codezeile (.UseWindowsService()) gelöscht werden. Damit die Jobs immer rechtzeitig ausgeführt werden, darf der App Service nicht durch das Idle-Timeout abgeschaltet werden. Dafür wird das „Always on“ Flag in den App Service Settings gesetzt. 

Vorteile:

• Lediglich eine kleine Anpassung an der vorhandenen Software
• App Service ist kostengünstig in Azure Cloud
• Einfach zu skalieren 

Nachteile:

• App Service muss immer laufen „Always on“ (Zur Ausführung der Jobs) 

3. Refactoring: Web-App mit WebJobs in einem App Service 

Damit die Software mit Azure WebJobs läuft, müssen einige Änderungen gemacht werden. Quartz.net als Scheduler muss durch Azure WebJobs ersetzt werden. Auch hier muss der Windows Service als Container entfernt werden.

Dadurch wird die Abhängigkeit zu Quartz.Net zwar entfernt aber eine neue (Azure WebJobs) hinzugefügt.

 Vorteile:

• Kostengünstig in Azure Cloud
• Einfach zu skalieren 

Nachteile:

• Größere Anpassung der Software
• Einbindung einer neuen Technologie (WebJob-Technologie)
• App Service muss immer laufen „Always on“ (zur Ausführung der Jobs)

4. Rearchitect: Web-App ohne Scheduler in einem App Service und zusätzlich Azure Functions als Scheduler 

Die vierte Lösungsmöglichkeit ist die aufwändigste Variante. Es muss nicht nur der Quartz.net Scheduler entfernt werden, sondern zusätzlich noch für jeden Job eine Azure Function geschrieben werden. Zusätzlich muss eine API-Schnittstelle in der Software bereitgestellt werden, die die Function aufrufen kann, damit der Job ausgeführt werden kann. 

Vorteile:

• Azure Functions sind extrem günstig
• Das Scheduling ist nicht mehr Teil des Codes
• Einfach zu skalieren

 Nachteile:

• Größere Anpassung des Codes (Ausbau Scheduler + Implementierung neuer Web-API)
• Teurer als Variante zwei/drei da zusätzlich Azure Function bezahlt werden müssen
• Einbindung einer neun Technologie (Azure Functions)
• App Service wird immer laufen (auch ohne Always on), solange mindestens alle 20 Minuten ein Job ausgeführt wird 

Bewertung der vorgestellten Möglichkeiten für den Windows Service 

Welche der vier Möglichkeiten für den Windows Service sollte wann gewählt werden? 

Möglichkeit eins (Rehost) sollte gewählt werden, wenn man schnell in die Cloud möchte / muss und nach der Migration im „Optimierungsschritt“ einige Anpassungen vornehmen möchte bzw. auch sollte. Die Lösung ist außerdem sinnvoll, wenn die Skalierung der VM unrelevant ist oder wenn die Kosten für Cloud sekundär sind. 

Möglichkeit zwei (Refactoring mit Quartz.net) ist die präferierte Lösung, weil PaaS zur Abstrahierung der Infrastruktur verwendet und sehr wenig Änderungen an der vorhandenen Software gemacht werden müssen. Durch diese Abstrahierung ist es nicht mehr notwendig die Infrastruktur zu warten und aktuell zu halten. Diese Aufgabe wird durch den Cloud-Anbieter – in diesem Fall Microsoft – gemacht. SLA’s gewährleisten eine Aussage über die Verfügbarkeit der PaaS Lösung.

Möglichkeit drei (Refactoring mit WebJobs) sollte gewählt werden, wenn man mehr auf Microsoft Technologie setzen möchte. Quartz.Net ist ein weit verbreiteter Open Source Scheduler, der in den nächsten Jahren vermutlich stetig weiterentwickelt wird. WebJobs ist von Microsoft (Open Source) und wird vermutlich auch in den nächsten Jahren weiterentwickelt. Wenn man nur Microsoft Technologie verwenden möchte, ist das die richtige Option. 

Möglichkeit vier (Rearchitect) sollte gewählt werden, wenn man die Architektur des Services z.B. aus Performance-Gründen aufspalten möchte. Das Scheduling wird ausgelagert in Azure Functions und der Service bietet durch eine Schnittstelle die Möglichkeit von außen die Jobs anzustoßen. 

Weitere Überlegungen und Anregungen für eine erfolgreiche Migration in die Azure Cloud 

In diesem Beitrag wurden nur einige Punkte behandelt, die für eine Migration in die Azure Cloud notwendig sind. Folgende weitere Punkte sollten für eine erfolgreiche Migration in Betracht gezogen werden: 

• Ein wichtiges Thema ist Backup and restore. Wie erstellt man ein sinnvolles Backup, sodass die Daten auch wiederherstellbar sind?
• Ein anderer wichtiger Bereich ist das Thema Security. Wie sichere ich meine Anwendung vor Hackern oder schütze meine Daten vor unbefugtem Zugriff? Bei diesem Thema spielen auch Authentication and Authorization eine große Rolle.
• Wenn die Anwendung größer ist als ein kleiner Service, sollte über virtuelle Netzwerke nachgedacht werden. Wie viele Netzwerke brauche ich? Wie groß müssen diese sein? Und welche Netzwerke dürfen miteinander kommunizieren?
• Ist eine Anwendung von Geschäftszeiten abhängig, sollte über ein automatisiertes Scaling nachgedacht werden. Das wichtige dabei ist, dass es nicht nur Regeln für das Upscaling – hochfahren neuer Instanzen – gibt, sondern auch für das Downscaling – herunterfahren nicht mehr benötigter Instanzen.
• Gibt es mehrere Komponenten, die über die gleiche Einstiegs-URL erreichbar sein sollen, muss der Datenverkehr über einen Load Balancer gesteuert werden. Auch hier gibt es verschiedene Möglichkeiten in der Azure Cloud über die man sich Gedanken machen sollte.
• Die meisten Anwendungen benötigen auch eine Persistenz ihrer Daten. Die Azure Cloud stellt dafür diverse NoSQL und SQL-PaaS Lösungen bereit. Wählt man eine MS SQL-Lösung kann man sich noch zwischen SQL-Dbs oder Managed Instances entscheiden.
• Logging und Monitoring ist ebenfalls ein wichtiger Bestandteil eines Systems. Die Azure Cloud bietet hierfür Services an, damit das zentrale Logging und Monitoring erleichtert wird.

Meiner Meinung nach ist der erste Schritt Bewerten der wichtigste Schritt, um die Wahrscheinlichkeit für eine erfolgreiche Migration in die Azure Cloud zu erhöhen. In diesem Schritt beschäftigt man sich mit dem Gesamtsystem und bekommt einen sehr guten Überblick über die aktuelle und die Ziel-Architektur. Dadurch werden mögliche Probleme im Schritt Migration in die Azure Cloud frühzeitig erkannt oder vollständig vermieden.

[1] Region: Germany West Central, eine Nachrichteneinheit, 730 Std./Monat Pricing Calculator | Microsoft Azure (09.12.2021)