Im Zuge der voranschreitenden Digitalisierung werden Projekte im Umfeld der API-Economy immer wichtiger. Die Umsetzung solcher Projekte hat in der Regel enorme Auswirkungen auf das gesamte Unternehmen. Vor allem vor dem Hintergrund, dass es im Grunde in jedem Unternehmen sog. Legacy-Systeme gibt, die integriert werden müssen, denn kaum ein Unternehmen im Bereich der Financial Services hat den Vorteil, auf der grünen Wiese starten zu können.
Durch den Schwenk von Legacy-Systemen, die eher monolithisch aufgebaut sind, hin zu Microservices kommen weitere Herausforderungen auf die Projekte zu. Die weitreichenden Auswirkungen erstrecken sich von technischen Herausforderungen verbunden mit der Neuausrichtungen der Softwarearchitektur bis hin zu Konsequenzen bzgl. Betriebsführung und organisatorischen Veränderungen. Im Grunde bleibt hier im Unternehmen kein Stein auf dem anderen.
Wir wollen in dieser Session zeigen, welche Fragestellungen exemplarisch auftreten können und welche Lösungsalternativen diskutiert werden müssen. Dabei werden wir auf die organisatorischen und die technischen Problemfelder in Verbindung mit der veränderten Softwarearchitektur genauer eingehen. Am Ende der Session sollten die Teilnehmer ein Gespür dafür bekommen, wo die Herausforderungen bei solchen Projekten liegen.
Microservices mit Java EE - am Beispiel von IBM Liberty
API-Economy bei Financial Services – Kein Stein bleibt auf dem anderen
1. API-Economy bei Financial Services
Kein Stein bleibt auf dem anderen
Michael Hofmann
Hofmann-IT Consulting
Robert Runggatscher
Allgemeines Rechenzentrum GmbH
4. Core Banking System
Entstanden im „letzten Jahrtausend“
Mehrere 100 bzw. 1000 PT
Ältere Architektur-Paradigmen
Kein Fokus auf API (Bank-Mitarbeiter)
Einstellige Anzahl Releases/Jahr
5. Architektur-Paradigmen von damals
Client-Server, Mainframe (Batch, Online)
Monolith
Starre Laufzeitumgebung
Enge Kopplung (verteilte Transaktionen)
Stateful Server
Coarse-Grained Interfaces
Role Based Access Control (RBAC)
7. Vorhandene APIs im CBS
SOAP
Technische API
viele Parameter
funktions-orientiert
Expertenwissen beim Aufrufer vorhanden
Keine REST API
Konsequenz: neue APIs!
19. „Alter“ des CBS
Liste der technischen Schulden
Klassische Findings
Business Logik im Client Layer (JSF, Struts, MVC) fehlt somit im
REST-Endpoint
Business Logik mit Variationen mehrfach vorhanden
Eigene Implementierungen die Marktstandards verhindern
Höhere Release-Frequenz möglich?
20. CBS und neue Architektur
CBS Schnittstellen
Funktionsorientiert
ohne Unterteilung
eigene Datenelemente
keine HTTP Status Codes
Fehlertexte (Datenschutz)
Idempotenz
Stateless
Verteilte Transaktionen
GUI-Layer und REST-Layer
21. CBS und API Anforderungen
Verändertes Lastverhalten
Anbindung API an CBS: synchron/asynchron
PaaS / Cloud
Templating (Produktkatalog)
Zwischenspeicherung
Orchestrierung oder Choreografie
22. CBS und API Anforderungen
Neue Systeme
API Gateway
Service Registry
PaaS
...
Security
Access Control List
OAuth/OpenId Connect
Security Propagation
Zugriffsrechte (CBS vs. API Layer)
23. CBS und API Anforderungen
Verteiltes System
Service Mesh (Istio)
Konfiguration der Services
Resilienz
Traceability
Health
Metrics
24. REAL CHANGE only happens when you WANT IT,
and WANT IT A LOT MORE THAN YOU FEAR IT,
and want it a lot more than you FEAR
STAYING RIGHT WHERE YOU ARE NOW.
Until then, you will only commit to the level of
DIPPING YOUR TOE in the deep end of the
„CHANGE POOL“ and lie to yourself that this
PROVES you are at least TRYING TO CHANGE.
NO, YOU ARE NOT!
Der Change als Herzstück
fitbeliever.tumbler.com Scott Abel