Anwendungsmodernisierung

„Multicloud Mindset“: Gedanken zu Open Source und Sicherheit in der Multicloud-Welt

Wed, 19 Apr 2023 09:00:00 +0000

Nie gab es einen besseren Zeitpunkt, um über Multicloud zu diskutieren. Folgerichtig wurde eigens zu diesem Zweck die „Multicloud Mindset“-Serie von Google Cloud auf Twitter Spaces ins Leben gerufen. Die Serie setzt sich im Zwei-Wochen-Rhythmus fort und bietet Live-Gespräche mit Top-Expert*innen zu den heißesten Multicloud-Themen. Stellen Sie Ihre persönlichen Fragen in der 15-minütigen Q&A-Session, oder hören Sie die Folgen später offline – sie sind bis zu 30 Tage nach dem Live-Termin verfügbar.

Sollten Sie die letzten Folgen verpasst haben, entdecken Sie in der Blog-Einführung zur Serie, was Ihnen entgangen ist. Befassen wir uns nun mit den jüngsten Inhalten: Open Source und neue Sicherheitsfragen in Multicloud-Umgebungen.

Folge 5: Open Source und Multicloud treffen zusammen

Open Source ist schon sehr lange fester Bestandteil der Computertechnik: Sie war es bereits, bevor Technologiezentren wie das Silicon Valley entstanden. Open-Source-Projekte haben uns weltweit erfolgreiche Softwarelösungen beschert, zum Beispiel Mozilla Firefox oder das Betriebssystem Linux.

In der fünften Folge haben wir uns mit Mike Coleman, Cloud Developer Advocate bei Google Cloud, zusammengesetzt und einen näheren Blick auf die Geschichte der Open-Source-Technologien geworfen – ihre Rolle in einer Multicloud-Welt, und die Sicht von Entwickler*innen auf den Einsatz von Open Source in ihrer Arbeit.

Seine Berechtigung schöpft das Konzept Multicloud aus der Möglichkeit, Workloads in mehreren Clouds zu betreiben und für bestimmte Workload-Anteile den jeweils besten Anbieter auszuwählen. Mit Open-Source-Technologien und -Sprachen können Unternehmen alle Tools nutzen, die sie brauchen, ohne sich von einem bestimmten Cloud-Anbieter abhängig zu machen.

„Vielleicht ziehen Sie einen Umgebungswechsel in Erwägung – von Cloud zu Cloud oder vom Entwickler-Desktop zum endgültigen Ziel, möglicherweise auch zwischen Ihrem Rechenzentrum und einer Cloud. Das ist mit der Open-Source-Software kein Problem ... und Multicloud ist lediglich eine Erweiterung davon. Das Konzept, dieselbe Software zu nutzen, egal wo ich gerade bin, darum geht es.“ — Mike Coleman, Cloud Developer Advocate bei Google Cloud

Wenn Sie wissen möchten, wie Multicloud und Open Source aus Sicht der Entwicklung beurteilt werden und wie sie sich auf Trends der digitalen Transformation auswirken, sollten Sie sich diese Folge nicht entgehen lassen.

Verfolgen Sie das ganze Gespräch auf Twitter Spaces.

Folge 6: Neue Herausforderungen für die Multicloud-Sicherheit

Sicherheitsverantwortliche und -architekt*innen setzen immer seltener auf traditionelle Sicherheitsmodelle – diese werden Multicloud-Umgebungen kaum noch gerecht. Darüber sprachen wir in der sechsten Serienfolge mit Dr. Anton Chuvakin, Security Advisor im Office of the CISO bei Google Cloud.

Immer mehr Unternehmen folgen Multicloud-Ansätzen. Dementsprechend ist die Gewährleistung der Sicherheit in diesen komplexen Umgebungen eine zentrale Frage, genauso wie die zunehmende Belastung der SecOps-Teams. Wie Dr. Chuvakin feststellte, stehen traditioneller aufgestellte Teams bei der Cloud vor vielfältigen Herausforderungen: von der Art der Telemetrie und Protokolle bis hin zu fehlender Klarheit bei der praktischen Erkennung von Einsatzbereichen. Diese Herausforderungen verschärfen sich, wenn mehrere Clouds zu betrachten sind, denn die nötige Vorgehensweise kann sich von Anbieter zu Anbieter grundsätzlich unterscheiden.

„Wenn Sie sich für Multicloud entscheiden, müssen Sie sich mit der Public Cloud und ihrer Funktionsweise besser auskennen, als wenn Sie nur einen Anbieter nutzen. Wer drei Autos reparieren will, muss erst einmal in der Lage sein, überhaupt ein Auto zu reparieren. Multicloud erfordert mehr Cloud-Wissen, nicht weniger. Und im Public Cloud-Bereich braucht es eben ein paar Superkräfte mehr: Man kann nicht nur einen Provider durchdenken und sich dann zufrieden zurücklehnen.“ — Dr. Anton Chuvakin, Security Advisor, Office of the CISO bei Google Cloud

Im Gespräch formulierte er drei Tipps für die Sicherheit in Multicloud-Umgebungen:

Lernen Sie mehr über die Cloud, nicht weniger, wenn Sie auf Multicloud setzen. Multicloud setzt mehr Cloud-Know-how voraus: Sie können sich nicht nur mit einem Provider befassen und dann zurücklehnen. Sie müssen die Unterschiede zwischen den Clouds verstehen, wenn Sie mehrere Cloud-Umgebungen sicher machen wollen.
Konzentrieren Sie sich darauf, das Cloud-Identitätsmanagement zu erlernen und wie es im Vergleich zu Ihren herkömmlichen ID-Verwaltungsdiensten funktioniert. Nehmen Sie sich Ihre Clouds sukzessive vor und erfassen Sie zunächst die Unterschiede und Gemeinsamkeiten.
Untersuchen Sie, wo sich die Bedrohungsbereiche in Cloud-Umgebungen ändern, wenn Sie die Maßnahmen zur Erkennung und Reaktion planen. Sie wollen schließlich wissen, ob mit Ihrer Erkennungsmethodik alle Clouds abgedeckt sind.

Wenn Ihr Unternehmen auf Multicloud setzt, sollten Sie sich diese Folge auf jeden Fall anhören. Sie werden einiges über Cloud-Sicherheit, die wichtigsten Überlegungen und Herausforderungen für Sicherheitsteams sowie über Best Practices für Multicloud-Sicherheit erfahren.

In diesem Blog informieren wir Sie jeden Monat über die neuesten Themen und Folgen. Bis zum nächsten Mal!

Sechs Tipps zur Optimierung von API-Management-Kosten mit Apigee

Thu, 02 Mar 2023 05:00:00 +0000

Angesichts der gegenwärtigen Wirtschaftslage ist jedes Unternehmen einem beispiellosen Druck ausgesetzt: Inflation, knappes und teures Fachpersonal sowie gestörte beziehungsweise eingeschränkte globale Lieferketten sind alles Faktoren, die es zu meistern gilt. IT-Führungskräfte stehen vor der schwierigen Aufgabe, ihre Ausgaben zu senken und gleichzeitig die von der Pandemie ausgelöste „Digitalisierungswelle‟ am Laufen zu erhalten. Neue Untersuchungen zeigen, dass Unternehmen aus diesem Grund verstärkt auf die Cloud setzen. Dazu modernisieren sie ihre Infrastruktur und verlagern immer mehr Anwendungen aus On-Premise-Umgebungen in die Cloud. Da APIs entscheidend für die optimale Nutzung von alten wie neuen Systemen sind, hat sich durch diesen Trend auch die Akzeptanz und Nutzung von APIs weiter verstärkt.

Wir bei Google Cloud möchten Sie bei der raschen Einführung von APIs unterstützen und den Nutzen, den Sie aus Ihren API-Programmen ziehen, steigern. Wir haben vor Kurzem ein „Pay as you go“-Preismodell eingeführt, mit dem Sie Ihre Kosten für das API-Management ohne Vorabverpflichtung flexibel gestalten und im Griff behalten können. Sie brauchen hierfür keine Vorabverpflichtung einzugehen. Wenn Sie Leistungen nach dem „Pay as you go“-Preismodell in Anspruch nehmen, wird Ihnen Folgendes in Rechnung gestellt:

Apigee-Gateway-Knoten: Ressource einer Apigee-Umgebung, die API-Traffic verarbeitet. Berechnet wird die Anzahl der verwendeten Knoten pro Minute.
API Analytics: Gesamtzahl der API-Anfragen, die Apigee Analytics pro Monat verarbeitet (API-Anfragen werden unabhängig davon, ob sie erfolgreich sind oder nicht, von der Plattform Apigee Analytics verarbeitet).

Neben diesen primären Kostenfaktoren fallen auch nutzungsabhängige Netzwerkkosten an (zum Beispiel für den Netzzugang).

Wir freuen uns, dass sich immer mehr Kunden für Apigee und unser neues Preismodell entscheiden. Wir möchten deshalb die Gelegenheit ergreifen und Ihnen hier sechs Möglichkeiten vorstellen, wie Sie Ihre Kosten für das API-Management mit Apigee optimieren können. Diese Best Practices sollen Ihnen helfen, Ihre Cloud-Kosten den Bedürfnissen Ihres Unternehmens anzupassen und damit die Kosten zu reduzieren.

#1 Höchstwert für Apigee-Gateway-Knoten festlegen

Apigee Runtime kann automatisch auf bis zu 1.000 Knoten skalieren, und jeder Gateway-Knoten kann bis zu 300 Anfragen pro Sekunde verarbeiten (variiert je nach Richtlinien, Anfrage-/Antwortgrößen, Backend-Latenzen usw.). Wenn Sie mit einer kleinen Lösung beginnen, brauchen Sie wahrscheinlich keine Autoskalierung bis zu einer solch hohen Knotenanzahl. Wenn Sie einen Höchstwert für die Knotenanzahl festlegen, schützen Sie sich also vor übermäßigen Kosten, falls es zu einem unerwarteten Anstieg des Datenverkehrs kommt.

#2 Knoten-Mindestanzahl nicht zu hoch ansetzen

Da der Erfolg jeder modernen Anwendung maßgeblich von ihrer Leistung abhängt, konzentrieren sich die Entwicklungsteams darauf, ihre Anwendung in allen Aspekten optimal zu konfigurieren. Bei einigen Kunden haben wir beobachtet, dass sie eine hohe Knoten-Mindestzahl eingestellt haben, um bei einem unerwarteten Traffic-Anstieg die Latenzen niedrig zu halten. Jeder Apigee-Gateway-Knoten kostet 1,025 $ pro Stunde, so dass sich die Kosten für die Bereitstellung von Überkapazitäten schnell summieren können. Apigee Runtime skaliert sehr aggressiv, um Latenzen zu vermeiden. So haben wir beobachtet, dass eine Skalierung von 2.000 Requests pro Sekunde (RPS) auf 20.000 RPS innerhalb weniger Minuten und ohne Erhöhung der p50/p90-Latenz erfolgt (pXX-Latenz: XX % der Anfragen erhalten Antworten, die gleich dem oder schneller als der pXX-Latenzwert sind). Anstatt willkürlich unnötig hohe Werte einzustellen, um Bedarfsspitzen aufzufangen, empfehlen wir eine Analyse der Nutzung des Apigee-Gateway-Knotens (verfügbar in Cloud Monitoring), um ein passendes Knoten-Minimum zu definieren. Darüber hinaus empfehlen wir, Benachrichtigungen zur Knotennutzung zu konfigurieren, um rechtzeitig auf unerwartete Bedarfsspitzen reagieren zu können.

#3 Manuelle Anpassungen der Knotenanzahl vermeiden

Zur Vermeidung von Latenzzeiten bei einem plötzlichen Anstieg des Datenverkehrs (z. B. vor einem E-Commerce-Ereignis wie dem Black Friday) ist es gängige Praxis, dass Technikteams die Mindest- und Höchstwerte für die Knotenanzahl kurz vor dem anstehenden Ereignis vorübergehend anpassen. Bei einer manuellen Anpassung der Knotenanzahl besteht jedoch die Gefahr, dass hohe Kosten für die Bereitstellung von Überkapazitäten entstehen. Dazu kann es bspw. kommen, wenn Sie vergessen, die Werte für die Knoten wieder herabzusetzen. Wir empfehlen, anstatt manuelle Anpassungen vorzunehmen, geplante Anpassungen mit den Management-APIs von Apigee zu automatisieren. Mit den Management-APIs können Sie die Anpassungen an Apigee-Knoten in die Workflows einbetten, die sowieso schon eingerichtet wurden, um die erwarteten Traffic-Steigerungen zu bewältigen.

#4 API-Traffic am Netzwerk-Edge sichern, um unnötige Gebühren zu vermeiden

Apigee bietet einen umfangreichen Satz an Richtlinien zum Schutz Ihres API-Traffics. Diese Richtlinien werden jedoch zur Laufzeit ausgeführt und die API-Anfragen anhand der Sicherheitsrichtlinien bestätigt oder gefiltert. In jedem Fall werden die API-Anfragen von Apigee Analytics verarbeitet, unabhängig davon, ob sie erfolgreich waren oder nicht. Dadurch entstehen Ihnen auch anteilige Kosten für erfolglose API-Anfragen (im Rahmen des „Pay as you go“-Preismodells für Apigee wird Ihnen die Gesamtzahl der von API Analytics verarbeiteten Requests in Rechnung gestellt).

Eventuell sollten Sie den Einsatz von Sicherheitsrichtlinien am Netzwerk-Edge in Betracht ziehen, um bösartigen Datenverkehr (basierend auf IP, geografischer Region, Inhalt, Signatur usw.) herauszufiltern, noch bevor er den Apigee-Gateway-Knoten erreicht. Es gibt zahlreiche beliebte Lösungen auf dem Google Cloud Marketplace, die zum Blockieren von Bot-Traffic und zum Schutz Ihrer Endpunkte genutzt werden können. Die Lösung Google Cloud WAAP (Web App and API Protection) kombiniert z. B. Apigee, Cloud Armor und reCAPTCHA und bietet einen umfassenden Schutz vor Bedrohungen und Betrug. Da der eingehende Traffic zu Apigee durch Google Cloud Load Balancing überwacht wird, ermöglicht die nahtlose Integration von Apigee und Cloud Armor die Erkennung und Unterbindung von bösartigem Datenverkehr am Edge des Google Cloud-Netzwerks.

#5 Vorhandene Knoten auf mehrere Regionen aufteilen, statt Ressourcen hinzuzufügen

Wenn Nutzer*innen über mehrere Regionen verteilt sind, ist es üblich, zusätzliche Knoten in diesen Regionen bereitzustellen, um eine hohe Verfügbarkeit zu gewährleisten. Doch die Bereitstellung von Knoten ist immer mit zusätzlichen Kosten verbunden. Wenn Sie über mehrere Regionen hinweg skalieren und eine Verfügbarkeit von mehr als 99,9 % benötigen, sollten Sie Regionen zu Ihrer Apigee-Organisation hinzufügen, anstatt die Ressourcen aufzustocken. Wenn Sie bereits mehr als die Mindestanzahl von vier Knoten betreiben, können Sie diese auf mehrere Regionen aufteilen, um die Verfügbarkeit zu erhöhen und gleichzeitig die Kosten zu senken. Wie oben bereits angesprochen, fallen dabei zusätzliche Analytics-Gebühren auf Grundlage der Anzahl der verarbeiteten Anfragen an. Beachten Sie außerdem, dass für jede Umgebung, die in einer Region bereitgestellt wird, mindestens zwei Knoten erforderlich sind.

#6 Das am besten geeignete Apigee-Preismodell wählen

Das „Pay as you go“-Preismodell ist ideal für Kunden, denen Flexibilität und Kostenkontrolle wichtig sind und die ohne Vorabverpflichtungen beginnen oder experimentieren möchten. Wenn Ihr API-Programm (basierend auf der Anzahl der API-Aufrufe oder Gateway-Knoten) eine bestimmte Größe erreicht, könnte ein fester Tarif eine kostengünstigere Alternative für Sie sein. Rechnen Sie mit einer hohen Anzahl an API-Anfragen oder sind vorhersehbare Kosten für Sie wichtig, bietet sich eines der Abos an, die für Apigee verfügbar sind.

Wie Sie Ihre Kosten schätzen und Ihre Nutzung überwachen können

Bevor Sie beginnen, Apigee zu nutzen (aber auch später), können Sie Ihre potenziellen Kosten mit dem Preisrechner berechnen. Sehen Sie sich hier ein paar Beispiele an, die Ihnen helfen, die Kosten in Ihrem konkreten Anwendungsfall abzuschätzen.

Für den Fall, dass Sie das „Pay as you go“-Preismodell bereits nutzen, bietet Apigee verschiedene Tools, mit denen Sie Ihre Nutzung prüfen, Cloud Billing-Benachrichtigungen konfigurieren, Rechnungen schätzen und Unterstützung bei Fragen zu Abrechnungen einholen können.

Nächste Schritte

„Pay as you go“ ist ein neuer, kostengünstiger Weg, um Zugang zu Googles bewährter Apigee API Management-Plattform zu erhalten. Wir gehen davon aus, dass viele Kunden auf dieses neue Preismodell umsteigen und werden daher auch künftig Tipps für die Maximierung des Nutzens in verschiedenen Anwendungsfällen geben. Weitere Informationen zu Apigee oder zum Einstieg in das „Pay as you go“-Preismodell für Apigee finden Sie in der Console.

Migration Ihrer Oracle- und SQL Server-Datenbanken zu Google Cloud

Wed, 08 Feb 2023 04:00:00 +0000

Bevor Cloud Computing unsere Sicht auf Datenbanken und Anwendungen veränderte, waren Oracle- und Microsoft SQL Server-Datenbanken jahrzehntelang eine wichtige Basis für die Architektur von Unternehmensanwendungen. Doch heute werden Sie angesichts der gegenwärtigen Branchentrends und der enormen Möglichkeiten, die die Cloud bietet, wahrscheinlich noch einmal genau überlegen, auf welche Technologie Sie bei der Cloud-Planung setzen.

Im Datenbankbereich gehören zu diesen Trends der Wechsel zu Open-Source-Technologien (insbesondere zu MySQL, PostgreSQL und ihren Derivaten), die Einführung nicht-relationaler Datenbanken, Multi-Cloud- und Hybrid-Cloud-Strategien sowie die Notwendigkeit, global verteilte Anwendungen, die ständig online sind, zu nutzen. Dabei kann jede Anwendung andere Cloud-Anforderungen stellen – ob es sich nun um eine schnelle Lift-and-Shift-Migration, eine umfangreiche Anwendungsmodernisierung oder um eine vollständige Transformation mit einer Cloud-First-Datenbank handelt.

Google Cloud bietet eine Reihe von verwalteten Datenbankdiensten, die Open-Source-, Drittanbieter- und Cloud-First-Datenbanken unterstützen. Anlässlich der Next 2022 haben wir fünf neue Videos veröffentlicht, die sich gezielt an Oracle- und SQL Server-Kunden richten, die sich für eine Lift-and-Shift-Migration in die Cloud interessieren oder sich ganz von Lizenzierungs- und anderen Beschränkungen befreien wollen. Wir hoffen, dass Ihnen diese Videos beim Analysieren Ihrer Möglichkeiten helfen – ob Sie nun zu einer homogenen Migration (Verwendung der bisherigen Datenbank) oder zu einer heterogenen Migration (Wechsel zu einer anderen Datenbank-Engine) tendieren.

Kommen wir nun zu den fünf Videos.

#1 Ausführung von Oracle-basierten Anwendungen in der Google Cloud

Von Jagdeep Singh & Andy Colvin

Der Wechsel in die Cloud kann sich als schwierig erweisen, wenn Ihr Unternehmen auf Anwendungen angewiesen ist, die auf einer Oracle-Datenbank laufen. Anwendungen können z. B. aus Kompatibilitäts-, Lizenzierungs- und Verwaltungsgründen von Oracle abhängig sein. Informieren Sie sich über verschiedene Lösungen von Google Cloud, darunter die „Bare Metal Solution for Oracle“, eine für Oracle-Workloads zertifizierte und optimierte Hardwarelösung, sowie Lösungen von Cloud-Partnern wie VMware und Equinix. Sie erfahren, wie Sie Legacy-Workloads auf Oracle ausführen und gleichzeitig moderne Cloud-Technologien für neuere Workloads einsetzen können.

#2 SQL Server-basierte Anwendungen in Google Cloud ausführen

Von Isabella Lubin

Microsoft SQL Server ist nach wie vor ein weit verbreitetes kommerzielles Datenbankmanagementsystem. Informieren Sie sich darüber, wie Sie SQL Server mit Cloud SQL, einem vollständig verwalteten Datenbankdienst für die Ausführung von MySQL-, PostgreSQL- und SQL Server-Workloads, zuverlässig und sicher ausführen können. Einige der größten Unternehmen der Welt setzen auf Cloud SQL. Mehr als 90 % der 100 größten Google Cloud-Kunden nutzen Cloud SQL. Wir zeigen Ihnen, wie Sie die richtige Datenbank-Instanz auswählen, Ihre Datenbank migrieren, mit Standard-SQL-Server-Tools arbeiten und wie Sie Ihre Datenbank überwachen und auf dem neuesten Stand halten.

#3 Auswahl einer PostgreSQL-Datenbank in der Google Cloud

Von Mohsin Imam

PostgreSQL ist eine branchenführende relationale Datenbank, die für ihre freizügige Open-Source-Lizenzierung, ihre umfangreiche Funktionalität, ihren nachweislich erfolgreichen Einsatz in Unternehmen und eine starke Gemeinschaft von Entwickler*innen und zahlreiche Tools geschätzt wird. Google Cloud bietet drei vollständig verwaltete Datenbanken für PostgreSQL-Nutzer: Cloud SQL, ein intuitiver, vollständig verwalteter Datenbankdienst für Open-Source-PostgreSQL, AlloyDB, ein PostgreSQL-kompatibler Datenbankdienst für Anwendungen, die ein besonders hohes Maß an Skalierbarkeit, Verfügbarkeit und Leistung benötigen, und Cloud Spanner, eine Cloud-First-Datenbank mit unbegrenzter globaler Skalierung, 99,999 % Verfügbarkeit und einer PostgreSQL-Schnittstelle. Sie erfahren, welche Lösung die richtige für Ihre Anwendung ist, wie Sie Ihre Datenbank in die Cloud migrieren und wie die ersten Schritte dafür aussehen.

#4 Wie Sie Ihre Anwendungen mit Google Cloud-Datenbanken migrieren und modernisieren

Von Sandeep Brahmarouthu

Die Migration Ihrer Anwendungen und Datenbanken in die Cloud ist nicht immer ganz einfach. Während einfache Workloads vielleicht nur eine einfache Lift-and-Shift-Migration der Datenbank erfordern, können individuelle Unternehmensanwendungen von umfassenderen Modernisierungs- und Transformationsmaßnahmen profitieren. In diesem Video informieren wir Sie über die verwalteten Datenbankdienste von Google Cloud, unseren Ansatz für eine schrittweise Modernisierung, das Framework und die Programme, die wir für die Datenbankmigration anbieten, und darüber, wie wir Ihnen mit einer unverbindlichen Bewertung den Einstieg erleichtern können.

#5 Erste Schritte mit dem Database Migration Service

Von Shachar Guz & Inna Weiner

Angesichts der steigenden Kosten für die Wartung von Legacy-Datenbanken wird die Migration Ihrer Datenbanken zur Cloud immer attraktiver. Google Cloud kann Ihnen dabei helfen – ob es sich nun um eine einfache Lift-and-Shift-Migration, eine Datenbankmodernisierung auf eine moderne, Open-Source-basierte Alternative oder eine vollständige Transformation von Anwendungen handelt. Sie erfahren, wie der Database Migration Service die Migration mit einer serverlosen, sicheren Plattform, die native Replikationsfunktionen für hochpräzise und zuverlässige Migrationen nutzt, vereinfacht. Es wird gezeigt, wie eine Datenbankmigration weniger komplex, weniger zeitaufwendig und auch risikoärmer sein kann – und wie Sie Ihre Migration in den meisten Fällen in weniger als einer Stunde in die Wege leiten können.

Wir freuen uns auf die Zusammenarbeit mit Ihnen

Welchen Weg Sie bei der Migration zur Cloud auch einschlagen – Sie werden schnell erkennen, dass Google Cloud-Datenbanken skalierbar, zuverlässig, sicher und offen sind. Wir freuen uns darauf, ein neues Zuhause für Ihre Oracle- und SQL Server-basierten Anwendungen zu schaffen.

Beginnen Sie Ihre Cloud-Reise mit einer kostenlosen Testversion von Cloud SQL oder Spanner und gehen Sie anschließend mit dem Database Migration Program den nächsten Schritt zur Google Cloud.

So erschließen Sie Ihre Mainframe-Daten mit Data-First-Digitalisierung

Thu, 04 Aug 2022 04:00:00 +0000

Für viele Unternehmen ist der Mainframe immer noch das Rückgrat der IT. Das bedeutet auch, dass Kunden-, Prozess- und Betriebsdaten vom Mainframe verwaltet werden. Gerne würden sie einen Weg finden, um auf diese Daten zugreifen zu können und sie für Berichte, Big-Data-Analysen oder neue Machine Learning- und KI-Projekte zu nutzen.

Google Cloud unterstützt diese Organisationen dabei, ihre Mainframe-Ressourcen für das Cloud-Zeitalter verfügbar zu machen. Eine Möglichkeit dazu ist, die Mainframe-Anwendungen in die Cloud zu verlegen und so zu modernisieren. In Zusammenarbeit mit Partnern und Kunden haben wir aber einen neuen, agileren Ansatz entwickelt, mit dem sich die Cloud deutlich schneller als bei einer vollständigen Migration für Mainframe-Ressourcen nutzen lässt: Die Data-First-Digitalisierung.

Für ein besseres Verständnis der beiden Ansätze müssen wir zunächst auf den Unterschied zwischen Modernisierung und Digitalisierung eingehen. Bei der Modernisierung wird vom gegenwärtigen Zustand aus in die Zukunft geblickt und dabei Schritte erwogen wie die Migration der Mainframe-Anwendungen durch Rehosting (Emulation), Refaktorierung (automatische Code-Umwandlung), Reengineering – oder gar durch das komplette Ersetzen einer proprietären Anwendung mit einer Standardlösung. Bei der Digitalisierung wird vom angestrebten zukünftigen Zustand ausgegangen und überlegt, welche Schritte nötig sind, um dieses Ziel zu erreichen.

Zum Vergrößern hier klicken

Unser Data-First-Ansatz nutzt ein Mainframe-Digitalisierungs-Framework, bei dem sowohl interne als auch von Partnern bereitgestellte Produkte und Tools zum Einsatz kommen, um die Migration heterogener Datenquellen vom Mainframe in Google Cloud Storage zu ermöglichen. Diese in den Cloud-Speicher bereitgestellten Mainframe-Daten können dann mit Google Cloud-Tools wie BigQuery, KI- und Machine-Learning-Produkten sowie Smart- und Stream-Analyseplattformen integriert und genutzt werden. Das Integrations-Framework deckt sowohl Bulk-Batch-Datenübertragungen als auch die Echtzeit-Datenreplikation (Erfassung von Datenänderungen) ab.

Zum Vergrößern hier klicken

Die Data-First-Digitalisierung basiert auf dem Grundsatz, dass Anwendungen vergänglich, Daten hingegen beständig sind. Anstatt also die Anwendungen selbst zu modernisieren (z. B. mit Ansätzen zur Modernisierung von Legacy-Systemen von Gartner) werden deshalb nur die Daten in die Google Cloud übertragen, sodass Unternehmen direkt neue Geschäftsmodelle, Anwendungsfälle und innovative Möglichkeiten zur Bedienung von Kundinnen und Kunden entwickeln können. Zwei Beispiele dazu:

Smart- und Stream-Analyseplattformen sowie KI-/ML-Engines: Google ist ein Pionier auf dem Gebiet der Extraktion der von diesen Tools benötigten strukturierten und unstrukturierten Rohdaten und ermöglicht es Ihnen, Mainframe-Daten in BigQuery- und KI-/ML-Modellen zu nutzen.

Neue Reporting-Anwendungen: Mit dem Zugriff auf Mainframe-Daten können Sie Google Cloud-Produkte wie Looker und Appsheet verwenden, um umfassendere Reporting-Anwendungen zu entwickeln, die Ihre Mainframe-Reporting-Anwendungen ersetzen und Ihre Transformation insgesamt beschleunigen.

Unserer Erfahrung nach bietet ein Data-First-Digitalisierungsansatz für Ihren Mainframe eine Reihe von Vorteilen:

Schnellere Umsetzung: Da die Data-First-Modernisierung auf vorhandenen Produkten aufbaut, ist der Implementierungs Zyklus deutlich kürzer.
Geringerer Kapitalaufwand: Sie investieren Ihre Zeit in die Integration von Produkten, nicht in die Entwicklung von Anwendungen.
Risiko-Minimierung: Data-First baut auf vorhandenen, bewährten und zuverlässigen Google Cloud-Produkten auf.
Insgesamt schnellere Mainframe-Transformation: Wenn Sie sich bei der Modernisierung statt auf die Anwendung auf die Daten selbst konzentrieren, betrachten Sie Mainframe-Anwendungen als geschäftliche Ressourcen und nicht mehr als Bestand, den es zu wahren gilt. Sie modernisieren also nur die wirklich geschäftskritischen Anwendungen und können viele nicht kritische Anwendungen außer Betrieb nehmen. Das beschleunigt Ihre Transformation.

Data-First-Digitalisierung ist ein neuer Ansatz; die ersten Erfolge unserer Kunden sind vielversprechend. Wir werden an dieser Stelle auch weiter neue Einblicke, Referenzarchitekturen und technische Whitepaper zum Thema Data-First veröffentlichen. Wenn dieser Ansatz für Sie von Interesse ist, wenden Sie sich an mainframe@google.com.

Agil, skalierbar und sicher: Die Gruppe Deutsche Börse setzt auf SAP in der Google Cloud

Mon, 04 Jul 2022 03:00:00 +0000

Die Digitalisierung sorgt für eine umfassende Transformation der Finanzdienstleistungsbranche. Alle Akteure stehen vor der Herausforderung, auf neue Trends zu reagieren, und haben zugleich die Möglichkeit, sie aktiv zu gestalten. Das gilt insbesondere für Börsenorganisation: Anleger*innen erwarten heute schnellere, moderne und sichere Plattformen. IT-Verantwortliche in der streng regulierten Finanzbranche müssen deshalb auf bewährte, leistungsstarke Technologien setzen, die den höchsten Standards für Informationssicherheit entsprechen.

Die Gruppe Deutsche Börse deckt als internationaler und innovativer Kapitalmarkt-Infrastrukturanbieter die gesamte Wertschöpfungskette vom Pre-Trading über das Trading bis zum Post-Trading ab. Anders als viele Finanzdienstleister, die aufgrund regulatorischer Bedenken vor der Nutzung von Cloud-Diensten zurückschrecken, haben wir uns entschieden, eng mit den Aufsichtsbehörden zusammenzuarbeiten, damit unsere Branche und Kund*innen von technologischen Neuerungen profitieren können.

Unser Ziel dabei sind Verbesserungen in puncto Geschwindigkeit, Skalierbarkeit, Leistung, Sicherheit und Compliance. Aus Gründen der Geschäftskontinuität und Flexibilität verfolgen wir dazu eine Multi-Cloud-Strategie. Deshalb haben wir uns bei der Auslagerung einiger SAP-Workloads aus unseren lokalen Umgebungen für Google Cloud als Infrastruktur- und Dienstanbieter unseres Vertrauens entschieden.

Höhere Standards für Effizienz und Reaktionsvermögen

Die Verlagerung unserer S/4HANA-Umgebung in die Cloud hat sich als äußerst vorteilhaft erwiesen: Dank der Google Cloud-Infrastruktur konnten wir beispielsweise den Aufbau einer S/4HANA-Umgebung in der Schweiz statt in neun Monaten vor Ort in nur drei Monaten in der Cloud vollziehen.

Auch im Hinblick auf die Skalierbarkeit hatten wir hohe Erwartungen und erzielten mit Google Cloud schnell große Erfolge. Geschäftsprozesse wie das Berichtswesen, die Fakturierung und das Onboarding vieler teils manuell abgewickelter Services sind heute deutlich flexibler und weniger zeitaufwändig. Außerdem konnten wir viele Prozesse unter anderem in den Bereichen Infrastrukturmanagement, Systemwiederherstellung, Systemreaktion und Ausfallsicherheit automatisieren.

Vor der Umstellung auf unsere neue S/4 HANA-Umgebung in Google waren wir auf lokale Anwendungen vor allem von SAP angewiesen. Dazu gehörte ein riesiges Business Warehouse, das uns wenig Flexibilität für die Skalierung in neuen Märkten oder bei der raschen Bereitstellung von Daten für neue Geschäftsfelder bot.

Weil unsere Leistung in hohem Maße von unseren Sicherheits- und Compliance-Praktiken abhängig ist, haben uns die dazu verfügbaren nativen Funktionen auf der Infrastrukturebene von Google Cloud überzeugt. Technische System- und Anwendungsüberwachung, Data-in-Motion- und Data-at-Rest-Verschlüsselung sowie eine Vielzahl weiterer in Google Cloud enthaltener Sicherheits- und Betriebstools haben uns in unserer Entscheidung bestärkt. Außerdem können wir nun unsere Notfallwiederherstellung ausbauen, indem wir unsere beiden Rechenzentren durch Google Cloud-Infrastruktur in Deutschland und Belgien ergänzen und so die hohe Verfügbarkeit unserer Systeme gewährleisten.

Auch die starken Automations-Engines für die Replikation und Multiplikation von Umgebungen oder die Verbindung zu anderen Cloud-Anbietern bestätigen uns, dass wir den richtigen Weg eingeschlagen haben. Bei unserem endgültigen Umzug in die Cloud konnten wir uns jederzeit auf die von Google Cloud bereitgestellte Infrastruktur verlassen.

Mehr Leistung, Agilität und Datenzugriffe mit SAP in der Google Cloud

Im Rahmen der Transformation unserer Backoffice-Prozesse werden wir auch unsere übrigen Legacy-Umgebungen wie SAP ERP, CRM, BW und andere abhängige Anwendungen nach SAP S/4HANA in die Google Cloud migrieren.

Die Leistung unserer Systeme hat sich bereits in vielen entscheidenden Bereichen wie kürzeren Zugriffs-, Lade- und Wiederherstellungszeiten verbessert. So konnten wir etwa seit der Verlagerung von SAP in die Google Cloud die Dauer der Systemwiederherstellung von 45 Minuten auf unter 20 Minuten reduzieren.

In unserer Fakturierung haben früher permanente Maschinen Millionen monatlicher Kundenrechnungen aus Handelsgeschäften und die entsprechenden Compliance-Simulationen bearbeitet. Diese Workloads brachten mit ihren hohen Rechenanforderungen das bisherige System an seine Grenzen. Heute können wir für die Fakturierung bei Bedarf einfach zusätzliche Maschinen hochfahren und ein paar Tage später wieder außer Betrieb nehmen. Auf diese Weise bietet SAP in der Google Cloud ein hohes Maß an Effizienz bei voller Kostenkontrolle.

Die Kundenfakturierung ist einer unserer Bereiche mit dem größten Datenzuwachs. Derzeit haben wir etwa fünf TB Daten allein aus diesem Bereich in SAP-Anwendungen, und jährlich kommt rund ein weiteres TB hinzu. Zusätzlich haben wir 17 bis 20 TB in SAP Business Warehouse (BW). Auch hier erwarten wir, durch den Einsatz nativer Dienste in der Google Cloud die Zugänglichkeit, das Tiering sowie das Management der Daten und damit auch die betriebliche Effizienz zu verbessern.

Außerdem werden wir künftig von intuitiven Funktionen profitieren, die in Google Cloud standardmäßig enthalten sind. Nachdem wir SAP nicht mehr lokal sondern in der Google Cloud nutzen, konnten wir den Zugriff auf SAP-Anwendungen transformieren: Statt mehrere Passwörter einzugeben und sich durch verschiedene Formulare zu klicken, können unsere Beschäftigten heute mit wenigen Mausklicks von ihrem Browser aus sicher auf Informationen und Dienste zugreifen. Das ist ein enormer Fortschritt, da unsere weltweit mehr als 10.000 Beschäftigten diese Systeme nicht nur im Büro sondern auch regelmäßig im Homeoffice nutzen.

Genauso wichtig ist auch die starke Partnerschaft von Google Cloud und SAP, dank der wir untersuchen können, wie Entwickler*innen, Analyseteams und andere SAP in der Google Cloud optimal nutzen. So experimentieren wir zum Beispiel bereits mit BigQuery und BW/4 HANA, um die Abfragezeiten mit Data Slicing, Tiering und anderen von den Integrationen zwischen diesen Lösungen bereitgestellten Methoden zu verbessern. Wir gehen davon aus, dass sich die Antwortzeiten bei Abfragen auf diese Weise von bis zu zwei Stunden auf fünf oder weniger Minuten verkürzen lassen.

Zusammenarbeit mit Aufsichtsbehörden für stärkere Nutzung der Cloud im Finanzdienstleistungssektor

Google Cloud verfolgt einen proaktiven, richtlinienbasierten Sicherheits- und Compliance-Ansatz. Das ist in dem streng regulierten Umfeld, in dem wir tätig sind, auch unbedingt erforderlich. Dank der integrierten Sicherheitsfunktionen von Google Cloud sind wir in der Lage, die Anforderungen von Behörden wie etwa der deutschen Bundesanstalt für Finanzdienstleistungsaufsicht im Hinblick auf das Workload-, Daten- und IT-Betriebsmanagement zu erfüllen.

Die Aufsichtsbehörden müssen die Migration von Workloads in die Cloud genehmigen. In unserem Digitalisierungsplan spielen sie deshalb eine entscheidende Rolle. Wir haben sehr gute Erfahrungen damit gemacht, jeden unserer Schritte mit ihnen abzustimmen, um so die sichere Einbindung weiterer Cloud-Dienste zu gewährleisten. Wir betrachten die Branchenaufsicht nicht nur als eine Behörde, sondern als Partner, der unser eigenes Interesse an der finanziellen Stabilität der Märkte und den Vorteilen neuer und besserer Arbeitsweisen teilt.

Unsere Zusammenarbeit mit Google Cloud und die Transformation unserer SAP-Umgebung zeigt, wie die Vorteile von Cloud-Diensten in unserer Branche besser genutzt werden können, ohne Regulierungs-, Datenschutz- und andere Rechtsvorschriften zu verletzen oder bewährte Verfahren außer Acht zu lassen.

Wir sind stolz darauf, dass die Gruppe Deutsche Börse als eines der ersten Unternehmen in der Finanzdienstleistungsbranche ihre Geschäfts-Infrastruktur in die Cloud verlagert. Wir wissen aber auch, dass wir noch ganz am Anfang stehen: SAP in der Google Cloud wird auf unserem Weg auch weiterhin eine wichtige Rolle spielen.

Klicken Sie hier, um mehr über die Vorteile von SAP in der Google Cloud für Ihr Unternehmen zu erfahren.

„Rehost“, „Replatform“ und „Rearchitect“ neu durchdacht: Cloud-Migration für die Praxis

Thu, 02 Sep 2021 17:00:00 +0000

Wenn wir Unternehmenskunden dabei helfen, umfassende Migrationen von Anwendungen in die Cloud vorzunehmen, erlebt unser Professional Services-Team gelegentlich, wie unzählige Stunden darauf verwendet werden, den Zustand der Anwendungen zu evaluieren und diese verschiedenen Migrationsstrategien wie „Rehost“, „Replatform“, „Refactor“ usw. zuzuordnen. Dies ist eine gängige Praxis, bei der die einzige Frage zu sein scheint, ob es 5, 6, 7 oder 8 verschiedene „R“-Strategien gibt.

In Wirklichkeit sind die beliebten „R“-Strategien gar keine Strategien. Sie sind nur Platzhalter für alle Aspekte, die Sie von Ihren Anwendungen noch nicht kennen. Wir erleben, dass insbesondere die Richtlinien und Funktionen eines IT-Unternehmens den Migrationspfad bestimmen und letztendlich den früheren Top-Down-Plan der Entwicklerinnen und Entwickler nichtig machen.

Noch wichtiger ist, dass so gut wie keine Anwendung in Bezug auf alle ihre Ebenen ausschließlich zu einer der Migrationsstrategien passt. Die Datenbank wird z. B. von selbstverwaltetem PostgreSQL auf verwaltetes Cloud SQL migriert, während die Anwendungsebene möglicherweise als dieselbe VM auf Compute Engine gehostet wird und der Load-Balancer durch den globalen Load-Balancer von Google ersetzt wird.

In der Regel benötigen die meisten Unternehmen einen ganzheitlicheren Migrationsansatz. Aus diesem Grund achtet unser Professional Services-Team bei der Interaktion mit Unternehmenskunden nur wenig auf die Nennungen dieser Strategieebenen. In der frühen Planungsphase interessieren wir uns mehr für die Menschen und Prozesse, bevor wir uns näher mit der Technologie befassen. Zunächst sollten Sie vielleicht über das Google Cloud Adoption Framework nachdenken und überlegen, ob Ihre Anforderungen an die Cloud-Migration taktisch, strategisch oder transformativ sind. Wenn Sie dies ermittelt haben, sollten Sie drei grundlegende Migrationsansätze prüfen:

Ansatz: Migration Factory

Der Migration Factory-Ansatz, bei dem wir virtuelle Maschinen oder Container in Gruppen kopieren oder bereitstellen, funktioniert gut, wenn es sich um einfache, einander recht ähnliche Anwendungen handelt, und wenn das Team, das die Migration durchführt, dies selbst ohne viel Koordination mit einzelnen Anwendungsteams bewerkstelligen kann. Dieser skalierte Ansatz eignet sich für Initiativen, die infrastruktur- statt anwendungsorientiert sind, insbesondere für umfassende Rechenzentrumsmigrationen, und kann mit Lösungen wie Google Cloud VMware Engine oder speziellen Tools wie Migrate for Compute Engine oder unserem Database Migration Service ausgeführt werden.

Auf der anderen Seite eignet sich der Migration Factory-Ansatz nicht besonders gut für einen Change Management-Prozess (durch interne Richtlinien oder externe Regulierungen), bei dem jede Anwendung einzeln einer manuellen Prüfung unterzogen wird. Der für die Prüfung und Kontrolle der unausweichlichen Änderung erforderliche Aufwand überwiegt die durch die automatisierte Migration von Code und Daten erzielte Zeitersparnis. Dasselbe gilt, wenn Sie umfassende Änderungen an Ihrer CI/DC-Toolkette vornehmen müssen, bevor Sie die Änderungen in Ihrer Cloud-Umgebung vornehmen können. Wenn Sie den Änderungsprozess berücksichtigen, scheint eine einfache Migration der lokalen IT-Infrastruktur in die Cloud aus Kostensicht weniger attraktiv.

Zusammengefasst lässt sich festhalten, dass es einige konkrete Szenarien gibt, in denen der Migration Factory-Ansatz die beste Option ist. Es gibt jedoch viele Szenarien, die diese Kriterien nicht erfüllen.

Ansatz: Greenfield-Softwareentwicklung

Ganz im Gegensatz zum Migration Factory-Ansatz gibt es die Möglichkeit, keine vorhandenen Anwendungen zu migrieren, sondern stattdessen eine neue „Greenfield“- oder „cloudnative“ Anwendung zu zu entwickeln. Dieser Ansatz entspricht im Grunde den gängigen Methoden der agilen Softwareentwicklung. Der Ansatz bezieht sich nicht speziell auf die Cloud. Die verwalteten und serverlosen Dienste der Cloud eignen sich besonders gut für die schnelle Entwicklung einer solchen Softwarelösung.

Eine neu entwickelte Anwendung sollte wie ein Produkt, nicht wie ein Projekt behandelt werden. Das heißt, das Team stellt seine Arbeit nicht ein, wenn der letzte Meilenstein erreicht wurde. Stattdessen muss es die Anwendung weiter überwachen und ihre Funktionen ständig weiterentwickeln und erweitern (oder zumindest so lange, bis die Verwendung der Anwendung eingestellt wird). In dieser Hinsicht unterscheidet sich der Ansatz grundlegend von jeder anderen Art der Migration. Es gibt keine vordefinierten Zeitpläne und bei der Entwicklung werden keine einseitigen Voraussetzungen festgelegt. Es gibt lediglich Sprints einer inkrementell nutzbaren Software mit vielen Funktionen. Das mit der Entwicklung der Anwendung vertraute Team sollte klein, funktionsübergreifend und dauerhaft aufgestellt sein. Es braucht deutlich mehr Zeit, eine neue Anwendung zu entwickeln, als eine vorhandene zu migrieren.

Ansatz: Modernization Factory

Die Mehrzahl der Migrationen, die wir bei unseren Unternehmenskunden sehen, beinhaltet in irgendeiner Form die Modernisierung einer Anwendung nach der anderen.

Softwaremodernisierung ist breit gefächert und umfasst zahlreiche unabhängige Vorgehensweisen und Best Practices zur Verbesserung von Skalierbarkeit, Verfügbarkeit, Sicherheit und Langlebigkeit der Anwendung an sich, während gleichzeitig der für Bereitstellung und Betrieb der Anwendung erforderliche Aufwand gesenkt werden soll.

Es sind diese inkrementellen Modernisierungen, die in der Regel dazu führen, dass Unternehmenskunden echte TCO-Einsparungen erzielen – und sie sind auch der Grund, weshalb eine Verbesserung ihrer DevOps-Fähigkeiten Hand in Hand mit der Cloud-Einführung geht. Da in der Cloud immer APIs eingesetzt werden, kann alles automatisiert werden.

So kann beispielsweise die Bereitstellung abgestimmter Projektumgebungen mithilfe der Infrastruktur entscheidend für eine effektive Modernisierung sein. Es kann für die Skalierung große Vorteile bringen, zustandsorientierte von zustandsloser Logik zu entkoppeln. Das Entfernen des Shell-Zugriffs von allen Servern, sodass stattdessen nur Änderungen durch eine CI/CD-Pipeline weitergegeben werden können, kann für Ihre Aufstellung in puncto Sicherheit von enormer Bedeutung sein. Es gibt Hunderte weitere Beispiele für inkrementelle Softwaremodernisierungen und keines davon lässt sich in eine „R“-Migrationsstrategie pressen.

Eine vereinfachte Darstellung einer graduellen Modernisierung

Wenn wir unsere Unternehmenskunden dabei unterstützen, ihre Anwendungen mit einigen Modernisierungen zu Google Cloud zu migrieren, nutzen wir die gängigen Anwendungsebenen (bzw. „Archetypen“) in ihrem aktuellen Zustand und verständigen uns auf eine begrenzte Anzahl an angestrebten Cloud-Diensten, eine Reihe von Modernisierungstaktiken und ein bestimmtes Maß an Automatisierung über CI/CD und Infrastruktur als Code. Weitere Modernisierungen, die über diese grundlegenden Vereinbarungen hinausgehen, sollten zurückgestellt werden, bis die Anwendung für den Betrieb in der Cloud bereit ist.

Bei einem Modernization Factory-Ansatz ist ein gemischtes Team notwendig. Es sollte aus einem kleinen funktionsübergreifenden Anwendungsteam, das mit der individuellen Anwendung vertraut ist, sowie aus einem „Factory-Team“ bestehen, das sich mit dem Portfolio der angestrebten Dienste und mit den Modernisierungstaktiken auskennt, die für alle Anwendungen zum Einsatz kommen. Während das Anwendungsteam die „Factory“ mit seiner jeweiligen Anwendung betritt und verlässt, bleibt das Factory Team durchgängig zuständig und befasst sich mit einer Anwendung (und einem Anwendungsteam) zur Zeit.

Es ist von entscheidender Bedeutung, dass das Factory Team sich mit allen Entscheidungsträgerinnen und -trägern abstimmt, die in der Position sind, den erfolgreichen Abschluss der Migration zu verhindern. Sie können sich das Factory Team als begrenzten Mikrokosmos innerhalb des Unternehmens vorstellen, der organisatorische Hierarchien durchdringt und alle auf ein gemeinsames Ziel hinarbeitet: die erfolgreiche Migration einer Anwendung in die Cloud.

Nicht zuletzt sollte beim Modernization Factory-Ansatz ein zentrales Forum geschaffen werden, das die Möglichkeit bietet, Mitarbeiterinnen und Mitarbeiter in Bezug auf das neue Cloud-Modell zu schulen. Dadurch lässt sich vermeiden, dass zahlreiche IT-Beschäftigte im Vorgriff Schulungen zu Technologien erhalten, die sie später gar nicht benötigen. Gleichzeitig wird sichergestellt, dass die Anwendungsteams die Fähigkeiten und Möglichkeiten erhalten, nach der Migration eigenständig und erfolgreich zu arbeiten.

Wenn die erste Migration erfolgreich verlief, können zusätzliche Modernization Factorys geschaffen werden, um weitere Anwendungen parallel zu migrieren.

Fazit

Welchen Ansatz sollten Sie für Ihre Anwendungen wählen? Um eine gute Migrationsstrategie zu entwickeln, sollten Sie zuerst Klarheit darüber erhalten, warum Ihr Unternehmen den Wechsel in die Cloud vollzieht. Ausgehend davon planen Sie Ihr weiteres Vorgehen.

Nehmen wir noch einmal das Beispiel des Google Cloud Adoption Framework: Wenn Ihr Ziel darin besteht, Kosten zu senken und gleichzeitig nur minimale Änderungen an Ihren Anwendungen vorzunehmen (also ein taktisches Ziel), dann empfehlen wir den Migration Factory-Ansatz. Wenn Ihr Ziel darin besteht, die Vorteile zu maximieren, die Sie durch Ihre Software erhalten (also ein strategisches Ziel), dann empfehlen wir den Modernization Factory-Ansatz oder den Greenfield-Softwareentwicklungsansatz. Wenn Ihr Ziel darin besteht, mit neuen Anwendungen auf innovative Weise neue geschäftliche Herausforderungen zu meistern (also ein transformatives Ziel), empfehlen wir den Greenfield-Softwareentwicklungsansatz.

Nachdem Sie ermittelt haben, warum Ihr Unternehmen in die Cloud wechseln möchte, und sich auf das weitere Vorgehen verständigt haben, ergibt sich alles andere von selbst – auch die Aspekte, die nicht durch „R“-Strategien abgedeckt sind.

Weitere Informationen über eine Migration zu Google Cloud finden Sie in unserer Website zum Thema Rechenzentrumsmigration in die Cloud. Alternativ können Sie sich auch für eine kostenlose Evaluation des Kostenaufwands einer Cloud-Migration anmelden.

^{1. Die 5 Rs von Gartner
2. Die 6 Rs von AWS
3. Die 7 Rs von Citrix
4. Die 8 Rs von Infosys}

13 Beispielarchitekturen für Ihren Schnelleinstieg in Google Cloud

Thu, 14 Jan 2021 16:00:00 +0000

Unabhängig von den Anforderungen Ihres Unternehmens in puncto Kosten oder Leistung erhalten Sie mit Google Cloud eine äußerst flexible Plattform, die viele verschiedene Anwendungsarchitekturen unterstützt. Aber womit fangen Sie am besten an?

Als Google Cloud Developer Advocate habe ich kürzlich eine Twitter-Serie zum Thema 13 Tage GCP (in englischer Sprache) gepostet, in der einige der häufig genutzten Google Cloud-Referenzarchitekturen behandelt wurden. Diese habe ich nun hier zusammengefasst. Möchten Sie lernen, wie Sie Hybrid-Cloud- oder mobile Apps bereitstellen? Wie Mikrodienste, CI/CD, Machine Learning oder Sicherheit funktionieren? In diesem Artikel finden Sie alle nötigen Informationen, um zuversichtlich die ersten Schritte mit Google Cloud zu gehen. (Beachten Sie, dass es sich hier natürlich lediglich um Beispiele handelt und jede Lösung auf vielfältige Art und Weise umgesetzt werden kann.)

1. Hybrid-Architektur in Google Cloud und lokal einrichten

Wenn es um die Migration oder einfach nur das Ausführen von Anwendungen teils auf lokalen Systemen und teils in der Cloud geht, sind hybride Architekturen eine sehr verbreitete Lösung. Besonders gerne wird eine Hybrid-Architektur eingesetzt, bei der das Front-End und/oder der Anwendungsserver in Google Cloud und das Back-End lokal bereitgestellt werden.

In diesem Szenario fordern Nutzer:innen die Apps über das Internet an und ein globaler Load-Balancer leitet sie zu Ihrer Anwendung in Google Cloud oder im lokalen System weiter.
Hier verteilt das globale Load-Balancing den Traffic gleichmäßig auf die entsprechenden Dienste. Diese können sich auf jeder Compute-Plattform befinden, wie Compute Engine, Google Kubernetes Engine (GKE), App Engine usw.
Die Anwendungen, die mit den Back-End-Systemen in Ihrem Rechenzentrum interagieren müssen, müssen sich je nach Ihren Bandbreitenanforderungen über Cloud VPN oder Interconnect verbinden. Sie sind unsicher, welche Variante Sie wählen sollen? Hier finden Sie Antworten.
Anfragen für die lokale Anwendung landen beim Load-Balancer, der die Last über die Anwendungsserver verteilt.
Anwendungsserver verbinden sich mit Back-End-Funktionen wie Suche, Cache und Datenbanken, um die Anfragen der Nutzer:innen zu erfüllen.

Weitere Informationen zu Hybrid-Lösungen finden Sie in diesem Artikel.

2. Hybrid-Architektur für Cloud Bursting einrichten

Das Bursting von Traffic zur Cloud kann ein guter Einstieg in die Nutzung der Cloud sein. Wenn Ihre Anwendung lokal bereitgestellt ist, können Sie diese für die Basislast nutzen und vorübergehend einen Burst zu Google Cloud nutzen, wenn Sie bei einem plötzlichen Anstieg des Traffic zusätzliche Kapazität benötigen. Ein Hauptvorteil wäre hier, dass Sie keine zusätzlichen Kapazitäten lokal bereithalten und warten müssen. Da Sie in der Cloud nur für das bezahlen, was Sie auch nutzen, können Sie durch Bursting auch Kosten sparen.

Hier erfahren Sie mehr über Hybrid-Lösungen und -Muster.

3. Sensible Daten in Chatbots mit der Data Loss Prevention (DLP) API maskieren

Stellen Sie sich eine Situation vor, in der Ihr Unternehmen oder Ihre Nutzer:innen vertrauliche Informationen an einen Chatbot weitergeben müssen. Mit Dialogflow können Sie Ihren Nutzer:innen ein dialogorientiertes Erlebnis bieten, ohne Machine Learning oder künstliche Intelligenz erlernen zu müssen.

In dieser Architektur interagiert die Nutzerin oder der Nutzer beispielsweise mit einem Chat über Telefon oder Internet, der den Dialogflow-Agent aufruft. Die Anfrage wird von Geschäftslogik über die serverlose Cloud Functions-Umgebung oder VMs erfüllt. Wenn Sie dann vertrauliche Informationen aus dem Chat unkenntlich machen möchten, können Sie die DLP API nutzen und die Daten zur weiteren Verarbeitung in BigQuery speichern.

4. Back-Ends für mobile Apps in Google Cloud erstellen

Wenn Sie mobile Apps in Google Cloud erstellen, ist Firebase eine gute Option für die Speicherung, die Authentifizierung der Nutzer:innen, das Hosting und mehr. Sie können Firebase mit vielen Back-Ends zusammen verwenden, wie die serverlose Cloud Functions-Umgebung zum Vereinen von Geschäftslogik oder Cloud Run zum Ausführen serverloser Container als App-Back-Ends. Sie können auch eine Verbindung mit App Engine und Compute Engine herstellen, wenn Ihre Back-Ends sich dort befinden.

Weitere Informationen erhalten Sie in dieser Serie.

5. Oracle-Datenbank zu Spanner migrieren

Wie lässt sich Oracle am besten zu Cloud Spanner migrieren? Wenn Sie eine Oracle-Datenbank nutzen und diese zu Spanner migrieren möchten, um von der globalen Skalierung zu profitieren, müssen Sie zunächst Ihre Oracle-Datenbank in ein mobiles Dateiformat wie CSV exportieren und sie in Cloud Storage speichern. Dann können Sie die Daten in Dataflow aufnehmen. Hier werden die Dateien gelesen und geparst, die Daten konvertiert, Spanner-Mutationen erstellt, etwaige Fehler behandelt und letztendlich die Daten in Spanner geschrieben.

Hier finden Sie weitere Informationen zu dieser Lösung.

6. Data Lake in Google Cloud erstellen

Der Zweck eines Data Lake ist die Aufnahme und Speicherung von Daten für das Mining und andere Workflows wie Data-Marts, Echtzeitanalysen, ML und mehr. Folgendes sollten Sie berücksichtigen, wenn Sie einen Data Lake in Google Cloud einrichten:

Sie können Daten aus verschiedenen Quellen aufnehmen, z. B. aus (IoT-)Sensoren, lokalen Systemen, Nutzungsaktivitäten wie Clickstreams oder Onlinetransaktionen.
Echtzeitdaten können über Pub/Sub und Dataflow aufgenommen werden, die für variierende Datenvolumen skalierbar sind.
Batchdaten können je nach Bandbreite und Volumen über Transfer Appliance, Transfer Service oder gsutil aufgenommen werden. Die optimierten Echtzeitdaten können dann in Bigtable oder Spanner gespeichert werden.
Sie können das Data Mining der Daten im Data Lake mit Datalab und Dataprep ausführen. Für Machine Learning nutzen Sie Datalab oder ML Engine, um die Engine zu trainieren, und speichern die Prognosen in Bigtable.
Für Warehousing können Sie die Daten an BigQuery senden oder Dataproc nutzen, wenn Sie ein Hive-System verwenden.

Weitere Informationen finden Sie in dieser Lösung zum Einsatz von Cloud Storage als Data Lake.

7. Websites in Google Cloud hosten

Das Skalieren einer Website anhand des Traffics ist nicht immer einfach. Google Cloud bietet einfache und kosteneffiziente Möglichkeiten, um Websites zu hosten und auch für umfangreiches Anfragenaufkommen zu skalieren. So skalieren Sie eine Website
in Google Cloud:

Wenn eine Nutzerin oder ein Nutzer eine Anfrage an Ihre Website sendet, übersetzt Cloud DNS den Hostnamen in die IP-Adresse Ihres Webservers.
Die Anfrage geht dann an Cloud CDN, die Antwort erfolgt aus dem Cache. Wenn keine Antwort im Cache gespeichert ist, geht die Anfrage an das globale Load-Balancing, das die Last über die Webserver der Compute Engine verteilt. Sie können auch ein lokales System oder eine andere Cloud als Back-End festlegen.
Statische Dateien wie Bilder werden aus Cloud Storage geliefert. Der interne Load-Balancer sendet die Anfrage dann an die App-Server und letztendlich an die Datenbanken.
Nutzen Sie die Firestore-Dokumentendatenbank für die Profile und Aktivitäten von Nutzerinnen und Nutzern.
Nutzen Sie Cloud SQL für relationale Daten.
Zum Schutz Ihres Back-Ends vor L3- und L4-DDoS-Angriffen aktivieren Sie Cloud Armor mit einem globalen Load-Balancer.
In diesem Beispiel wird Compute Engine als Back-End genutzt, aber Sie können Ihr Back-End auch in Containern auf GKE, Cloud Run oder App Engine bereitstellen.
Verwenden Sie zum Skalieren der Infrastruktur bei Nutzung von Compute Engine verwaltete Instanzgruppen, die automatisch skalieren, wenn die Last steigt. (App Engine und Cloud Run skalieren automatisch mit der Last).

Hier finden Sie weitere Informationen zu dieser Webhosting-Lösung.

8. CI/CD-Pipeline in Google Cloud einrichten

CI/CD ist eine effektive Möglichkeit, Entwicklerteams die Arbeit zu erleichtern und Bereitstellungen am Laufen zu halten. Das Einrichten von CI/CD mit Google Cloud ist einfach:

Entwickler:innen schreiben den Code und pushen ihn in Google Cloud Source Repositories, Bitbucket oder ein Git-Repo.
Sobald der Code im Repository ankommt, startet Cloud Build. Es führt Tests und Sicherheitsscans durch, erstellt ein Docker-Image und überträgt es dann per Push zu Spinnaker, einer Open Source Multi-Cloud-Plattform für Continuous Delivery. Sie können auch Jenkins oder Gitlab nutzen.
Spinnaker stellt dann den Container in einem Produktions-Cluster auf GKE, Cloud Run oder Compute Engine bereit. Es kann auch eine Test-App bereitstellen, um sicherzustellen, dass Änderungen mit echtem Traffic getestet werden.
Der eingehende Traffic trifft auf den Load-Balancer und wird an die Test- oder Produktions-App weitergeleitet.
Wenn die Test-App nicht zufriedenstellend arbeitet, können Sie ein schnelles Rollback automatisieren.

Hier finden Sie weitere Informationen zur CI/CD-Lösung.

9. Serverlose Mikrodienste in Google Cloud erstellen

Mikrodienste und serverlose Architekturen bieten höhere Skalierbarkeit, mehr Flexibilität und kürzere Veröffentlichungszeiträume – all das bei geringeren Kosten. Eine gute Methode zum Erstellen einer serverlosen Mikrodienstarchitektur in Google Cloud ist Cloud Run. Nehmen wir als Beispiel eine E-Commerce-App:

Wenn eine Nutzerin oder ein Nutzer eine Bestellung aufgibt, empfängt ein Front-End in Cloud Run die Anfrage und sendet sie an Pub/Sub, einen asynchronen Messaging-Dienst.
Die nachgeordneten Mikrodienste, die ebenfalls in Cloud Run bereitgestellt sind, abonnieren die Pub/Sub-Ereignisse.
Zum Beispiel kann der Authentifizierungsdienst einen Aufruf an Firestore senden, eine serverlose NoSQL-Dokumentendatenbank. Der Inventardienst fragt die Datenbank ab: entweder in einer vollständig verwalteten relationalen Cloud SQL-Datenbank oder in Firestore. Der Bestelldienst empfängt dann ein Ereignis von Pub/Sub, um die Bestellung zu verarbeiten.
Die statischen Dateien werden in Cloud Storage gespeichert. Hier kann dann durch das Aufrufen der ML APIs eine Cloud Functions-Funktion zur Datenanalyse ausgelöst werden.
Es können weitere Mikrodienste wie Adressensuche in Cloud Functions bereitgestellt sein.
Alle Logs werden in Cloud Logging gespeichert.
BigQuery speichert alle Daten für den serverlosen Warehouse-Prozess.

Weitere Informationen finden Sie in diesem Handbuch zum Thema Serverlose Plattform auswählen.

10. Machine Learning in Google Cloud

Organisationen generieren immer weitere Daten und können Machine-Learning-Techniken einsetzen, um wertvolle Informationen aus diesen Daten zu ziehen. So können Sie in wenigen Schritten Machine Learning in Google Cloud nutzen:

Nehmen Sie zunächst die Daten über eine Transfer Appliance oder einen Transfer Service in Cloud Storage oder BigQuery auf.
Bereiten Sie die Daten anschließend mit BigQuery, Dataprep, Dataflow oder Dataproc vor.
Nutzen Sie AI Hub, um bereits vorhandene Pipelines und KI-Inhalte zu ermitteln.
Wenn alles bereit ist, verwenden Sie den Data Labeling Service von AI Platform, um Label zu Ihren Daten hinzuzufügen.
Erstellen Sie Ihre ML-Anwendung mithilfe von verwalteten Jupyter-Notebooks und eines Deep-Learning-VM-Images.
Mit den Trainings- und Vorhersagediensten von AI Platform können Sie Ihr Modell dann trainieren und in Google Cloud in einer serverlosen Umgebung oder lokal mittels Kubeflow bereitstellen.
Verwenden Sie verständliche KI, um Ihre Modellergebnisse für geschäftliche Nutzer:innen zu erläutern, und geben Sie die Ergebnisse für andere auf AI Hub frei.

Weitere Informationen finden Sie unter Machine Learning in Google Cloud.

11. Serverlose Bild-, Video- oder Textverarbeitung in Google Cloud

Die meisten Anwendungen erfordern ein gewisses Maß an Bild-, Video- oder Textverarbeitung. Nehmen wir als Beispiel für diese Architektur eine Blogging-Website, auf der Nutzerinnen und Nutzer Inhalte in Form von Videos, Bildern und Text erstellen.

Von Nutzer:innen generierte Inhalte aus dem Front-End werden in Cloud Storage gespeichert. Hier wird ein Pub/Sub-Ereignis generiert und eine Cloud Functions-Funktion ausgelöst.
Cloud Functions ruft dann die Vision API, Video Intelligence API oder NLP API auf, je nach Typ der hochgeladenen Datei.
Die Cloud Functions-Funktion empfängt eine JSON-Antwort von der entsprechenden ML API, verarbeitet die Ergebnisse weiter und sendet sie zur weiteren Analyse an BigQuery.
Mit Google Data Studio oder einem anderen Visualisierungstool können individuelle Dashboards für die Analyse der Trends erstellt werden.

Weitere Informationen finden Sie auf der Seite AI Platform.

12. Internet of Things (IoT) in Google Cloud

Wenn Sie eine große Anzahl von Geräten haben, die Daten generieren, können Sie mit IoT-Workflows Daten einfach und sicher verbinden, verwalten und aufnehmen, um sie für nachgeordnete Anwendungen zu nutzen. Im Folgenden finden Sie ein Beispiel für einen IoT-Workflow in Google Cloud.

Ein Sensor sendet Daten an ein Edge-Gerät mit einer Edge-TPU, einem Chip, der ML-Modelle auf Edge-Geräten ausführt.
Der Cloud IoT Edge-Softwarelayer ermöglicht Ihnen das Ausführen von ML-Modellen und von Android Things oder Linux OS.
Vom Edge-Gerät aus werden die Daten über MQTT oder HTTP(S) an Cloud IoT Core gesendet, was wiederum Ereignisse in Pub/Sub generiert.
Pub/Sub löst dann die Aktualsierung der Gerätekonfigurationen über Cloud Functions aus.
Zur langfristigen Speicherung filtert und verarbeitet Dataflow die Daten und sendet sie an eine Bigtable NoSQL-Datenbank oder BigQuery.
Über BigQuery können Sie ein ML-Modell mit BigQueryML oder AI Platform trainieren.
Sie können die Daten in Data Studio oder einem anderen Dashboard visualisieren.

Weitere Informationen finden Sie unter Cloud IoT Core.

13. Zero-Trust-Sicherheitsmodell von BeyondCorp einrichten

BeyondCorp ist die Umsetzung eines Zero-Trust-Sicherheitsmodells von Google. Dahinter stecken acht Jahre Erfahrung im Erstellen von Zero-Trust-Netzwerken bei Google und die Ideen und Best Practices aus der Community. Nehmen wir als Beispiel ein Unternehmen, in dem ein Teammitglied auf eine interne App zugreifen möchte.

Die Anfrage geht an Cloud Load Balancing und wird an einen Identity Aware Proxy (IAP) weitergeleitet.
IAP stellt eine Verbindung zum Geräteinventar her und prüft, ob die Nutzerin oder der Nutzer berechtigt ist. Dann werden folgende Verbindungen hergestellt: zu Cloud Identity für die Endpunktverwaltung, zu Active Directory für die Authentifizierung und zu Identity and Access Management (IAM) sowie Access Context Manager für den richtlinienbasierten, kontextabhängigen Zugriff. Diese Prüfungen können unterschiedlich konfiguriert werden, z. B. für Mitarbeiter:innen oder externe Angestellte.
Wenn alle Prüfungen bestanden wurden, erfolgt die Weiterleitung an den Service. Wenn die Prüfungen nicht bestanden werden, wird der Zugriff verwehrt.
Wenn das Back-End lokal ist, stellen der lokale IAP-Connector und Cloud Interconnect oder Cloud VPN eine direkte Verbindung zum Rechenzentrum her.

Hier finden Sie weitere Informationen zu BeyondCorp.

Alles klar!

Wir hoffen, diese Übersicht der häufigsten Google Cloud-Referenzarchitekturen war für Sie hilfreich. Ihre neu erworbenen Kenntnisse können Sie mit diesem Rätsel testen. Haben Sie weitere Fragen zu Google Cloud-Architekturen? Sie erreichen mich auf Twitter unter @pvergadia.

Anwendungsmodernisierung

„Multicloud Mindset“: Gedanken zu Open Source und Sicherheit in der Multicloud-Welt

Folge 5: Open Source und Multicloud treffen zusammen

Folge 6: Neue Herausforderungen für die Multicloud-Sicherheit

Sechs Tipps zur Optimierung von API-Management-Kosten mit Apigee

#1 Höchstwert für Apigee-Gateway-Knoten festlegen

#2 Knoten-Mindestanzahl nicht zu hoch ansetzen

#3 Manuelle Anpassungen der Knotenanzahl vermeiden

#4 API-Traffic am Netzwerk-Edge sichern, um unnötige Gebühren zu vermeiden

#5 Vorhandene Knoten auf mehrere Regionen aufteilen, statt Ressourcen hinzuzufügen

#6 Das am besten geeignete Apigee-Preismodell wählen

Wie Sie Ihre Kosten schätzen und Ihre Nutzung überwachen können

Nächste Schritte

Migration Ihrer Oracle- und SQL Server-Datenbanken zu Google Cloud

#1 Ausführung von Oracle-basierten Anwendungen in der Google Cloud

#2 SQL Server-basierte Anwendungen in Google Cloud ausführen

#3 Auswahl einer PostgreSQL-Datenbank in der Google Cloud

#4 Wie Sie Ihre Anwendungen mit Google Cloud-Datenbanken migrieren und modernisieren

#5 Erste Schritte mit dem Database Migration Service

Wir freuen uns auf die Zusammenarbeit mit Ihnen

Aktuelles auf dem Google Cloud Blog

So erschließen Sie Ihre Mainframe-Daten mit Data-First-Digitalisierung

Aktuelles auf dem Google Cloud Blog

Agil, skalierbar und sicher: Die Gruppe Deutsche Börse setzt auf SAP in der Google Cloud

Höhere Standards für Effizienz und Reaktionsvermögen

Mehr Leistung, Agilität und Datenzugriffe mit SAP in der Google Cloud

Zusammenarbeit mit Aufsichtsbehörden für stärkere Nutzung der Cloud im Finanzdienstleistungssektor

Aktuelles auf dem Google Cloud Blog

„Rehost“, „Replatform“ und „Rearchitect“ neu durchdacht: Cloud-Migration für die Praxis

Ansatz: Migration Factory

Ansatz: Greenfield-Softwareentwicklung

Ansatz: Modernization Factory

Fazit

Aufbau der digitalen Fabrik mit SAP in Google Cloud

13 Beispielarchitekturen für Ihren Schnelleinstieg in Google Cloud