Teilen
Wurden Sie schon einmal gebeten, lokale Software in eine Cloud zu migrieren? Dies mag wie eine Standardanfrage erscheinen, aber wenn Sie sich die Details ansehen, kann sich herausstellen, dass der Wechsel des Hosting-Standorts nur ein kleiner Teil der zu erledigenden Arbeit ist. Welche anderen Anforderungen oder zusätzlichen Aufgaben können auftauchen? Ich werde versuchen, diese Frage aus der Perspektive eines Migrationsprojekts zu beantworten, das wir für einen unserer Kunden bei Objectivity durchführten.
Erste Ansichten und Annahmen
Der Kunde wollte eine vorhandene Webanwendung von lokalen Servern zu einem Azure-Cloudabonnement migrieren. Dieser Schritt war Teil ihrer langfristigen Cloud-Strategie, die davon ausging, dass die Migration zu Kosteneinsparungen sowie einer erhöhten Flexibilität der Anwendung bei der zukünftigen Entwicklung führt.
Die Anwendung wird unter Verwendung des .NET-Frameworks erstellt und ihre Hauptkomponenten sind: ASP.NET MVC-Anwendung, eine Web-API und eine relationale SQL Server-Datenbank (ein allgemeiner Überblick über die Architektur ist in Abb. 1 dargestellt). Internetinformationsdienste (IIS) auf lokalen Windows Server-Computern wurden zum Hosten der .NET-Anwendungskomponenten verwendet.
Abbildung 1: Überblick über die Architektur des Kunden
Anfangs schien die Migrationsarbeit einfach zu sein. Gemeinsam mit unserem Kunden wollten wir den Lift-and-Shift-Ansatz vermeiden (Verwendung von Cloud-IaaS-Ressourcen, um die ursprüngliche lokale Infrastruktur widerzuspiegeln). Die erwartete und vereinbarte Lösung bestand darin, geeignete PaaS-Ressourcen in der Azure-Cloud zu verwenden – App Services für den Web- und API-Teil und die SQL-Datenbank für die Anwendungsdatenbank.
Was wirklich getan werden musste
Wir starteten das Projekt mit einem Kick-Off-Workshop mit dem Kunden. Unsere Gespräche ergaben zusätzliche Anforderungen und bestimmte Anwendungsabhängigkeiten und Einschränkungen, die sich auf die Migration auswirkten:
- Der Kunde wollte den Authentifizierungsmechanismus der Anwendung komplett ändern. Dies bedeutete, den bestehenden Mix aus WS-Federation, On-Premise-ADFS und Active Directory durch ein moderneres OpenID Connect-Protokoll und Azure Active Directory als Identitätsanbieter zu ersetzen.
- Die verwaltete Azure SQL-Datenbank-Instanz mit einem deaktivierten öffentlichen Endpunkt, war die einzige akzeptable Option für die Datenspeicherung.
- Die Anwendung verwendete Komponenten von SQL-Server Reporting Services (SSRS) und SQL-Server Analysis Services (SSAS), die in der verwalteten Azure SQL-Datenbank-Instanz nicht verfügbar sind (aber immer noch in Azure oder Power BI vorhanden). Unsere Idee war es, bestimmte Anwendungsfunktionen neu zu implementieren, um die Abhängigkeiten von diesen beiden Komponenten zu beseitigen.
- Wir haben uns entschieden, neue CI/CD-Pipelines für die migrierte Anwendung mit Azure DevOps zu erstellen (es wurde bereits als Git-Repository verwendet). Die Pipelines sollten vorhandene Konfigurationen in TeamCity ersetzen, die nur einen Teil der Anwendungsumgebungen unterstützten (einige Bereitstellungen wurden manuell durchgeführt).
Abbildung 2: Zielarchitektur nach der Migration
Authentifizierung in der Cloud
Die Änderung des Authentifizierungsmechanismus erwies sich als der technisch anspruchsvollste und zeitaufwendigste Teil der Arbeit. Wie bereits erwähnt, entschied sich der Kunde, eine vorhandene Azure Active Directory-Instanz als Identitätsanbieter und Authentifizierungsserver (anstelle des lokalen ADFS) zu verwenden. Darüber hinaus haben wir das WS-Federation-Protokoll durch ein modernes OpenID Connect (OIDC) ersetzt, welches eine Authentifizierungserweiterung des OAuth 2.0-Protokolls ist. Durch diese Änderungen wird die Anwendung flexibler und ist bereit für die zukünftige Interoperabilität mit verschiedenen Identitätsanbietern (OIDC-konform).
Diese spezifische Kundenanforderung führte zu tiefgreifenden Codeänderungen bei vielen Komponenten der Lösung. Eine besonders interessante technische Herausforderung war die Authentifizierung direkter AJAX-Aufrufe aus dem JavaScript-Code in einem Benutzerbrowser an die API-Schicht (Umgehung des MVC-Backends). Die OIDC-Spezifikation empfiehlt die Verwendung eines „Autorisierungscode-Flow“ für eine MVC-Webanwendung. In einem solchen Flow spielt der serverseitige Teil (MVC-Backend) die Rolle einer vertraulichen Client-Anwendung und standardmäßig werden keinen Token an einen Benutzerbrowser gesendet. Wir sind der Empfehlung gefolgt, mussten aber immer noch die Authentifizierung vieler vorhandener direkter AJAX-Aufrufe an Web-APIs von einem Benutzerbrowser (JavaScript-Code) abwickeln. Ein solches „gemischtes“ Szenario ist für OIDC- oder OAuth 2.0-Protokolle kein Standard. Wir haben uns entschieden, eine spezielle und gesicherte MVC-Aktion zu erstellen, die ein gültiges Zugriffstoken für die API-Schicht zurückgibt. Der JavaScript-Code kann die Aktion verwenden, um ein Zugriffstoken abzurufen und es dann als Trägertoken an eine AJAX-Anforderung an die API anzuhängen.
Datenbankmigration
Der Kunde wollte das Risiko einer Datenbankmigration minimieren, weshalb er uns bat, die verwaltete Instanz von Azure SQL Database zu verwenden. Dieser Azure-Dienst bietet den höchsten Kompatibilitätsgrad mit lokalen SQL-Server-Instanzen, Sicherheit und Isolierung. Die Anwendungsdatenbank verwendet beispielsweise benutzerdefinierte Funktionen, die auf CLR-Assemblys (Common Language Runtime) basieren. Diese Funktion wird nur im verwalteten Instanzmodus unterstützt. Diese Funktionen wollten wir nicht ersetzen, da dies mühsam sein und zu erhöhten Migrationskosten führen könnte.
Darüber hinaus waren Datensicherheit und -isolierung für den Kunden extrem wichtig, sodass der Managed-Instance-Modus die einzig akzeptable Option zu sein schien. Aufgrund von Sicherheitsanforderungen dürften wir die öffentliche Endpunktoption der verwalteten Instanz nicht aktivieren oder verwenden. Folglich mussten wir die VNET-Integrationsfunktion unserer API-App-Dienste nutzen, um die Datenbankkonnektivität zu ermöglichen. Das Feature erstellt ein dediziertes App-Dienst-Subnetz im virtuellen Netzwerk der von SQL verwalteten Instanz.
SQL Server Reporting and Analysis Services
Die SSRS-Abhängigkeit loszuwerden war eine einfache Aufgabe. Diese SQL-Server-Komponente wurde von der ursprünglichen Anwendung nur zum Generieren einfacher PDF-Dokumente für die Benutzer verwendet. Die gleiche Funktion kann mit einer von vielen verfügbaren JavaScript-Bibliotheken erreicht werden, die ein PDF-Dokument in einem Benutzer-Webbrowser rendern (ohne serverseitige Beteiligung). Wir haben einen solchen Ansatz angewendet und die Entfernung des SSRS führte zu großen Kosteneinsparungen und einer geringeren Lösungskomplexität.
Wie wir von Anfang an erwartet hatten, ist die Beseitigung der SSAS-Abhängigkeit eine ernstere Herausforderung. Die bestehende Lösung bietet Benutzern die Möglichkeit, basierend auf den Daten der Anwendung eigene benutzerdefinierte Berichte in Power BI zu erstellen. Die Daten werden als Power BI-Dataset-Objekt in einem Arbeitsbereich bereitgestellt. Der entscheidende Punkt ist, dass das Dataset-Modell dynamisch ist – wenn ein Benutzer spezielle Entitäten in der Anwendung erstellt, müssen neue entsprechende Datentabellen sichtbar und automatisch im Power BI-Dataset verfügbar sein. Heute wird dieses Verhalten mit SSAS leicht erreicht. Neue Datentabellen werden in der analytischen SSAS-Datenbank von der Anwendung unter Verwendung der Microsoft SSAS-API-Bibliothek erstellt. Diese Tabellen werden dann automatisch in einem Power BI-Dataset-Modell angezeigt, sodass Benutzer verbesserte Berichte erstellen können. Dynamische Dataset-Modelle werden von Power BI nur für SSAS unterstützt – sie funktionieren nicht für gewöhnliche relationale Datenbanken, die wir als bevorzugte Datenquelle für das Dataset verwenden möchten.
Wäre es nicht perfekt, wenn wir Power BI-Datasets (basierend auf einer relationalen Datenbank) programmgesteuert mithilfe einer API-Bibliothek erstellen oder ändern könnten, ähnlich wie beim aktuellen SSAS-API-Ansatz? Glücklicherweise gibt es eine Power BI-Funktion namens „XMLA- read/write Endpoints“, die sich derzeit im privaten Vorschaustatus befindet (März 2020, schreibgeschützte Endpunkte sind bereits weltweit verfügbar). Die Vorschaufunktion ermöglicht Anwendungen von Drittanbietern, über Analysis Services-API-Bibliotheken auf Power BI-Datasets zuzugreifen und ihr semantisches Datenmodell zu ändern. Dies ist möglich, da Power BI das Analysis Services-Modul intern verwendet, um seine Datasets zu unterstützen.
Dank unserer Partnerschaft mit Microsoft wurden wir zu den privaten Vorschautests eingeladen. Wir konnten überprüfen, ob die Funktion „XMLA-read/write Endpoints“ für unseren Anwendungsfall funktioniert und bestätigten, dass sie unser Problem wie erwartet löste. Da die Funktion noch nicht weltweit verfügbar war, konnten wir sie nicht in der Produktion verwenden. Daher haben wir dies mit dem Kunden besprochen und entschieden, dass der Anwendungscode vorübergehend beide Ansätze unterstützen sollte: den bestehenden mit SSAS und den neuen mit den Power BI XMLA-Endpunkten. Bis das Feature „XMLA-read/write Endpoints“ verfügbar sein wird, verwendet eine Übergangslösung die SSAS-Instanz, die auf einem virtuellen Azure-Computer gehostet wird - und den vorhandenen Anwendungscode.
Kontinuierliche Integration und Bereitstellung
Der Prozess des Erstellens von Anwendungscode, des Testens und der Bereitstellung, muss als Ergebnis der Cloud-Migration neu definiert werden. Das Definieren neuer CI/CD-Pipelines in Azure DevOps war kein großes Problem, hauptsächlich weil das Team bereits Erfahrung mit dieser Plattform hatte. Die neue Build-Definition, die in DevOps erstellt wurde, ist viel klarer und intuitiver als ihr ursprüngliches Gegenstück in TeamCity.
Die in DevOps erstellte neue Release-Pipeline (CD) ermöglicht vollautomatische Bereitstellung in alle Anwendungsumgebungen – bisher wurden nur einige von ihnen von einer TeamCity-Deployment-Konfiguration unterstützt. Die Bereitstellungsautomatisierung für alle Umgebungen war eine klare und wichtige Projektanforderung. Bei der Erstellung der Release-Pipeline haben wir das Roundhouse-Tool für die Datenbankversionierung und -bereitstellung vorgeschlagen und implementiert. Das Anwendungsteam hat gute Erfahrungen mit dem Tool gemacht, was die zukünftige Datenbankpflege verbessern soll. Vor dieser Verbesserung wurden alle Datenbankänderungen manuell angewendet, indem benutzerdefinierte SQL-Patch-Skripts ausgeführt wurden.
Auf die verwaltete SQL-Datenbank-Instanz, ohne öffentlichen Endpunkt, kann von Microsoft-gehosteten DevOps-Agenten nicht zugegriffen werden – sie ist außerhalb ihres eigenen virtuellen Azure-Netzwerks nicht sichtbar. Daher planten wir, selbst gehostete DevOps-Agents zu verwenden, die sich im Azure-Abonnement des Kunden im selben VNET befanden.
Neben der Haupt-Release-Pipeline wurden zusätzliche DevOps-Pipelines für migrierte Selenium-, SpecFlow- und tSQLt-Tests erstellt.
Zusammenfassung
Das Migrationsprojekt lief noch während ich diesen Artikel verfasste, aber die meisten Arbeiten waren bereits abgeschlossen und einige der Vorproduktionsumgebungen waren in Azure in Betrieb. Die Lektion, die wir im Laufe dieses Projekts gelernt haben, ist dass es bei der Cloud-Migration nicht nur um eine Änderung des Anwendungshostings geht. Es kann eine Vielzahl von Anforderungen, Abhängigkeiten oder Einschränkungen geben, die zu Beginn nicht klar erkennbar sind, aber später während eines Migrationsprojekts auftreten können. Der Umgang mit solchen zusätzlichen Bedenken kann wichtiger, technisch anspruchsvoller und zeitaufwendiger sein als ein „reiner“ Cloud-Migrationsprozess. Abgesehen davon, kann die Migration in die Cloud eine gute Gelegenheit sein, bestimmte Verbesserungen innerhalb der Lieferprozesse oder der Anwendung zu entdecken und umzusetzen.
Dies mag offensichtlich erscheinen, aber es ist erwähnenswert, dass eine gute Zusammenarbeit mit dem Kunden für uns immer entscheidend ist. Unser Kick-Off-Workshop zu Beginn des Projekts war eine großartige Idee, da dieser die meisten Erwartungen und technischen Herausforderungen des Kunden offenbarte. Gemeinsam konnten wir eine generelle Richtung für die neue Cloud-basierte Lösung vorgeben.
Wenn Sie mehr über die Cloud erfahren möchten, holen Sie sich unser kostenloses eBook „The Cloud Done Right: Effektives Kostenmanagement“.
