Über den Kunden:
Unser Kunde ist eine mittelgroße Geschäftsbank mit einer vor Ort installierten mobilen Banking-Plattform. Die Bank ist in einem der CEE-Länder tätig und betreut Privatpersonen, KMU und Unternehmen. Sie hat eine halbe Million Kunden.
Überblick über den Kanal Mobile Banking:
Unter der Bank digitale Kanäleist die wichtigste davon Mobile Banking aus den folgenden Gründen.
- schnell wachsende Zahl aktiver mobiler Kunden (>300 Tausend).
- hohe Anzahl von Benutzeranmeldungen (~30 pro Monat, ~3x mehr als beim Internet-Banking).
- entscheidende Bedeutung für Zahlungen (mobile Zahlungen und 3D-Secure-Genehmigungen für Kartentransaktionen).
Durch den Markt, die Bank der mobile Anwendung gilt als innovativ, kann sowohl Privat- als auch Firmenkunden bedienen und unterstützt verschiedene Arten von Zahlungen, darunter Sofortüberweisungen, E-Commerce-Zahlungen, Apple Pay / Google Pay, 3D-Secure-Autorisierungen und Abhebungen an Geldautomaten ohne Karte.
Die Mobile-Banking-Plattform wurde vor ein paar Jahren gebaut und in Betrieb genommen mit ein modernes Technologiepaket (native mobile Anwendungen in Kotlin & Swift), Microservice-Architektur, Oracle-Datenbank, und verwaltet mit OpenShift.
Die Plattform wird vor Ort installiertund die Hardware-Infrastruktur muss in der Lage sein, monatliche Nutzungsspitzen (Zahlungstage am Monatsende) und saisonale Spitzen (wie Black Friday, Nachweihnachtsgeschäft und Sommerschlussverkauf) zu bewältigen.
Herausforderung: überdimensionierte Infrastruktur und hohe Wartungskosten.
Der CTO der Bank identifizierte die folgenden Herausforderungen bei der Wartung der mobilen Plattform.
Kosten für den Ausbau der Infrastruktur
Die Infrastruktur vor Ort muss in der Lage sein, das rasche Wachstum der Nutzerzahlen und mehrere Nutzungsspitzen im Laufe des Jahres zu bewältigen.
Außerdem muss sie äußerst zuverlässig sein, da sie für Zahlungen entscheidend ist. Daher erfordert es die notwendige Kapazitätsreserve nur einige Male im Jahr konsumiert werden.
Kosten für die Instandhaltung von Ressourcen für verschiedene Umgebungen
Bei einer Vor-Ort-Infrastruktur muss die Bank in verschiedene andere Hardware-Umgebungen zu investieren und diese zu warten.
Beispiele dafür sind Entwicklungs-, Staging-, UAT-, Vorproduktions-, Produktions- und Referenzumgebungen (Kopie der Produktion zur Replikation von Fehlern).
Jede Umgebung umfasst Hardware, die gewartet, in regelmäßigen Abständen erneuert und/oder zur Unterstützung neuer Initiativen angeschafft werden muss.
Kosten der Datenbanklizenz
Ein wesentlicher Kostenfaktor im IT-Budget sind die jährlichen Lizenzgebühren für den Anbieter von Datenbanksoftware.
Die Bank erwägt die Umstellung auf eine Open-Source-Alternative.
Lösung:
Die Abhilfe für die oben beschriebenen Herausforderungen war die Migration der Plattform in die Cloud mit einer skalierbaren und hochverfügbaren Datenbank ausgestattet, die als Dienstleistung angeboten und nach der tatsächlichen Nutzung der Rechenleistung abgerechnet wird.
Ein zusätzlicher Vorteil wäre die sofort einsetzbare Zugang zu automatisierten Tools, die den Aufbau automatisierter CI/CD-Prozesse ermöglichen. Da die Bank nicht über interne Experten auf diesem Gebiet verfügte, suchte sie einen erfahrenen Berater, der das Bankenteam bei der Migration der Plattform und der erforderlichen Code-Optimierung unterstützte.
Cloud-Migration Schritt für Schritt:
- 1. Migration von OpenShift zu Google Kubernetes Engine
- 2. Einrichten von Cloud SQL für PostgreSQL
- 3. Datenmigration zu Cloud SQL für PostgreSQL
- 4. Migration auf die Produktionsumgebung
Für die Umstellung auf GKE mussten wir die Anwendung optimieren und die erforderlichen Tests durchführen:
- Anpassung des mobilen Banking-Backends an Kubernetes
- Integration mit nativen Google Cloud-Diensten wie Pub/Sub
- Erster Testlauf der mobilen Banking-Plattform auf Kubernetes
- Entwicklung und Konfiguration einer ausgereiften CI/CD-Pipeline
- Vorbereitung der erforderlichen Umgebungen in Google Cloud (Test, Stage, Production)
- Testeinführung von Mobile Banking auf GKE mit E2E-Tests, Leistungstests und Dimensionierung für die Produktion
- Konfiguration von gesichertem Ingress/Egress-Verkehr und Integration mit Drittdiensten außerhalb der öffentlichen Cloud
- Umstellung des Datenverkehrs von der lokalen Umgebung auf Google Cloud
Um Cloud SQL für PostgreSQL zu nutzen, haben wir die folgenden Aufgaben durchgeführt:
- Vorbereitung und Überprüfung von Liquibase-Änderungssätzen
- Teststart des Systems in einer lokalen Umgebung mit einer lokalen PostgreSQL-Datenbank
- Dimensionierung für Cloud SQL festlegen
- Datenmigration von Oracle zu Cloud SQL for PostgreSQL in einer Testumgebung
- Leistungstests und Datenbankabstimmung
- Test der Migration der Produktionsdatenbank
- Migration der Produktionsdatenbank
Um Cloud SQL für PostgreSQL zu nutzen, haben wir die folgenden Aufgaben durchgeführt:
- Konfigurieren von Cloud SQL für eine Vorproduktionsumgebung
- Datenmigration und anschließende Validierung der Migrationsergebnisse
- Testeinführung von Mobile Banking mit Cloud SQL-Datenbank
- Leistungstests und KPI-Überprüfung
- Testkonfiguration von Sicherungsrichtlinien, Wiederherstellungstests
Nach positiven Testergebnissen wiederholten wir die Migration in der Produktionsumgebung mit den aktuellen Daten:
- Konfigurieren von Cloud SQL für die Produktionsumgebung
- Datenmigration und anschließende Validierung der Migrationsergebnisse
- Leistungstests und KPI-Überprüfung
- Konfiguration von Sicherungsrichtlinien, Wiederherstellungstests
- Umschaltung des Datenverkehrs des Systems auf die Cloud-SQL-Datenbank.
Lassen Sie uns gemeinsam finanzielle Erfahrungen im Finanzsektor leicht und angenehm gestalten.
Sagen Sie uns, was Sie brauchen, und wir werden uns umgehend mit Ihnen in Verbindung setzen.