Modernisierungspfad für .NET-Anwendungen in Google Cloud

In diesem Dokument werden die allgemeinen Einschränkungen von monolithischen Anwendungen erläutert und eine schrittweise, aber strukturierte Vorgehensweise zur Modernisierung dieser Anwendungen beschrieben.

Dieses Dokument richtet sich an Cloud-Architekten, Systemadministratoren und CTOs, die mit Windows und der .NET-Umgebung vertraut sind und mehr über die Modernisierung erfahren möchten. Der Schwerpunkt dieses Dokuments liegt zwar auf benutzerdefinierten Serveranwendungen (z. B. ASP.NET- oder Windows-Dienstanwendungen), Sie können die Lektionen jedoch auch auf andere Anwendungsfälle anwenden.

Legacy-Anwendungen und moderne Anwendungen: Warum modernisieren?

Die Modernisierung von Legacy-Anwendungen ist ein komplexer Vorgang. Wo Sie diesen Vorgang beginnen und enden und welche Vorteile Sie erzielen, hängt weitgehend vom Zustand Ihrer Anwendungen sowie vom Zeit- und Arbeitsaufwand für die Modernisierung ab.

Was ist Legacy im Kontext von .NET-Anwendungen und was ist modern? Diese Frage lässt sich nicht einfach oder vollständig beantworten. Jede Anwendung hat spezifische Legacy- und Modernisierungsanforderungen. Legacy-Anwendungen haben jedoch einige allgemeine Einschränkungen.

Das folgende Diagramm fasst die Merkmale von Legacy-Anwendungen und modernen cloudbasierten Anwendungen zusammen.

Unterschiede zwischen monolithischen und modernen cloudbasierten Anwendungen.

Eine alte .NET-Anwendung ist in der Regel ein monolith-Objekt, das auf .NET Framework basiert und auf einem lokalen Microsoft Windows-Server gehostet und mit einem lokalen Server, auf dem Microsoft SQL Server ausgeführt wird. Die Details Ihrer Architektur können von diesen allgemeinen Merkmalen abweichen. Für die meisten monolithischen Anwendungen gelten jedoch die folgenden Einschränkungen:

  • Die Verwaltung lokaler Server, auf denen Windows und SQL Server ausgeführt werden.
  • Die begrenzten Bereitstellungsumgebungen und Lizenzkosten im Zusammenhang mit der Abhängigkeit von Windows.
  • Die Schwierigkeiten in Bezug auf ein Upgrade von Legacy-Anwendungen, die auf einer monolithischen Architektur basieren.
  • Geringe Flexibilität, um Planung, Budget und Skalierung mit lokalen Ressourcen zu planen.

Für eine cloudbasierte Architektur entwickelte Anwendungen bieten mehrere Vorteile:

  • Geringer Verwaltungsaufwand durch Einbindung in verwaltete Dienste
  • Vollständige Mobilität mit .NET Core-Containern und Containern ohne Windows-Abhängigkeiten oder Lizenzierungskosten
  • Ein Upgradepfad mit hoher Geschwindigkeit, der auf unabhängig bereitgestellten Mikrodiensten basiert
  • Umfassende Skalierbarkeit und Budget mit einer serverlosen Architektur

Verglichen mit dem herkömmlichen lokalen Ansatz bietet eine Cloud-Architektur eine kostengünstigere, effizientere und robustere Möglichkeit, Ihre Anwendungen auszuführen. Bei einem cloudbasierten Ansatz können Sie flexibler auswählen, wo und wann Ihre Anwendungen bereitgestellt werden.

Modernisierungspfad

Die Vorteile einer cloudbasierten Architektur sind zwar verständlich, doch der Weg in die Cloud ist möglicherweise nicht der richtige. Bei der Modernisierung von einer .NET-Architektur zu einer cloudbasierten Architektur wird kein Muster für die Einheit befolgen. Wie das folgende Diagramm zeigt, umfasst die Modernisierung eine Reihe von Schritten, bei denen jeder Schritt eine Einschränkung aufhebt, die Anwendungsmöglichkeiten erhöht und Möglichkeiten für spätere Phasen der Modernisierung eröffnet.

Prozess, Technologien und Dienste im Modernisierungsprozess.

Die Schritte zur Modernisierung sind in drei Phasen unterteilt:

  1. Host in der Cloud (auch Lift-and-Shift genannt)
  2. Plattformwechsel
  3. Umgestaltung und Neuerstellung

Bewertung und Lernprozesse vor der Modernisierung

Sie müssen sich auf die Modernisierung vorbereiten. Der erste Schritt besteht darin, Ihre Anwendungen und deren Abhängigkeiten zu bewerten, um zu bestimmen, welche Anwendungen für die Modernisierung geeignet sind und welche nicht geändert oder verschoben werden können (in der Regel aufgrund von Legacy-bezogenen oder behördlichen Gründen). Weitere Informationen finden Sie unter Migration zu Google Cloud: Arbeitslasten bewerten und erkennen.

Parallel zu dieser Bewertung muss Ihr Team mehr über die Funktionen der Cloud erfahren. Google Cloud bietet Zertifizierungen, technische Leitfäden und Windows- und .NET-spezifische Codelabs, damit der Lernprozess beschleunigt wird.

Nachdem Sie festgestellt haben, welche Anwendungen modernisiert werden sollen, können Sie damit beginnen, Ihre Legacy-Anwendungen unverändert oder mit minimalen Anwendungscode- oder Konfigurationsänderungen in die Cloud zu migrieren.

Phase 1: Host in der Cloud

Das Hauptziel dieser ersten Phase besteht darin, die Last der Serververwaltung von Ihren lokalen Ressourcen in die Cloudinfrastruktur zu übertragen. In dieser Phase sorgen Sie dafür, dass Ihre Infrastruktur für die Cloud bereit ist, damit Sie sie in späteren Phasen für die Cloud optimieren können.

Manuelle Migration und toolbasierte Migration

Bei Windows-basierten .NET-Anwendungen werden in der Regel zuerst lokale Windows Server- und SQL Server-Instanzen in Compute Engine-VM-Instanzen verschoben. Sie können diesen Vorgang manuell ausführen oder mit einem Migrationstool automatisieren.

Bei einer manuellen Migration können Sie Windows Server-Images in Compute Engine zum Starten von Instanzen verwenden. Der Google Cloud Marketplace bietet auch Lösungen für die Bereitstellung in Compute Engine, z.B. die ASP.NET Framework-Lösung, um eine Windows Server-VM zu erhalten, z. B. IIS, SQL Express und ASP.NET.

Ebenso können Sie SQL Server-Instanzen aus SQL Server-Images starten oder direkt zu einer verwalteteren Lösung wechseln – Cloud SQL for SQL Server.

Google Cloud bietet außerdem Migrationstools wie Migrate for Compute Engine oder VMware Engine, um lokale VMware-VMs in eine VMware-Umgebung in Google Cloud zu migrieren.

Nach der Konfiguration der VMs erstellen Sie in der Regel benutzerdefinierte VM-Images, damit Sie bei Bedarf neue Instanzen erstellen können. Dieser Schritt ist auch für Instanzvorlagen wichtig, die weiter unten in diesem Dokument behandelt werden.

Wenn Sie Domaindienste in der Cloud benötigen, können Sie eine fehlertolerante Microsoft Active Directory-Umgebung mit einer Virtual Private Cloud (VPC) in Compute Engine bereitstellen oder direkt zu Verwalteter Dienst für Microsoft Active Directory wechseln.

Lokale Konnektivität und Cloud-Konnektivität

Wenn Sie VMs in die Cloud migrieren, ist es nicht unüblich, einige Arbeitslasten lokal aufzubewahren, z. B. wenn Sie Anwendungen haben, die Legacy-Hardware oder -Software erfordern, oder um Anforderungen an Compliance und lokale Vorschriften zu erfüllen. Sie benötigen ein VPN oder eine Interconnect-Lösung, um lokale und Cloud-Ressourcen sicher zu verbinden. Informationen zum Erstellen und Verwalten dieser Verbindung sowie zu den weiteren Auswirkungen von Ausführen von Hybrid-Cloud- und lokalen Arbeitslasten finden Sie unter Migration zu Google Cloud: Foundation aufbauen.

Anfängliche Vorteile

Am Ende von Phase 1 haben Sie eine grundlegende Infrastruktur, die in der Cloud ausgeführt wird. Dies bietet unter anderem folgende Vorteile:

  • Kostenoptimierung. Sie können einen benutzerdefinierten Maschinentyp (CPU, Arbeitsspeicher und Speicher) erstellen und bezahlen. VMs sowie die Notfallwiederherstellungsumgebungen starten und stoppen und zahlen nur, wenn sie ausgeführt werden. Außerdem erhalten Sie vor der Migration Empfehlungen zur Größenanpassung.
  • Erhöhte operative Effizienz. Sie können VMs mit nichtflüchtigem Speicher verknüpfen und Snapshots erstellen, um die Sicherung und Wiederherstellung zu vereinfachen.
  • Mehr Zuverlässigkeit: Dank des Features für Live-Migration müssen Sie keine Wartungsfenster mehr planen.

Diese anfänglichen Vorteile sind nützlich, aber wenn Sie mit der Optimierung für die Cloud beginnen, erhalten Sie noch mehr Vorteile.

Phase 2: Plattformumgestaltung

Bei einer Plattformumgestaltung optimieren Sie Ihre Anwendung, indem Sie Teile der Anwendungskomponenten (z. B. Datenbank, Caching-Ebene oder Speichersystem) aktualisieren, dabei jedoch nicht die Architektur der Anwendung ändern und nur geringfügige Änderungen an der Codebasis ausführen. Das Ziel von Phase 2 besteht darin, mit der Verwendung von Cloud-Features für eine bessere Verwaltung, Robustheit, Skalierbarkeit und Elastizität der Anwendung zu beginnen, ohne diese neu zu strukturieren oder die VM-Umgebung zu verlassen.

Compute Engine nutzen

Compute Engine bietet einige Standardfeatures, die nützlich sind. Beispielsweise können Sie in Compute Engine Instanzvorlagen verwenden, um Vorlagen aus vorhandenen VM-Konfigurationen zu erstellen. Instanzgruppen sind identische VMs, mit denen Sie die Leistung und Redundanz Ihrer Anwendung effizient skalieren können. Verwaltete Instanzgruppen bieten neben einfachen Load-Balancing und Redundanz Skalierungsfunktionen wie Autoscaling, Hochverfügbarkeitsfeatures wie automatische Reparatur, regionale Bereitstellungen und Sicherheitsfunktionen wie automatische Updates.

Mit diesen Features können Sie in der VM-Umgebung bleiben, aber die Ausfallsicherheit, Redundanz und die Verfügbarkeit Ihrer Anwendungen erhöhen, ohne Ihre Anwendung vollständig neu strukturieren zu müssen.

Nach direkten Ersetzungen suchen

Wenn Sie Ihre Anwendung in die Cloud verschieben, müssen Sie nach Möglichkeiten suchen, um Ihre gehostete Infrastruktur durch verwaltete Cloud-Optionen von Google und Drittanbietern in Cloud Marketplace zu ersetzen, darunter:

  • Cloud SQL anstelle von selbst gehosteten SQL Server-, MySQL- oder Postgres-Instanzen. Dank Cloud SQL können Sie sich auf die Verwaltung der Datenbank konzentrieren, anstatt die Infrastruktur verwalten zu müssen (z. B. Datenbank-VMs für Sicherheitszwecke oder für die Verwaltung von Sicherungen) mit dem zusätzlichen Vorteil, die für eine Windows-Lizenz erforderlich ist.
  • Verwalteter Dienst für Microsoft Active Directory anstelle von selbst gehostetem Active Directory.
  • Memorystore anstelle von selbst gehosteten Redis-Instanzen.

Diese Ersetzungen erfordern in der Regel keine Codeänderungen und nur minimale Konfigurationsänderungen und bieten die folgenden Vorteile: Minimaler Verwaltungsaufwand, verbesserte Sicherheit und Skalierbarkeit.

Erste Schritte mit Windows-Containern

Nachdem Sie die grundlegenden Funktionen für die Cloud optimiert haben, können Sie damit beginnen, VMs in Container zu verschieben.

Ein Container ist ein Ressourcenpaket, das eine Anwendung und alle zugehörigen Abhängigkeiten enthält. Im Vergleich zur Ausführung Ihrer Anwendung direkt auf einer VM können Sie Ihre Container mit Containern in verschiedenen Umgebungen ausführen. Dies ist eine einheitlicher, vorhersehbarer und effizientere Ausführung (insbesondere, wenn Sie mehrere Container auf demselben Host ausführen). Die Umgebung rund um Container (z. B. Kubernetes, Istio und Knative) bietet auch eine Reihe von Verwaltungs-, Belastbarkeits- und Monitoring-Funktionen, die die Umwandlung Ihrer Anwendung von einem einzelnen Monolithen zu einer Reihe von fokussierten Mikrodiensten weiter beschleunigen können.

Die Containerisierung war schon seit einiger Zeit nur für Linux verfügbar. Windows-Anwendungen konnten nicht von Containern profitieren. Das hat sich an Windows-Containern und den nachfolgenden Unterstützungen in Kubernetes und Google Kubernetes Engine (GKE) geändert.

Windows-Container sind eine Option, wenn Sie .NET Framework-Anwendungen nicht zu .NET Core migrieren, aber trotzdem die Vorteile von Containern nutzen möchten (z. B. Flexibilität, Portabilität und Kontrolle). Sie müssendas richtige Betriebssystem für das Targeting auswählen .NET Framework verwendet werden. Beachten Sie, dass nicht alle Windows-Stacks unterstützt in Windows-Containern werden. Die Einschränkungen dieses Ansatzes und der Alternativen finden Sie weiter unten in diesem Dokument unter .NET Core- und Linux-Container.

Nachdem Sie Ihre .NET Framework-Anwendung in einen Windows-Container containerisiert haben, wird empfohlen, sie in einem Kubernetes-Cluster auszuführen. Kubernetes bietet Standardfeatures wie das Erkennen, wenn ein Container-Pod ausgefallen ist und neu erstellt wird, sowie Autoscaling, Pods, automatisierte Rollouts oder Rollbacks und Systemdiagnosen. GKE bietet mit Anthos Funktionen wie Autoscaling von Clustern, regionale Cluster, hochverfügbare Steuerungsebenen und Unterstützung für Hybrid- und Multi-Cloud. Wenn Sie GKE oder Anthos verwenden, können Sie mit Migrate for Anthos die Migration von Windows-VMs in Container vereinfachen und beschleunigen. Migrate for Anthos automatisiert die Extraktion von Anwendungen von VMs in Container, ohne dass Sie Anwendungen umschreiben oder umgestalten müssen.

Mit den richtigen Features in Compute Engine können Sie zwar viele Vorteile erzielen, aber durch den Wechsel zu Containern und GKE können Sie Ihre VMs vollständig nutzen, indem Sie mehrere Pods auf dieselben VMs verpacken. Diese Strategie führt potenziell zu weniger VMs und niedrigeren Windows-Lizenzierungskosten.

Wenn Sie sowohl Windows- als auch Linux-Container deklarativ mit Kubernetes und GKE verwalten, können Sie die Infrastrukturverwaltung optimieren. Die Containerisierung steht für die nächste Phase der Modernisierung bereit.

Phase 3: Umgestaltung und Neuerstellung

Die Umgestaltung der Plattform ist nur einer der umfassenden Vorteile der Cloud. Die Transformation Ihrer Architektur auf eine cloudbasierte Plattform bietet mehrere Vorteile:

Der Weg zu verwalteten Diensten

Wenn Sie Teile Ihrer Anwendung neu schreiben, empfehlen wir Ihnen, von gehosteten Diensten zu verwalteten Diensten zu wechseln. Beispielsweise können Sie Folgendes eingeben:

Sie benötigen zwar zusätzlichen Code, um Ihre Anwendung in diese Dienste einzubinden, aber dies ist eine sinnvolle Investition, da Sie die Belastung der Plattformverwaltung zu Google Cloud verlagern. Google Cloud .NET-Clientbibliotheken, Tools for Visual Studio und Cloud Code für Visual Mit Studio Code können Sie die .NET-Umgebung und -Tools beibehalten, während Sie diese Dienste integrieren.

Verwaltete Dienste können auch Vorgänge für Ihre Anwendung unterstützen. Sie können Ihre Anwendungslogs in Cloud Logging speichern und Ihre Anwendungsmesswerte an Cloud Monitoring senden, wo Sie Dashboards mit Server- und Anwendungsmesswerten erstellen können. Google Cloud bietet .NET-Clientbibliotheken für Cloud Logging, Cloud Monitoring und Cloud Trace, um die Option zu aktivieren.

.NET Core- und Linux-Container

Wenn Ihre Anwendung eine Legacy-Version der .NET Framework-Anwendung ist, die nur unter Windows ausgeführt wird, kann es Ihnen praktisch vorkommen, sie weiterhin auf einem Windows-Server in Compute Engine oder in einem Windows Server-Container in GKE auszuführen. Dieser Ansatz funktioniert zwar möglicherweise kurzfristig, kann aber auf lange Sicht zu starken Einschränkungen führen. Für Windows fallen Lizenzgebühren an und es werden insgesamt mehr Ressourcen als bei Linux bereitgestellt. Diese Faktoren können langfristig zu höheren Gesamtbetriebskosten führen.

.NET Core ist die moderne und modulare Version von .NET Framework. Die Anleitung von Microsoft besagt, dass .NET Core die Zukunft von .NET ist. Obwohl Microsoft plant, .NET Framework zu unterstützen, werden neue Funktionen nur zu .NET Core (und schließlich .NET 5) hinzugefügt. Auch wenn Sie die Ausführung unter Windows ausführen möchten, sollte jegliche neue Entwicklung auf .NET Core erfolgen.

Einer der wichtigsten Aspekte von .NET Core ist Multi-Platform. Sie können eine .NET Core-Anwendung in einen Linux-Container containerisieren. Linux-Container sind schlanker als Windows-Container und werden auf mehr Plattformen effizienter ausgeführt. Bei diesem Faktor werden Bereitstellungsoptionen für .NET-Anwendungen erstellt. Sie können also frei von Abhängigkeiten von Windows und den damit verbundenen Lizenzierungskosten profitieren.

.NET Framework-Anwendungen zu .NET Core portieren

Eine gute Möglichkeit, auf .NET Core umzustellen, finden Sie unter Übersicht über die Portierung von .NET Framework auf .NET Core. Mit Tools wie dem .NET Portability Analyzer und dem .NET API-Analysetool können Sie feststellen, ob Assembles und APIs portierbar sind. Andere Portierungstools wie dotnet Try-convert können nützlich sein.

Externe Tools können Ihnen dabei helfen, Kompatibilitätsprobleme zu identifizieren und zu entscheiden, welche Komponenten zuerst migriert werden sollen. Letztendlich müssen Sie .NET Core-Projekte erstellen, Ihren .NET Framework-Code schrittweise in das neue Projekt verschieben und etwaige Inkompatibilitäten beheben. Bevor Sie Ihren Code portieren, ist es wichtig, dass Sie Tests durchführen und die Funktion nach der Portierung testen. Wir empfehlen Ihnen, A/B-Tests zu verwenden, um alten und neuen Code zu testen. Mit A/B-Tests können Sie Ihre Legacy-Anwendung weiterführen und einige Ihrer Nutzer zur neuen Anwendung leiten. Mit diesem Ansatz können Sie Ausgaben, Skalierbarkeit und Robustheit der neuen Anwendung testen. Zur Unterstützung bei A/B-Tests bietet Google Cloud Load-Balancing-Lösungen wie Traffic Director.

Kulturelle Transformation

Die Transformation von .NET Framework und Windows-Servern in .NET Core- und Linux-Container ist nicht nur technisch möglich. Diese Umstellung erfordert eine kulturelle Transformation in Ihrer Organisation. Mitarbeiter, die möglicherweise nur für Windows-Umgebungen verwendet werden, müssen sich an Umgebungen mit mehreren Plattformen anpassen. Diese kulturelle Transformation erfordert Zeit und Budget für das Training in .NET Core-, Linux- und Container-Tools wie Docker und Kubernetes. Durch eine Transformation von einer Windows-Struktur auf eine Multi-Platform-Organisation haben Sie jedoch Zugriff auf mehr Tools und Fähigkeiten.

Aufteilung monolithischer Anwendungen

Der Wechsel von .NET Framework zu .NET Core kann mehrere Fragen aufwerfen, darunter:

  • Schreiben Sie Ihre gesamte Anwendung in .NET Core um?
  • Zerlegen Sie Ihre Anwendung in kleinere Dienste und schreiben diese in .NET Core?
  • Schreiben Sie nur neue Dienste in .NET Core?

Wie Sie entscheiden müssen, welche Vorteile, Zeit und Kosten mit den einzelnen Ansätzen verbunden sind. Es empfiehlt sich, einen ausgewogenen Ansatz zu haben, bei dem nicht alle Daten auf einmal neu geschrieben werden. Stattdessen können Sie neue Dienste schreiben. .NET Core und unterteilen Sie Ihren bestehenden monolithischen Dienst in kleinere Dienste in .NET Core. Die folgenden Whitepaper können Ihnen bei der Planung helfen:

Bereitstellungsoptionen für .NET Core-Container

Für die Bereitstellung von .NET-Anwendungen in Google Cloud stehen Ihnen verschiedene Optionen zum Bereitstellen von .NET Core-Containern in Google Cloud zur Verfügung. Wenn Sie Ihre monolithische Anwendung auf Mikrodienste setzen, können Sie je nach Architektur und Design Ihrer Mikrodienste mehr als eine Hosting-Lösung verwenden.

Anhand der folgenden Fragen können Sie die optimale Hosting-Strategie ermitteln:

  • Wie wird die Anwendung ausgelöst? Alle Hostinglösungen sind für Standard-HTTP(S) geeignet, aber wenn Ihr Protokoll TCP/UDP oder ein proprietäres Protokoll ist, ist GKE möglicherweise die einzige Option.
  • Benötigt Ihre Anwendung eine spezielle Hardware? Cloud Run bietet für jede Anfrage eine angemessene, aber begrenzte Menge an RAM und CPU. Cloud Run for Anthos bietet weitere Anpassungsoptionen wie GPU, mehr Speicher und Speicherplatz.
  • Welche Erwartungen gibt es für die Skalierung? Wenn Ihre Anwendung Zeitüberschreitungen aufweist, können serverlose Lösungen wie Cloud Run die Möglichkeit bieten, auf null herunterzuskalieren.
  • Wie wichtig ist die Latenz und wie tolerant ist Ihre Anwendung gegenüber Kaltstarts? Bei geringer Toleranz gegenüber Kaltstarts müssen Sie die Verwendung einer Mindestzahl von Instanzen in der flexiblen App Engine-Umgebung oder GKE mit Autoscaling erwägen.
  • Kommuniziert Ihr Dienst mit anderen Diensten? Wenn Ihre Anwendung Zugriff auf Ihre VPC oder eine Peering-VPC benötigt, sollten Sie Ihre Anwendung in der flexiblen App Engine-Umgebung, in Cloud Run for Anthos oder in GKE hosten.

Wir empfehlen Ihnen, die Dokumentation für jede Hostingumgebung zu lesen, um sich mit den Funktionen, Stärken und Schwächen und dem Preismodell vertraut zu machen.

Allgemein gilt: Wenn Sie Mikrodienste erstellen möchten, die HTTP-Anfragen verarbeiten, müssen Sie nach Möglichkeit Cloud Run bereitstellen und auf GKE zurückgreifen, wenn Sie in der Kubernetes-Umgebung bleiben oder weitere Anpassungsoptionen. GKE ist auch die Standardauswahl, wenn Sie einen lang andauernden Prozess haben, z. B. einen Prozess, der eine Warteschlange überwacht, oder eine Anwendung, die andere Protokolle als HTTP(S) verwendet. Wir empfehlen, die flexible App Engine-Umgebung zu verwenden, wenn Sie Cloud Run aufgrund von Einschränkungen nicht verwenden können, z. B. mit WebSocket-Unterstützung oder Verbindung zu einem VPC-Netzwerk, oder wenn Ihre Anwendung nicht die Komplexität von Kubernetes rechtfertigen.

Die App Engine-Standardumgebung und Cloud Functions sind ebenfalls gute serverlose Bereitstellungsoptionen. Sie werden jedoch hier nicht erläutert, da sie derzeit .NET Core nicht unterstützen.

Flexible App Engine-Umgebung

Die flexible App Engine-Umgebung ist eine Plattform, die Webanwendungen in vielen Sprachen, einschließlich .NET Core, direkt ausführen kann. App Engine installiert und führt Ihre .NET Core-Anwendung in Docker-Containern mit der .NET-Laufzeit aus. Wenn Sie diese Laufzeit anpassen möchten, können Sie App Engine Ihr eigenes Dockerfile bereitstellen. App Engine verwendet weiterhin VM-basierte Compute Engine-Instanzen, aber App Engine verwaltet diese VMs. Die flexible Umgebung enthält einige Funktionen wie Autoscaling, Überarbeitungen und Trafficaufteilung. Die flexible Umgebung lässt auch mehrere Dienste in einer einzigen Anwendung zu. Diese ist für Mikrodienste hilfreich.

Wenn Sie ein Web-Front-End oder eine kleine Anzahl ähnlicher Container bereitstellen möchten, ist App Engine eine Option. Mit App Engine sind die Bereitstellungszeiten jedoch generell langsamer als andere Optionen. Ihnen werden die Kosten für jede VM auch dann berechnet, wenn Sie die Anwendung nicht verwenden.

Kubernetes und GKE

Wenn Sie die Ausführung in einer containeroptimierten Umgebung vornehmen möchten, erfordert dieser Ansatz wahrscheinlich Kubernetes und dessen verwaltete Version, GKE. Kubernetes und GKE sind besonders geeignet, wenn Sie viele Container mit unterschiedlichen Anforderungen bereitstellen möchten und eine detaillierte Kontrolle über die Bereitstellung und Verwaltung der einzelnen Container wünschen.

Kubernetes wurde für die skalierte Ausführung von Containern entwickelt und bietet Bausteine wie Pods, Dienste, Deployments und Replikatsets. Ein korrektes Verständnis und die Verwendung dieser Konstrukte können eine Herausforderung darstellen. Sie ermöglichen aber einen Großteil der Verwaltungsaufwand von Containern für Kubernetes. Sie eignen sich außerdem für Mikrodienstarchitekturen, bei denen ein Mikrodienst ein Deployment mit einer Reihe von Pods mit Load-Balancing hinter einem Dienst ist.

Zusätzlich zu Kubernetes bietet GKE Features wie Cluster-Autoscaling, automatische Reparatur und automatisches Upgrade zur Vereinfachung der Kubernetes-Verwaltung und Sicherheitsfeatures wie Container-Isolierung und private Registries. Obwohl Ihnen jeder Knoten in GKE in Rechnung gestellt wird, unterstützt GKE VMs auf Abruf, um die Kosten zu senken.

GKE kann sowohl Windows- als auch Linux-Container verwalten. Diese Funktion ist nützlich, wenn Sie eine einzelne Hybridumgebung für Windows-basierte und moderne Linux-basierte Anwendungen verwalten möchten.

Knative und Cloud Run

Für Ihre zustandslosen .NET Core-Container bieten Knative und die verwaltete Version Cloud Run eine serverlose Containerumgebung. Serverlose Container bieten Vorteile wie Bereitstellung, Autoscaling und Load-Balancing ohne den mit der Infrastrukturverwaltung verbundenen Aufwand.

Zur Bereitstellung von Containern in einem Kubernetes-Cluster bietet Knative eine API-Oberfläche, die höher und kleiner als Kubernetes ist. Mit Knative können Sie die Komplexität von Kubernetes vermeiden und so die Container-Bereitstellung vereinfachen.

Cloud Run folgt der Knative API, wird jedoch in der Google-Infrastruktur ausgeführt, sodass keine Kubernetes-Cluster mehr vorhanden sind. Cloud Run bietet eine serverlose Option für Container. Standardmäßig werden in Cloud Run Container automatisch skaliert und für die Dauer der Anfrage in Rechnung gestellt. Die Bereitstellungszeit erfolgt in Sekunden. Cloud Run übernimmt auch nützliche Features von App Engine, z. B. Überarbeitungen und Trafficaufteilung.

Cloud Run for Anthos ist die flexiblere Version von Cloud Run für Kunden, die die Einfachheit von Knative und Cloud Run mit der operativen Flexibilität von Kubernetes wünschen. Mit Cloud Run on Anthos können Sie beispielsweise zugrunde liegenden Instanzen, auf denen Ihre Container ausgeführt werden, GPUs hinzufügen oder auf andere VMs oder GKE-Cluster in derselben VPC zugreifen.

Cloud Run ist in andere Dienste wie Pub/Sub, Cloud Scheduler, Cloud Tasks und Back-Ends wie Cloud SQL integriert. Sie kann sowohl für automatisch skalierte Web-Front-Ends als auch für interne Mikrodienste verwendet werden, die durch Ereignisse ausgelöst werden.

Modernisierung von Vorgängen

Modernisieren bezieht sich nicht nur auf Ihren Anwendungscode. Es gilt für den gesamten Lebenszyklus Ihrer Anwendung – wie er erstellt, getestet, bereitgestellt und überwacht wird. Wenn Sie sich für Modernisierung entscheiden, müssen Sie daher auch Vorgänge berücksichtigen.

Mit Cloud Build können Sie den Zyklus zum Erstellen, Testen und Bereitstellen der Anwendung modernisieren und automatisieren. Cloud Build bietet nicht nur Builder für .NET Core, sondern lässt sich auch in den Vulnerability Scanner von Container Registry und in die Binärautorisierung integrieren. Damit wird verhindert, dass Images, die aus einem unbekannten Quellcode oder aus unsicheren Repositories erstellt wurden, in Ihrer Bereitstellungsumgebung ausgeführt werden.

Die Operations Suite von Google Cloud (ehemals Stackdriver) bietet mehrere Dienste, mit denen Sie die Sichtbarkeit Ihrer Anwendung modernisieren können:

Sie können die Bibliothek Google.Cloud.Diagnostics.AspNetCore verwenden, um die Operations Suite von Google Cloud einfach in Ihre ASP.NET Core-Anwendungen zu integrieren. Zum Exportieren von OpenTelemetry-Messwerten in die Operations Suite können Sie die Bibliothek OpenTelemetry.Exporter.Stackdriver der Operations Suite von Google Cloud verwenden.

Weitere Informationen dazu, wie sich die Modernisierung auf Teamprozesse und die Kultur einer Organisation auswirkt, finden Sie unter Google Cloud-Lösungen für DevOps.

Nächste Schritte