Java-Anwendungsmodernisierung mit Anthos: Nutzerhandbuch

Last reviewed 2020-06-30 UTC

Dieses Dokument erläutert den Prozess, die Best Practices und Tools für die Verwendung von Anthos zur Modernisierung monolithischer Legacy-Java-Anwendungen.

Dieses Dokument richtet sich an CTOs, CIOs, Enterprise Architects, Anwendungsentwickler, IT-Sicherheitsadministratoren, Anwendungsentwickler, DevOps-Teams und Site Reliability Engineering-Teams (SRE). Es werden Grundkenntnisse in der Containerisierung sowie von operativen und Entwicklungsvorteilen vorausgesetzt.

In diesem Dokument wird ein zweistufiger Ansatz zur Modernisierung vorgeschlagen:

1. Containerisieren: In dieser Phase containerisieren Sie entweder lokal oder in Google Cloud geeignete Anwendungen und stellen sie auf der Anthos-Plattform bereit. In dieser Phase werden verschiedene Dienste und Technologien wie Migrate for Container, moderne Verfahren zur Continuous Integration/Continuous Deployment (CI/CD) und Systemintegrierungstools verwendet.
2. Refaktorieren und Plattform wechseln: Mit der Zeit werden monolithische Legacy-Anwendungen in moderne Java-Frameworks wie Spring Boot und Mikrodienste refaktoriert und ein Plattformwechsel durchgeführt.

Dieses Dokument enthält Anleitungen und Ressourcen für die einzelnen Phasen. Es bietet auch einen alternativen Pfad für den Fall, dass Sie Ihr Unternehmen auf virtuellen Maschinen (VMs) halten möchten.

Ein Fall für Modernisierung

Viele Organisationen haben Mühe, ihre Geschäftsanwendungen am Laufen zu halten und gleichzeitig Innovationen zu fördern. Entwicklungs- und Betriebsteams müssen sich den neuen Anforderungen an Anwendungsdienste stellen und bestehende Anwendungsportfolios verwalten, betreiben und verbessern.

Diese neue Nachfrage ergibt sich aus digitalen Geschäftsinitiativen und dem Ziel der digitalen Transformation zur Verbesserung bestehender Funktionen. Laut einem Gartner-Bericht (Building a Multiplatform Application Modernization Business Case, November 2019) werden allerdings 90 % der aktuellen Anwendungen noch bis zum Jahr 2025 verwendet. Außerdem sammeln sich die technischen Schulden durch Unterstützung und Verwaltung dieser Anwendungen weiter an und werden mehr als 40 % der derzeitigen IT-Budgets aufbrauchen.

Obwohl Unternehmen neue Anwendungen entwickeln und anwenden, handelt es sich bei der Mehrzahl ihrer Anwendungen immer noch um herkömmliche, monolithische Anwendungen. Viele dieser Legacy-Anwendungen werden auf proprietären und kommerziellen Anwendungsservern wie IBM WebSphere oder Oracle® WebLogic ausgeführt. Da diese Anwendungen häufig gut optimiert, gewartet und verwaltet werden, sind die Unternehmen gefordert, über diese Anwendungen hinaus innovativ zu sein. Darüber hinaus können proprietäre Anwendungsserver den operativen Aufwand erhöhen und (in vielen Fällen) kostspielige Lizenzvereinbarungen nach sich ziehen.

Einige Studien deuten darauf hin, dass Einrichtungen Zeit und Geld sparen können, indem sie herkömmliche Anwendungen modernisieren, anstatt vorhandenen Anwendungscode umzuschreiben. Jede Strategie zur Modernisierung von Legacy-Anwendungen muss darauf abzielen, sowohl Zeit als auch Kosten für die Modernisierung zu reduzieren.

Moderne Anwendungen

Mit modernen Anwendungen ermöglichen Sie Ihren Kunden eine bessere Nutzererfahrung. Dies kann zu größerer Kundentreue und Kundenzufriedenheit führen und somit die Rentabilität erhöhen. In den zehn Grundsätzen der modernen Anwendungs- und Plattformentwicklung werden die Vorteile der digitalen Transformation hervorgehoben. In den folgenden Abschnitten werden diese Aspekte erläutert.

Steigerung der Produktivität von Entwicklern und Operatoren

Legacy-Anwendungen sind häufig monolithische Anwendungen. Diese Anwendungen haben eine große Codebasis, die mehrere Funktionen ausführt. Wenn die Anwendungen und die Teams, die sie entwickeln und verwalten, größer werden, wird es zunehmend schwieriger, neue Funktionen schnell einzuarbeiten und freizugeben. Es gibt viele Abhängigkeiten zwischen Teams, die abgeglichen und genehmigt werden müssen, bevor eine Änderung in die Produktion und an den Kunden gehen werden kann. Diese Dynamik kann zu einer geringeren Produktivität von Entwicklern und Operatoren sowie zu sinkender Kundenunzufriedenheit führen.

Moderne Anwendungen werden mit Mikrodiensten erstellt. Verschiedene Domains einer monolithischen Anwendung werden in separate Dienste aufgeteilt, die jeweils für eine bestimmte Funktion verantwortlich sind; daher der Begriff Mikrodienste. Diese Architektur bietet mehrere Vorteile:

• Für Entwickler: Durch die Entkopplung der Dienste voneinander können Ihre Entwickler unabhängig von anderen Diensten an ihrer jeweiligen Funktion arbeiten. Dadurch wird die Produktivität der Entwickler gesteigert, da diese nun Funktionen zu ihrem Dienst hinzufügen können, ohne enge Abhängigkeiten anderer Dienste und Teams zu haben.
• Für Operatoren: Jedes Mikrodienst-Release implementiert kleine Änderungen, was für Ihr operatives Team viel einfacher zu handhaben ist als eine große, komplexe Änderung. Durch die Bereitstellung kleinerer Änderungen in dieser kontrollierten Art und Weise entstehen weniger Risiken, wenn ein Release fehlschlägt, was die Produktivität des operativen Teams steigert.
• Für Kunden: Durch die Entwicklungs- und operative Effizienz einer modernen Architektur können Ihre Teams schneller neue Funktionen schneller bereitstellen als mit einer monolithischen Architektur.

Schwerpunkt auf Diensten und APIs

Legacy-Anwendungen werden oft als Infrastruktur angesehen. Server, virtuelle Maschinen (VMs), Netzwerke und Speicher sind wichtige Designelemente für eine monolithische Anwendung. Moderne Anwendungen werden als Dienste und APIs betrachtet. Der Schwerpunkt liegt auf Diensten und APIs:

• Dienstredundanz und Ausfallsicherheit: Sie können Dienste überall und häufig an mehreren Orten ausführen, z. B. VMs, Container oder Cluster.
• Dienstverfügbarkeit: Wenn Sie sich auf Dienste konzentrieren, kann die Gesamtverfügbarkeit Ihrer Anwendung gesteigert werden. Solange der Dienst verfügbar ist, sind Infrastrukturfehler hinfällig und irrelevant. Der Entwurf und die Konzeption von Diensten und APIs anstelle von Infrastruktur erlaubt Ihnen, den Fokus auf Verfügbarkeit zu setzen. So können Sie Ihr Service Level Objective (SLO) erreichen.

Als Mikrodienste in Containern ausführen

Legacy-Anwendungen werden in der Regel als VMs oder auf Bare-Metal ausgeführt. Diese Plattformen sind teuer, werden ineffizient genutzt (mit zu wenig genutzten CPUs und RAM) und schwieriger zu verwalten als moderne Cloud-basierte Plattformen (insbesondere für Bare-Metal-Server). Moderne Anwendungen werden als Mikrodienste in Containern ausgeführt. Dies bietet viele Vorteile, unter anderem:

• Kleinere, effizientere Anwendungen: Container können einen Mikrodienst so verpacken, dass er zwei bis drei Mal kleiner ist als eine monolithische Anwendung.
• Linux-Nutzerspeicher-Isolierung: Sie können mehrere Container auf einem einzelnen Host ausführen und ihn so effizient nutzen.
• Portabilität zwischen verschiedenen Umgebungen und Infrastruktur: Da Container die Anwendung mit allen Abhängigkeiten und erforderlichen Bibliotheken umschließen, können Sie Container in jeder Umgebung ausführen – in einem lokalen Rechenzentrum oder in einer öffentlichen Cloud-Umgebung.

Auf offenen Standards aufbauen

Legacy-Anwendungen nutzen häufig kommerzielle oder lizenzierte Produkte zur Nutzung der Funktionen. Dieser Ansatz ist nicht nur teuer, da Lizenzkosten anfallen, sondern macht die Anwendung auch stark abhängig von kommerziellen Plattformen.

In manchen Fällen wird die kommerzielle Software durch die Infrastruktur oder Hardware eingeschränkt, auf der sie ausgeführt wird. Wenn die Software beispielsweise nur lokal ausgeführt werden kann, muss Ihr Unternehmen teure Rechenzentren und Infrastrukturen verwalten (z. B. Netzwerke, Speicher, Server, Stromversorgung und HVAC).

Moderne Anwendungen und Dienste werden häufig mit Open-Source-Software erstellt, die mehrere Vorteile bietet:

• Erweiterbarkeit und Portabilität: Sie können Dienste überall ausführen.
• Support: Gut etablierte Open-Source-Technologien wie Kubernetes und Docker haben starke Communities (zusammengesetzt aus vielen Unternehmen), die Funktionen erstellen, die nicht an ein Unternehmen gebunden sind. Dieser Open-Source-Ansatz führt zu einem insgesamt größeren Funktionsumfang für das Produkt. Je mehr Sie eine Open-Source-Technologie wie Kubernetes anwenden, desto leistungsfähiger wird Ihr Funktionsumfang im Vergleich zu nahezu allen kommerziellen Äquivalenten.
• Flexibilität: Bei diesem Modell ist Ihr Unternehmen nicht mehr von einem einzelnen Anbieter Ihrer Anwendungsplattform oder Infrastruktur abhängig. Mit offenen Standards können Sie Anwendungs- und Infrastrukturentscheidungen anhand der Kunden- und Geschäftsanforderungen treffen.

Die moderne Plattform

Moderne Anwendungen benötigen eine moderne Plattform. Die moderne Plattform muss mehrere Anforderungen erfüllen.

Schnelle, zuverlässige und sichere Einführung von Features

Moderne Plattformen müssen die schnelle, zuverlässige und sichere Einführung neuer Features unterstützen.

• Schnell: Diese Anforderung erfordert eine ausreichende Automatisierung zur Bereitstellung von Diensten und neuen Features. Durch Automatisierung wird weniger menschliche Arbeit benötigt und Fehler werden ausgeräumt. All dies erhöht die Bereitstellungsgeschwindigkeit.
• Zuverlässig: Auf der Plattform müssen Teams Funktionen in regelmäßigen Abständen freigeben oder Features auf ihren ursprünglichen Zustand zurücksetzen können, falls sie nicht funktionieren.
• Sicher: Die Plattform muss detaillierte Zugriffskontrollen unterstützen. Nur autorisierte Operatoren sollten auf Dienste zugreifen oder Funktionen und Dienste auf der Plattform bereitstellen können.

Mit Priorität auf Diensten

Moderne Anwendungen werden mit Blick auf Dienste und nicht auf die Infrastruktur entworfen, entwickelt und betrieben. Diese Priorität der Dienste hängt von Plattformen ab, die gegenüber Infrastrukturausfällen widerstandsfähig sind. Moderne Plattformen verfügen über integrierte Funktionen, die Dienste (und die Plattform selbst) nach Hardware- und Softwarefehlern wiederherstellen.

Hybrid- und Multi-Cloud-Ansatz mit einheitlicher Steuerungsebene

Im Zuge des digitalen Wandels wechseln viele Unternehmen zu einer Multi-Cloud- oder Hybrid-Cloud-Strategie für ihr Dienstportfolio. Möglicherweise können Sie bestimmte Anwendungen nicht aus lokalen Rechenzentren in die öffentliche Cloud verschieben, z. B. aus gesetzlichen, Compliance- oder Sicherheitsgründen, aber Sie möchten die Cloud dennoch für andere Dienste nutzen. Moderne Plattformen können in mehreren Umgebungen ausgeführt werden (und tun dies auch oft), z. B. in lokalen Rechenzentren, privaten Clouds oder einer oder mehreren öffentlichen Clouds. Bei der Ausführung in verschiedenen Infrastrukturen müssen moderne Plattformen den Entwicklern und Operatoren zur Erhöhung der Betriebseffizienz eine einheitliche, konsistente Steuerungsebene bereitstellen.

Alles als deklarativer Code

Legacy-Plattformen (wie VMs) sind von Natur aus unerlässlich. Operatoren erstellen häufig Ressourcen und stellen Skripte und Konfigurationen bereit, die zur Laufzeit der Anwendung ausgeführt werden. Wenn Operatoren eine Anwendung ändern, nehmen sie die Änderung direkt an der VM vor, auf der die Anwendung ausgeführt wird. Dieser Prozess kann Konfigurationsabweichungen verursachen, was bedeutet, dass zu keinem Zeitpunkt eine Garantie dafür besteht, dass sich die Anwendung und die Plattform im vorgesehenen Zustand befinden. In einer solchen Umgebung können die Fehlersuche und die Behebung von Ausfällen schwierig sein.

Moderne Plattformen sind deklarative Systeme, in denen alle Ressourcen als Code definiert werden – auch bekannt als Infrastruktur als Code (IAC). Infrastruktur, Dienste, Bereitstellungen, Sicherheit und Richtlinien werden in Ressourcendokumenten kodifiziert, die den vorgesehenen Zustand der Plattform festlegen. Dieser deklarative Ansatz ermöglicht es Operatoren, ihre Dienste, Sicherheit und Richtlinien über eine einheitliche Sprache zu definieren. Da es sich bei diesen Ressourcen um Code handelt, können sie in einem Code-Repository gespeichert werden und genauso wie Codeanwendungen ausgeführt werden. Wenn sich der Zustand der Plattform in einem Git-Repository (zusammen mit dem Verlauf aller Commits für jede Zustandsänderung) befindet, ist es einfacher, einen früheren Zustand wiederherzustellen, falls ein Systemausfall oder eine Katastrophe auftreten.

Die Anthos-Plattform

Anthos ist die moderne Anwendungsplattform von Google Cloud. Mit der offenen, Hybrid-Multi-Cloud-Plattform von Anthos können Sie Ihre vorhandenen Anwendungen modernisieren, neue erstellen und sie überall sicher ausführen. Anthos basiert auf Open-Source-Technologien, die von Google federführend entwickelt wurden, darunter Kubernetes, Istio und Knative. Diese Technologien helfen Ihnen, Konsistenz zwischen lokalen und Cloud-Umgebungen zu erreichen und die Anwendungsentwicklung zu beschleunigen.

Im folgenden Diagramm sind die verschiedenen Komponenten von Anthos und ihre Interaktion in einer typischen Unternehmensumgebung dargestellt.

In den folgenden Abschnitten werden die wichtigsten Komponenten von Anthos kurz beschrieben.

Anthos-Cluster: Containerorchestrierung

Die primäre Rechenumgebung für Anthos basiert auf Anthos-Clustern, um Kubernetes-Installationen in Umgebungen zu verwalten, in denen Sie Ihre Anwendungen bereitstellen möchten. Diese Angebote bündeln vorgelagerte Kubernetes-Releases, sodass Sie konforme Kubernetes-Cluster erstellen, skalieren und aktualisieren können.

Kubernetes besteht aus zwei Hauptteilen: der Steuerebene und den Knotenkomponenten. Wenn Sie GKE verwenden, hostet Google Cloud die Steuerungsebene. Der Kubernetes API-Server ist dann die einzige Komponente der Steuerungsebene, auf die Kunden zugreifen können. GKE verwaltet die Knotenkomponenten im Kundenprojekt mithilfe von Instanzen in Compute Engine. Wenn Sie Anthos-Cluster verwenden, werden alle Komponenten in der lokalen Virtualisierungsumgebung des Kunden gehostet.

Wenn Kubernetes installiert ist und ausgeführt wird, haben Sie Zugriff auf eine gemeinsame Orchestrierungsschicht, die die Bereitstellung, Konfiguration, Aktualisierung und Skalierung von Anwendungen verwaltet.

Anthos Config Management: Richtlinienverwaltung

Mit Anthos Config Management können Sie einzelne Cluster, mehrmandantenfähige Cluster und mehrmandantenfähige Kubernetes-Bereitstellungen mithilfe von Dateien, die als Konfigurationen bezeichnet werden, verwalten. Sie speichern Konfigurationen in einem Git-Repository.

Einige Konfigurationen sind Kubernetes-Objektmanifeste. Andere Konfigurationen sind keine Objektmanifeste, stellen jedoch Informationen bereit, die Anthos Config Management benötigt. Sie können Konfigurationen in YAML oder JSON schreiben. Anthos Config Management sucht nach Aktualisierungen dieser Dateien und wendet Änderungen automatisch auf alle relevanten Cluster an.

Mit einem Configuration-as-code-Ansatz können Sie die Konfiguration Ihrer Anthos-Cluster mit den gleichen Grundsätzen verwalten, die Sie möglicherweise bereits für die Verwaltung Ihrer bereitgestellten Anwendungen in Kubernetes verwenden.

Anthos Service Mesh: Dienstverwaltung

Anthos Service Mesh ist ein Istio-kompatibles Framework, mit dem Sie Dienste, die auf Anthos-Clustern ausgeführt werden, verbinden, überwachen und sichern können. Mit Anthos Service Mesh können Sie ein Netzwerk aus bereitgestellten Diensten wie Load-Balancing, Dienst-zu-Dienst-Authentifizierung und Monitoring erstellen, ohne Änderungen am Dienstcode vorzunehmen.

Anthos Service Mesh fügt automatisch einen Sidecar-Proxy für jeden Pod Ihrer Anwendung ein. Ein Pod ist die grundlegende Ausführungseinheit einer Kubernetes-Anwendung. Ein Pod umschließt den Container einer Anwendung (oder in einigen Fällen auch mehrere Container). In Anthos Service Mesh enthält jeder Pod zwei Container: den Anwendungscontainer und einen Envoy-Proxy-Container (auch als Sidecar-Proxy bekannt). Der Sidecar-Proxy fängt den gesamten Netzwerkverkehr zu und von den Pods ab. Anthos Service Mesh konfiguriert außerdem ein Ingress-Gateway, um eingehenden Traffic im Mesh-Netzwerk zu verwalten. Mit Open-Source-APIs für Istio können Sie Richtlinien konfigurieren, die für Sidecars und Gateways erzwungen werden.

Der Weg zur Modernisierung

Google Cloud bietet einen präskriptiven Prozess, um Ihre Java-Anwendungen aus einem monolithischen Zustand in Mikrodienste zu überführen. Sie können die folgenden Schritte in dem Tempo ausführen, das Ihren geschäftlichen Anforderungen und Bedürfnissen am besten entspricht:

1. Bewegen Sie geeignete Anwendungen von der Ausführung in VMs weg und hin auf die Ausführung in Containern. Sie müssen dafür keinen Code neu schreiben.
2. Stellen Sie containerisierte Anwendungen mithilfe der modernen CI/CD-Verfahren auf der Anthos-Plattform bereit. Einige Anwendungen sind möglicherweise keine guten Kandidaten für die Containerisierung und verbleiben gegebenenfalls in VMs.
3. Refaktorieren Sie Anwendungen im Laufe der Zeit im Rahmen von OSS-Anwendungsstacks, modernen Frameworks und Mikrodiensten.

Das folgende Flussdiagramm veranschaulicht diesen Weg:

Jeder dieser wichtigen Schritte wird im nächsten Abschnitt erläutert.

Schritte zur Modernisierung

In den folgenden Abschnitten werden die einzelnen Schritte zur Modernisierung beschrieben. Außerdem wird dargelegt, wie hilfreich Anthos und Migrate for Container in jeder Phase sind.

Schritt 1: Java-Anwendungen containerisieren

Bei diesem Modernisierungsschritt containerisieren Sie geeignete Java-Anwendungen, die derzeit als VMs ausgeführt werden.

Containerisierung ist ein Prozess, der Anwendungscode zusammen mit allen Abhängigkeiten und Bibliotheken der Betriebsumgebung verpackt. Sie können mehrere Container auf einem einzigen Host ausführen, jeder mit seinen eigenen isolierten, eigenständigen Anwendungsumgebungen. Container sind einfache, portierbare und effiziente Alternativen zu VMs.

In der Regel erstellen und verpacken Sie Java-Anwendungen als JAR-Dateien mit Tools wie maven oder gradle. Dann führen Sie die Binärdateien auf VMs oder auf Bare-Metal-Servern aus.

Sie haben zwei Möglichkeiten, eine Java-Anwendung in Container zu verlagern:

1. Sie können die Anwendung mit Containern migrieren und modernisieren.
2. Sie können Tools zur Systemintegration verwenden, um Container zu erstellen.

Verbesserungen und Modernisierung mit Migrate to Containers

Mit Migrate for Container können Sie Anwendungen von VMs direkt zu Containerartefakten migrieren (z. B. einem Dockerfile oder Kubernetes-Ressourcenmanifesten). Anschließend stellen Sie die Container für Anthos (in GKE und Anthos clusters on VMware) bereit.

Mit Migrate to Containers migrieren

So migrieren Sie Anwendungen mit Migrate zu Containern:

1. Geeignete Kandidaten für die Migration ermitteln: In diesem Schritt entscheiden Sie, welche Anwendungen für die Migration geeignet sind. Zwei Arten von Anwendungen eignen sich gut für die Migration:
   • Anwendungen, auf deren Quellcode nicht zugegriffen werden kann: Möglicherweise sind die Entwickler nicht mehr beim Unternehmen angestellt und die Codebasis wird nicht mehr unterstützt. Anstatt diese Anwendungen als VMs zu verwalten, können Sie den vereinfachten Containerisierungsprozess in Migrate to Container verwenden, um diese Anwendungen nach Anthos zu verschieben.
   • Anwendungen, die weiter unterhalten, aber nicht weiter entwickelt werden: Einige Anwendungen werden möglicherweise nicht aktiv weiter entwickelt. Unternehmen benötigen sie aber noch aufgrund von Abhängigkeiten in anderen Diensten. Migration to Container vereinfacht den Modernisierungsprozess der Plattform, die diese Anwendungen unterstützt.
2. Zu Anthos migrieren: Nachdem Sie geeignete Kandidaten für die Migration ermittelt haben, verwenden Sie Migrate to Container, um VMs in Containerartefakte umzuwandeln, die mithilfe moderner CI/CD-Verfahren in Anthos bereitgestellt werden können (siehe den nächsten Abschnitt). Migrate to Container hilft auch beim Verschieben von Daten und Zustand für die Anwendungen.

Migration to Containers und anspruchsvolle Migrationen

Die Anzahl von Anwendungen, die Unternehmen verwalten, kann manchmal in die Tausende gehen. Die Anzahl von zu verschiebenden Anwendungen oder die Komplexität der Containerisierung hindern Unternehmen möglicherweise daran, wichtige Cloud-Initiativen voranzutreiben. Dadurch können Unternehmen Geschäftsmöglichkeiten und die Vorteile erstklassiger öffentlicher Cloud-Dienste verpassen. Bei diesen Diensten kann es sich um Daten- und Analysedienste wie BigQuery, um Anwendungen der künstlichen Intelligenz wie AutoML oder um Anwendungen des maschinellen Lernens (ML) wie die vortrainierten APIs von Google Cloud handeln.

Migrate to Container kann Ihnen auf folgende Arten bei den Herausforderungen und der Komplexität Ihres Anwendungsportfolios helfen:

• Umfangreiche Anwendungsmigrationen durchführen: Mit Migrate to Container können Sie zahlreiche Anwendungen modernisieren und gleichzeitig zahlreiche Anwendungen zu Anthos bewegen, ohne Ihren Entwicklern und Operatoren technische Kosten zu verursachen.
• Vereinfachung der Containerisierung: In Kombination mit einer großen Anzahl von Anwendungen kann die Containerisierung komplex sein und Unternehmen haben möglicherweise nicht das nötige Know-how oder die Ressourcen zur Unterstützung umfangreicher Modernisierungsmaßnahmen. In solchen Fällen bietet Migrate to Container einen vereinfachten und effizienten Weg zu Anthos und zur Modernisierung.

Weitere Informationen finden Sie in der Dokumentation zu Migrate to Container.

Weitere Tools für die Containerisierung

Docker ist eine weitverbreitete Plattform zum Erstellen von Container-Images. Ein Dockerfile ist ein Textdokument, das alle Befehle enthält, die Sie in der Befehlszeile aufrufen können, um ein Image zusammenzustellen. Erstellen Sie Ihre Binärdateien (JAR-Dateien) und packen Sie sie in einem Dockerfile, um einen Docker-Container anzulegen. Nachdem Sie das Dockerfile erstellt haben, können Sie es in einer CI/CD-Pipeline verwenden. Das folgende Diagramm veranschaulicht den Workflow, der ein Dockerfile verwendet.

Schritt 2: Anwendungen mit modernen CI/CD in Anthos bereitstellen

In diesem Modernisierungsschritt stellen Sie containerisierte Java-Anwendungen für Anthos mithilfe moderner Softwarebereitstellungsverfahren bereit.

Anwendungen erfordern eine gut durchdachte, automatisierte, wiederholbare und zuverlässige Methode zum Erstellen, Testen und Bereitstellen für die Kunden. Da verschiedene Entwicklungsteams ständig neue Funktionen hinzufügen, erstellen, testen und implementieren sie häufig containerisierte Anwendungen unter Verwendung von CI/CD.

Vorteile moderner Softwarebereitstellungsverfahren

Mit der modernen CI/CD- oder Softwarebereitstellungsplattform von Anthos können Sie Folgendes erreichen:

• Best Practices für die Bereitstellung von Anwendungen erstellen und aktualisieren.
• Neue Anwendungen durch Starter- (oder Boilerplate)-Projekte einbinden.
• Anwendungen entwickeln und weiterentwickeln, ohne die Entwicklung anderer Anwendungen zu beeinträchtigen.
• Richtlinien nahtlos auf der gesamten Plattform implementieren und verteilen.
• GitOps für die Bereitstellung und zur verbesserten Versionsverwaltung und Änderungsverfolgung verwenden.

Softwarebereitstellungsplattform mit Anthos

Die Komponenten im folgenden Diagramm bilden eine vollständige Plattform zur Softwarebereitstellung, die auf der Anthos-Plattform verfügbar ist.

Jede Komponente stellt Funktionen für das System und die Anwendungen bereit, die auf der Plattform ausgeführt werden. Mehrere Teams (z. B. Entwicklung, Betrieb und Sicherheit) sind in der Regel für die Aufrechterhaltung der Betriebszeit, Konfiguration, Stabilität und Skalierung der Plattform verantwortlich.

Eine Kernkomponente der Softwarebereitstellungsplattform ist das CI/CD-System. Wenn Sie mit der Definition des CI/CD-Prozesses beginnen, müssen Sie sicherstellen, dass jede Komponente Artefakte, die einer standardisierten Schnittstelle entsprechen, erzeugt oder verbraucht. Wenn Sie eine Standardschnittstelle verwenden, ist es einfacher, die einzelnen Komponenten auszutauschen, sobald eine bessere Implementierung auf den Markt kommt. Sie können zwischen drei standardisierten Schnittstellen wählen, wenn Sie eine Plattform für containerisierte Anwendungen erstellen:

• Git-Repositories
• Docker-Images
• Kubernetes-Manifeste

Mit diesen Schnittstellen können Sie eine wiederverwendbare und flexible CI/CD-Pipeline mit den im folgenden Diagramm dargestellten Abläufen erstellen.

So läuft der Vorgang ab:

1. Entwickler übergeben den Anwendungscode per Commit an das Git-Repository der Anwendung.
2. Das CI-System testet den Code, erstellt ein Docker-Image-Artefakt und speichert das Image in einer Registry.
3. Sobald das Artefakt zur Bereitstellung bereit ist, wird der Konfigurationsdatei der Anwendung ein Verweis auf das Artefakt hinzugefügt.
4. Diese Anwendungskonfiguration wird in einem für Kubernetes lesbaren Format gerendert und in einem Code-Repository gespeichert, das sie in einer Vorproduktionsumgebung einsetzt.
5. Nachdem die Änderungen per Commit im Code-Repository vorgenommen wurden, prüfen Operatoren die Änderungen und führen sie anschließend im Hauptzweig zusammen.
6. Die Anwendung wird für die Produktion bereitgestellt.
7. Wenn Operatoren Änderungen in der gesamten Organisation vornehmen wollen, übergeben sie diese Änderungen per Commit an die Repositorys, was eine Anwendungskonfiguration auslöst. Wenn Entwickler die nächste Änderung bereitstellen, übernehmen die Entwickler die Aktualisierungen der Operatoren.
8. Parallel dazu können Sicherheitsentwickler die Richtlinien, die festlegen, was bereitgestellt werden kann, implementieren und optimieren, indem sie sich auf ihr eigenes Richtlinien-Repository festlegen.

Schritt 3: Lokale VMs für Legacy-Java-Anwendungen optimieren

In diesem Modernisierungsschritt werden Java-Anwendungen als VMs ausgeführt, entweder in lokalen Rechenzentren oder in Google Cloud, wie im folgenden Diagramm dargestellt.

Einige Java-Anwendungen sind aus den folgenden Gründen nicht geeignet für die Containerisierung:

• Einige Ihrer Anwendungen sind geschäftskritisch: Wenn die Migration Ihrer geschäftskritischen Anwendungen in Container zu riskant ist, können Sie dennoch Kostenvorteile bei der Elastizität der Infrastruktur erzielen, indem Sie VMs in die Google Cloud verschieben. In Google Cloud können Sie die Größe der VM anpassen, um die Nutzungskosten zu maximieren.
• Operations-Teams sind mit der Verwaltung einer modernen Plattform nicht vertraut: Einige Betriebsteams sind möglicherweise nicht mit der Verwaltung von VM-Umgebungen vertraut oder haben nicht die erforderlichen Kenntnisse, um auf modernen containerisierten Plattformen zu arbeiten. Ihr Team ist möglicherweise bereits mit der aktuellen Toolchain vertraut, die für die Verwaltung der Konnektivität und der Abhängigkeiten zwischen Legacy-Anwendungen zuständig ist, aber mehr Zeit für die Nutzung einer containerisierten Plattform in der Produktion benötigt.
• Sie müssen die Cloud stufenweise einführen: Sie können beispielsweise mit der Einführung der Cloud beginnen, aber noch nicht zu viele Änderungen gleichzeitig vornehmen. Oder möchten Sie vielleicht Ihre Umgebung (von einem Rechenzentrum zur Cloud) und Plattformen (von der VM zu Containern) nicht gleichzeitig ändern?
• Sie haben ein Budget und operative Einschränkungen: Dies kann Anforderungen an die Hardware/Infrastruktur, Lizenzierung oder die Anwendungsarchitektur umfassen.

Optionen zum Ausführen von VM-Arbeitslasten

Sie können eine oder mehrere der folgenden Optionen auswählen, um Ihre VM-Arbeitslasten effizienter auszuführen:

• Mit Google Cloud: Sie können VMs in Google Cloud auf zwei Arten ausführen:
  • Als Compute Engine-Instanzen: Compute Engine bietet konfigurierbare VMs, die in Rechenzentren von Google ausgeführt werden und Zugriff auf hochleistungsfähige Netzwerkinfrastrukturen und Blockspeicher haben. Diese Option macht es Unternehmen einfacher, lokale Rechenzentren und Server zu verwalten und für Virtualisierungslizenzen zu zahlen (falls zutreffend).
  • Als VMware als Dienst: Die Partnerschaft zwischen VMware und Google Cloud stellt eine offene Plattform dar, um konsistente Bereitstellung, Betrieb und Sicherheit für Cloud-Anwendungen in Multi- und Hybrid-Cloud-Umgebungen zu gewährleisten. Diese Option gilt für Unternehmen, in denen derzeit VMware ausgeführt wird und auf denen VMware-spezifische Funktionen genutzt werden. Unternehmen befinden sich entweder in einer Hybrid-Cloud-Umgebung, in der sie eine konsistente Steuerungsebene für die Verwaltung ihrer VMs (über mehrere Umgebungen hinweg) möchten, oder sie wollen keine eigenen Rechenzentren und Serverinfrastruktur mehr verwalten.
• Lokale Rechenzentren: Es gibt verschiedene Gründe, bestimmte Anwendungen als lokale VMs auszuführen:
  • Überlegungen zu Richtlinien oder Compliance
  • Leistungsanforderungen, bei denen die Nähe der Nutzer oder anderer Anwendungen höher sein muss
  • Aktuelle Investitionen in lokale Hardware

Tools und Lösungen zum Migrieren von VMs

Google Cloud bietet verschiedene Tools und Lösungen, mit denen Sie Ihre VMs zu Google Cloud migrieren können. Mit Migrate to Virtual Machines können Sie Anwendungen innerhalb von Minuten validieren, ausführen und zu Google Cloud migrieren, während Ihre Daten transparent im Hintergrund migriert werden. Informationen zur Migration zu Compute Engine finden Sie unter Migration zu Google Cloud: Einstieg.

Für Migrationen zu VMWare as a Service arbeitet Google mit vertrauenswürdigen Partnern zusammen, um professionelle Dienste bereitzustellen, die Sie bei Ihren VMware-Migrationen zu Google Cloud unterstützen.

Schritt 4: Anwendungen in Mikrodienste umwandeln

Nachdem Sie die Plattform modernisiert haben, können Sie sich auf die Modernisierung von Anwendungen konzentrieren, die auf der Plattform ausgeführt werden. In dieser Phase nehmen Sie Anwendungen auf, die auf der Anthos-Plattform ausgeführt werden, und refaktorieren sie in Mikrodienste.

Möglicherweise haben Sie einige Anwendungen, die in Containern immer noch als monolithische Anwendungen ausgeführt werden. Dies stellt jedoch kein Problem dar. Eine Voraussetzung für die Modernisierung von Anwendungen ist die Migration Ihrer Anwendungen auf eine moderne Plattform wie Anthos. Die Modernisierung Ihrer Anwendungen in Mikrodienste kann nach der Migration im Laufe der Zeit erfolgen.

Durch den Wechsel zu Anthos können sich Entwickler und Operatoren mit neuen Möglichkeiten der Anwendungs- und Plattformverwaltung vertraut werden. Entwickler gewöhnen sich daran, Code schneller zusammenzuführen und häufig zu testen, während sich die Operatoren mit der modernen Art und Weise vertraut machen, Software zu erstellen, zu testen und an ihre Kunden auszuliefern.

Bei den Anwendungen, die auf der Anthos-Plattform laufen, können Ihre Geschäftszweige Prioritäten setzen, welche zu Mikrodiensten modernisiert werden sollen. Google und unsere SI-Partner bieten zahlreiche Entwickler- und Bedienertools an, die Unternehmen in diesem Modernisierungsschritt unterstützen. In den folgenden Abschnitten werden diese Ressourcen erläutert.

Spring Google Cloud

Im Rahmen der Refaktorierung können Sie Java-Anwendungen in moderne Java-Frameworks wie Spring Boot portieren. Das Spring Boot and Spring Framework bieten ein umfassendes Programmier- und Konfigurationsmodell für moderne Java-basierte Unternehmensanwendungen. Spring Cloud bietet Tools für Entwickler, mit denen einige gängige Muster in verteilten Systemen schnell erstellt werden können, z. B. Konfigurationsmanager, Diensterkennung, Unterbrechungen, intelligentes Routing, Mikro-Proxy, Kontrollbus, einmalige Tokens, globale Sperren, Bestimmen des Leaders, verteilte Sitzungen und der Cluster-Zustand.

Um die Verwendung von Google Cloud von Spring Boot-Anwendungen zu vereinfachen, enthält das Projekt Spring Google Cloud mehrere Bibliotheken und Funktionen, die die folgenden Google Cloud-Produkte unterstützen:

• Pub/Sub: Spring Integration und Spring Stream
• Cloud Spanner, Datastore und Cloud SQL: Spring Data
• Cloud Logging und Cloud Trace
• Firestore: Spring Data Reactive Repositories
• Cloud Storage: Spring Resource und Spring Integration
• Cloud Vision API: Die Vorlage CloudVisionTemplate
• Identity-Aware Proxy (IAP): Spring Security-Identitätsextraktion aus IAP-Headern
• BigQuery: Spring Integration

Entwicklertools

Google Cloud bietet Tools, mit denen Sie moderne, containerisierte Java-Anwendungen erstellen können. Zu diesen Tools gehören unter anderem:

• Cloud Code: Cloud Code bietet IDE-Unterstützung für den gesamten Entwicklungszyklus von Kubernetes-Anwendungen, vom Erstellen eines Clusters für Entwicklung und Tests bis hin zum Ausführen einer abgeschlossenen Anwendung in der Produktion. Hier finden Sie einsatzbereite Beispiele, sofort einsatzfähige Konfigurations-Snippets und eine maßgeschneiderte Fehlerbehebung, mit der die Entwicklung mit Kubernetes vereinfacht wird. Cloud Code umfasst eine optimierte Google Kubernetes Engine (GKE), die das Erstellen von in Google Cloud gehosteten Clustern vereinfacht und eine bessere Integration mit Google Cloud-Tools wie Cloud Source Repositories, Cloud Storage und einer Vielzahl von Cloud-Bibliotheken ermöglicht. Sie können Cloud Code entweder mit VS Code oder IntelliJ verwenden.
• Artifact Registry: Artifact Registry bietet einen zentralen Ort zum Speichern von Artefakten und zum Erstellen von Abhängigkeiten als Teil einer integrierten Google Cloud-Umgebung. Artifact Registry bietet einen zentralen Speicherort für die Verwaltung von Paketen, Bibliotheken und Docker-Container-Images. Sie können diese Artefakte (Pakete und Container-Images) in einer modernen CI/CD-Pipeline verwenden, die weiter oben in diesem Dokument beschrieben wird.

• Tools wie Jib und Buildpacks erstellen: Mit Jib und Buildpacks können Sie Container mit bereits vorhandenen Java-Tools wie Maven oder Gradle erstellen. Ohne solche Build-Tools müssen Sie das Dockerfile manuell erstellen und testen. Dieser manuelle Ansatz erfordert einen Host, auf dem der Docker-Daemon für die Erstellung und Ausführung der Container läuft. Dieser Prozess umfasst einige weitere Schritte und kann für Entwickler monoton sein, die ihren Code so schnell und reibungslos wie möglich in die Produktion übertragen möchten. In einem einzigen Build-Schritt orchestriert Jib den Build der Binärdatei, erstellt das Container-Image und schiebt das Image in eine Container-Registry. Jib verwendet Build-Tools, die Entwicklern bereits vertraut sind. Dadurch wird ihre Produktivität erhöht. Nachdem Sie den Java-Container in die Registry verschoben haben, können Sie ihn über eine CI/CD-Pipeline bereitstellen. Das folgende Diagramm zeigt diesen gesamten Ablauf für Buildpack oder Jib.

  

Re-Plattformierung für Open-Source-Anwendungsserver

Für einige Anwendungen erfordert die Refaktorierung von Java-Anwendungen auch die Re-Plattformierung von Java-Anwendungsservern. Um die Lizenzkosten zu senken, werden Java-Anwendungen, die auf kommerziellen Anwendungsserver-Plattformen (z. B. WebSphere oder WebLogic) laufen, auf Open-Source-Komponenten (z. B. JBoss oder Tomcat) umgestellt.

Legacy-Java-Anwendungsarchitektur

Legacy-Java-Anwendungen nutzen im Allgemeinen eine drei- oder vierstufige JEE-Architektur. Die JEE-Architektur unterstützt die komponentenbasierte Entwicklung von mehrstufigen Unternehmensanwendungen. Das folgende Diagramm zeigt die Stufen, die normalerweise in einem JEE-Anwendungssystem enthalten sind.

Es gibt folgende Stufen:

• Präsentationsstufe: In der Präsentationsstufe bieten Webkomponenten wie Servlets und JavaServer-Seiten (JSP oder JSF) oder eigenständige Java-Anwendungen eine dynamische Schnittstelle für die Mittelstufe.
• Anwendungs- oder Mittelstufe: Auf der Anwendungs-oder in der Mittelstufe kapseln Enterprise Java Beans und Webdienste wiederverwendbare, verteilbare Geschäftslogik für die Anwendung ab. Diese Serverstufen-Komponenten sind auf einem JEE-Anwendungsserver enthalten, der die Plattform für diese Komponenten zur Verfügung stellt, damit Aktionen ausgeführt und Daten gespeichert werden können.
• Unternehmensdatenstufe: Auf der Datenstufe werden die Unternehmensdaten gespeichert und beibehalten, in der Regel in einer relationalen Datenbank.

Diese verschiedenen Stufen werden in der Regel in virtualisierten Umgebungen bereitgestellt und sind auf Anwendungsserver angewiesen. Dies kann zu hohen Lizenzkosten führen.

Vorteile der Umstellung auf offene Standards

Der Wechsel zu offenen Standards reduziert die Lizenzkosten und bietet die Vorteile cloudbasierter Bereitstellungsmethoden und einer cloudbasierten Plattform.

Tools und Lösungen

Google Cloud Partner kooperieren mit verschiedenen Systemintegratoren (SIs), die bewährte Ansätze und Tools für die Re-Plattformierung von JEE-Anwendungen und die Einführung von OSS-Technologien bieten.

Der Prozess der Re-Plattformierung beginnt mit der Bewertung Ihrer alten Java-Anwendungen. Bei der Prüfung werden zahlreiche Faktoren berücksichtigt, darunter die Komplexität der Anwendung, ihre Funktionalität, Nutzungsmesswerte und geschäftliche Relevanz. Diese Bewertung liefert eine priorisierte Liste der Anwendungskandidaten, die reaktiviert werden sollen. Diese Bewertung führt zu einer Prioritätenliste von Bewerbungskandidaten, die neu zu platzieren sind. SIs bieten Entwickler- und DevOps-Tools, die Unternehmen dabei unterstützen, alle Abhängigkeiten kommerzieller Anwendungsserver aus dem Quellcode zu entfernen. Tests und Ausgangskriterien werden für jede Anwendung in Betracht gezogen, bevor zur nächsten Stufe (Bereitstellung) übergegangen wird. Diese Stufe gilt für Anwendungen, bei denen auf den Quellcode zugegriffen werden kann und bei denen die Open-Source-Variante der Plattform vorhanden ist.

Best Practices für die Refaktorierung

In den folgenden beiden Google Cloud-Artikeln werden die Vorteile sowie ein Prozess zur Umstellung von monolithischen Anwendungen auf Mikrodienste erläutert:

• Von einer monolithischen Anwendung zu Mikrodiensten in Google Kubernetes Engine migrieren
• Migration mit Istio-Mesh-Erweiterung unterstützen

Mikrodienste über Anthos Service Mesh mit VMs verbinden

Unternehmen haben eine Vielzahl von Anwendungen. Fast alle Unternehmen haben Anwendungen, die auf einer der folgenden Plattformen ausgeführt werden:

• Anthos-Plattform zum Ausführen von Mikrodiensten in Containern
• Eine Virtualisierungsplattform zum Ausführen von VMs

Auf diesen beiden Plattformen ausgeführte Dienste sind in der Regel voneinander abhängig und müssen miteinander kommunizieren können. Für Mikrodienste, die auf der Anthos-Plattform ausgeführt werden, bietet Anthos Service Mesh eine sicherheitserhöhte Verbindung zu VMs, die außerhalb von Anthos in einer virtualisierten Umgebung ausgeführt werden.

Vorteile von Anthos Service Mesh mit VMs

• VMs können das gleiche deklarative Richtlinien- und Sicherheitsverwaltungs-Framework von Kubernetes nutzen wie Container und Mikrodienste, die in Anthos ausgeführt werden. Mit diesem Ansatz können Operatoren dafür sorgen, dass eine sicherheitserhöhte (mTLS), authentifizierte Verbindung zwischen Containern, die auf Anthos ausgeführt werden, und VMs, die auf einer anderen Umgebung ausgeführt werden, funktioniert.
• Auf vorhandenen VMs ist keine erneute Codierung erforderlich, damit diese als Dienste auf der Anthos-Plattform angezeigt werden. Wenn die VM als Dienst angezeigt wird, betrachtet Anthos sie wie einen in GKE ausgeführten Dienst.
• Operatoren erhalten eine bessere Beobachtbarkeit (Messwerte) für VMs ohne Instrumentierung. Die Messwerte werden als in Anthos ausgeführter Dienst dargestellt.

VMs für Containerisierung

Im Laufe der Zeit können Sie Ihre bestehenden refaktorierten VMs in Container verschieben. Dieser Ansatz ermöglicht es Ihnen, die Modernisierung in Ihrem eigenen Tempo voranzutreiben und die zu modernisierenden Anwendungen zu priorisieren.

Nächste Schritte

• Checkliste für die Einrichtung von Google Cloud
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center