Redstack complete – Microservices mit FMW und Exalogic

Ein SCA (auch als Composite bezeichnet) ist eine eigenständige, in der Oracle SOA Suite (Service-Oriented Architecture) [3] installierbare Einheit. Composites können unabhängig voneinander entwickelt, ausgeliefert und skaliert werden. Somit erfüllen sie wesentliche Eigenschaften von Microservices. Die Oracle SOA Suite stellt die Laufzeitumgebung für Composites zur Verfügung. Composites können unabhängig voneinander überwacht und administriert werden. Über sog. Partitionen in der SOA Suite können Composites beispielsweise nach fachlichen Gesichtspunkten gruppiert werden. Zusätzlich ermöglichen Partitionen auch eine Priorisierung hinsichtlich Laufzeitaspekten von Composites. Als zugrundeliegende Infrastruktur nutzt die SOA Suite den Oracle WebLogic Server [4]. Die Priorisierung von Applikationen und Services wird im WebLogic Server über sogenannte Work Manager zur Verfügung gestellt. Work Manager können Partitionen in der SOA Suite zugewiesen und individuell konfiguriert werden.

Es bietet sich somit an, einzelne Microservices in Form eines Composites zu implementieren. Ein Microservice kann beispielsweise ein Dienst sein, der einfache CRUD-Operationen auf einer isolierten Produktdatenbank anbietet. Zur Umsetzung des Dienstes können in der Oracle SOA Suite Komponenten wie der Datenbank Adapter und ein Mediator (Komponente für Routingaufgaben) genutzt werden. Die entwickelten Microservices können über verschiedene Schnittstellentechnologien angeboten werden, z. B. in Form einer REST- oder SOAP-Schnittstelle (s.Abb.2).

Für die Umsetzung komplexerer Logik bietet die SOA Suite eine Vielzahl von zusätzlichen Komponenten an, die bei der Implementierung nützlich sein können, z. B.

• EJB und Spring Beans zur Nutzung und Integration von Java,
• Business Rules für die Verwaltung und zur Laufzeit änderbarer Geschäftsregeln,
• BPEL Engine für die Koordination von Services,
• Event Delivery Network zum Senden und Empfangen von Ereignissen.

Vor allem in der Integration mit anderen Microservices kann die SOA Suite sehr hilfreich sein, durch Nutzung der vielzählig verfügbaren Adapter oder über REST/SOAP Integration.

Erfahrungsbericht aus einem Kundenprojekt

Als ein führendes Unternehmen im Bereich der Informationsdienstleistung in Deutschland die Entscheidung gefällt hatte, eine neue Hard- und Softwareinfrastruktur auf Basis des Oracle "Redstacks" einzuführen, begann ein neues Informationszeitalter mit vielen (neuen) Herausforderungen.

In diesem Projekt wurde keine einfache Modernisierung einer Plattform oder eines Systems geplant, sondern viel mehr ein kompletter Wechsel der Hardware, Software und Technologie-Lieferanten durchgeführt. Mit Erneuerung der gesamten Infrastruktur wurde ferner ein strategisches Programm zur Modernisierung der Systemlandschaft aufgesetzt. Auf Basis der Oracle Fusion Middleware mit SOA-Produkten wurde eine "Microservice-basierte" Architektur für die neue Anwendungslandschaft definiert. Neben den technologischen Herausforderungen, wurde Scrum als Projektmethodik neu im Unternehmen verwendet. Im Rahmen des Projektes mussten viele technologische und zwischenmenschliche Herausforderungen gemeistert werden.

Ausgangslage

Im Rahmen einer Vorstudie wurde ein neues Konzept für ein neues Verfahrens- und Informationsmodell erstellt, das die Wettbewerbsfähigkeit des Unternehmens für die Zukunft sicherstellen soll. In der Vorstudie wurde folgendes Ergebnis festgehalten:

• Die bestehende IT-Anwendungslandschaft ist historisch gewachsen und hat den "End of Lifecycle" erreicht.
• Die Landschaft ist sehr komplex und geprägt durch inhomogene und unnötig redundante Komponenten.
• Das Datenmodell erfüllt die heutigen und zukünftigen Anforderungen nicht und ist nicht ausbaufähig.
• Die Komplexität der heutigen IT-Anwendungslandschaft erfordert hohe Aufwände bei der Weiterentwicklung der Systeme.
• Entwicklungsmodell und die derzeitig eingesetzte Technologie bedingen eine hohe Time-to-Market.

Daraus wurden folgende Ziele abgeleitet:

• Umsatzsicherung in den Kernprodukten.
• Zusätzlichen Umsatz durch neue und weiterentwickelte Produkte generieren.
• Kosteneinsparungen durch vollautomatische Prozesse.
• Höhere Daten- und Prozessqualität.
• Zeitnahe Umsetzung von Anforderungen aus Markt und Öffentlichkeit.
• Geringerer Aufwand für Wartung und Pflege der Systeme.

Als konkrete Maßnahme zur Umsetzung, wurde der Neubau der IT-Anwendungslandschaft beschlossen. Das hier vorgestellte Projekt hat im Rahmen der Neuausrichtung das Ziel, einen großen Teil der bestehenden Verarbeitungssysteme zu ersetzen und zu modernisieren. Als erstes Projekt soll das System auf der neuen Technologie-Plattform, bestehend aus Oracle Engineered Systems und Fusion Middleware mit SOA-Produkten, implementiert werden. Nachfolgende technischen Ziele sollten erfüllt werden:

• "Flexible" Architektur.
• Schnellere Bereitstellung von Releases.
• Keinen Monolithen: Möglichkeit, nur das bereitzustellen, was wirklich geändert wurde.
• Aufwände für das Testen von Releases minimieren.

Architektur

Der Kunde definierte unterschiedliche Qualitätsziele, die das Projekt im Architekturentwurf berücksichtigen musste. Insbesondere mehr Flexibilität in der Erweiterung des Datenmodells oder fachlichen Funktionalitäten, musste der neue Architekturentwurf vorsehen. Die Bereitstellung von neuen Produkten für Kunden und Lieferanten sollte erheblich schneller als in der Vergangenheit erfolgen. Durch Reduzierung von Komplexität und Abhängigkeiten zu Systemkomponenten wurde das Ziel verfolgt, eine schnellere Einarbeitungszeit für neue Entwickler zu gewährleisten. Zusätzlich musste der eingekaufte Technology-Stack von Oracle in der Architektur berücksichtigt und optimal genutzt werden. Um die Architekturziele zu erreichen, wurden Microservices als Lösungsansatz in Betracht gezogen. Eine wichtige Fragestellung in diesem Zusammenhang war, die Möglichkeiten zu prüfen, einen solchen Architekturansatz mit Oracle-Technologie umzusetzen.

Eine wichtige Anforderung im Projekt bestand darin, die Anwendung nicht als Monolith bereitzustellen. Idealerweise sollten Systembestandteile unabhängig voneinander entwickelt, getestet und austauschbar sein. In der Vergangenheit führten selbst kleine Anpassung dazu, das gesamte System erneut zu installieren und durch einen aufwändigen Integrationstest zu prüfen. Darüber hinaus, folgt die grundsätzliche Anwendungslogik, einem standardisierten Verarbeitungsprozess mit wenigen Varianten. Nachfolgend wird die konkrete Microservice-basierte Architektur für das neue System dargestellt.

Prozessschritt

Der Prozessschritt (PS) ist ein zentraler Baustein in der Architektur und entspricht im eigentlichem Sinne einem Microservice. Er stellt eine konkrete fachliche Funktion zur Verfügung. Er kann unabhängig von weiteren PS entwickelt, getestet, versioniert, installiert und überwacht werden. Er kennt keine Abhängigkeiten zu andern PS. Der PS stellt eine Schnittstelle zur Verfügung, die ausschließlich unter fachlichen Gesichtspunkten entworfen wurde. Mit den bereitgestellten Daten erfolgt die Verarbeitung entsprechend den fachlichen Anforderungen. Sofern erforderlich, steht dem PS eine eigene Datenhaltung zur Verfügung. Zur Verwaltung von Daten wurde im Projekt eine Oracle-Datenbank verwendet. Somit wurde bei Bedarf für jeden PS ein eigener Benutzer (Schema) in der Datenbank erzeugt. In den Entwicklungsvorgaben wurde festgelegt, dass Zugriffe auf die Informationen in der Datenbank ausschließlich über den jeweiligen PS erfolgen dürfen. Ein direkter Zugriff, auch innerhalb der Datenbank, z. B. über PL/SQL oder Datenbank-Links, etc. wurde strikt verboten.

Ein PS wurde im Projekt immer als SCA implementiert und in der SOA Suite zur Ausführung gebracht. Innerhalb des SCA wurde die Implementierung mit Java EE und ggf. weiteren Frameworks und Systemen, z. B. Suchmaschinen, ergänzt. Theoretisch erlauben Microservices die Nutzung unterschiedlicher Technologien, jedoch wurde im Projekt zwecks Standardisierung darauf geachtet, die gleichen Technologien einzusetzen. Beim Kunden vor Ort werden Applikationen vorwiegend mit Java EE entwickelt und betrieben. Die Technologie ist bekannt und sichert so kurze Einarbeitungszeiten von neuen Kollegen im Projekt. Ferner wurde im Projekt festgelegt, das ein PS nicht direkt andere PS aufrufen darf. Das entspricht nicht unbedingt dem Grundgedanken von Microservices, jedoch wurde die Verbindung von Microservices in diesem Projekt anders gelöst (s. Verarbeitungsstraße weiter unten).

Arbeitsschritt

Je nach "Größe" und fachlichem Schnitt, kann ein PS in weitere Bestandteile, sog. Arbeitsschritte (AS), zerlegt werden. Auch im Bereich Microservice ist das ein oft diskutiertes Thema. Vor allem was bedeutet "micro" im Detail und wie wirkt sich das auf die technische Umsetzung aus? Im Projekt wurden ausschließlich fachliche Kriterien für die Unterteilung in verschiedene PS herangezogen. Ein Arbeitsschritt erlaubt nun eine Unterteilung innerhalb eines PS. AS sind nach "Außen" nicht sichtbar und können auch nur innerhalb eines PS verwendet werden. Im Projekt wurden AS vorwiegend als Session-EJBs implementiert.

Verarbeitungsstraße

Wie zuvor erwähnt, erfolgt die Verarbeitung der eingehenden Daten nach einem genau definierten Prozess mit wenigen Varianten. Die Orchestrierung der einzelnen PS im Rahmen des fachlichen Verarbeitungsprozesses, wird durch eine sog. Verarbeitungsstraße (VS) sichergestellt und überwacht. Die VS wurde ebenfalls als SCA mit der Komponente BPEL in der SOA Suite umgesetzt. Mit BPEL können Prozessabläufe automatisiert werden. Die Verarbeitungsstraße stellt die fachlich korrekte Aufrufreihenfolge der PS sicher. Auch Fallunterscheidungen anhand von Verarbeitungsergebnissen einzelner PS wird durch eine VS durchgeführt. Die Koordination der Fehlerbehandlung und eventl. durchzuführende Kompensationen sind ebenfalls Aufgaben einer VS. Mit dem Audit Trail in der SOA Suite kann der Ablauf einer VS inkl. der PS jederzeit überprüft werden. Somit kann die Verarbeitung von Nachrichten jederzeit nachvollzogen werden. Nachvollziehbarkeit war beim Kunden ein sehr wichtiger Gesichtspunkt. Auch wenn die Nutzung einer Prozessengine im Umfeld von Microservices kontrovers diskutiert wird [5], hat sich der Einsatz in diesem Projekt bewährt. Als Alternative hätte die VS auch auf Basis des Event Delivery Networks (EDN) in der SOA Suite implementiert werden können. Diese Alternative wurde aber aufgrund der hohen Performanceanforderungen nicht gewählt.

Ein wichtiger Aspekt im Projekt war die Protokollierung und fachliche Nachvollziehbarkeit einer Nachrichtenverarbeitung. Aus diesem Grund wurde das Konzept einer Prozessnachricht (s.Abb.4) in der Verarbeitung etabliert. Die Prozessnachricht besteht immer aus einem Header- und einem Datenanteil. Im Header werden alle Informationen transportiert, die für eine Protokollierung und Steuerung der Verarbeitung erforderlich sind. Daten im Header werden durch die einzelnen PZ zur Verfügung gestellt. Im Datenbereich wird das konkrete fachliche Datenmodell zur Verfügung gestellt. Das Datenmodell enthält immer die konkreten Fachobjekte, die vom jeweiligen PZ benötigt werden.

Mit Oracle Business Activity Monitoring (BAM) werden vom Fachbereich definierte Kennzahlen in anschaulichen Dashboards zur Verfügung gestellt. Die Kennzahlen werden aus dem Header-Bereich der Prozessnachricht entnommen und regelmäßig asynchron an BAM übertragen. BAM wurde in einer eigenen Infrastruktur betrieben und es wurde darauf geachtet, die eigentliche Verarbeitung durch das Schreiben von Events an BAM nicht zu beeinträchtigen.

Engineered Systems

Als Runtime-Umgebung stand für die Middleware ein Oracle Engineered System mit einer Exalogic-Maschine pro Rechenzentrum zur Verfügung. Die beiden Exalogic-Systeme waren identisch aufgebaut und wurden in einem Aktiv/Passiv-Modus betrieben. Sobald ein Knoten oder das gesamte Rechenzentrum ausfallen würde, übernimmt der Knoten im zweiten Rechenzentrum die Arbeit. Die beiden Systeme waren so aufgebaut, dass die geforderte Last jeweils von einem Knoten problemlos getragen werden konnte. An den Exalogic-Systemen war ein externes ZFS-Filesystem angebunden, das in regelmäßigen Zeitintervallen die Synchronisation der Filesysteme durchführt. Aufgrund von technischen Limitierungen konnte das Zeitintervall der Synchronisation nicht so klein eingestellt werden, um eine hohe Ausfallsicherheit zu gewährleisten. Insbesondere bei Queues, die Inhalte in das Filesystem speichern, musste das im Systemdesign berücksichtigt werden. In diesem Fall musste die Synchronisation über die Datenbank sichergestellt werden. Die Datenbank wurde fast synchron über Oracle Data Guard in das entfernte Rechenzentrum synchronisiert.

Auf einer einzelnen Exalogic wurden mehrere WebLogic (WLS)-Domänen mit Clustern von bis zu 6 Managed Servern konfiguriert. Die Verteilung der Last auf die verfügbaren Managed Server, wurden durch den Oracle Traffic Director [6] durchgeführt. Ein Software Loadbalancer von Oracle, der für die Exalogic-Systeme optimiert ist. Es wurde jeweils eine WebLogic-Domäne für die SOA Suite, BAM und Java EE konfiguriert. Aufgrund von unterschiedlichen Last- und Performanceanforderungen wurde diese Aufteilung gewählt. VS und PS wurden in der WLS-Domäne mit der SOA Suite betrieben. Aufgrund hoher Last- und Performanceanforderungen, wurden viele Möglichkeiten der Optimierung in der SOA Suite für die einzelnen PS herangezogen, um das System optimal einzustellen. Insbesondere die Exalogic Optimizations im WLS- und JPA-Umfeld, Threads, Timeout-Settings, etc. wurden "getuned".

In der Verarbeitung von Batchnachrichten konnte das System sein Leistungspotential aufzeigen. Das geforderte Datenaufkommen von mehr als 80 Mio. Nachrichten konnte im geforderten Zeitrahmen (mehrfach) erfolgreich verarbeitet werden.

Fazit

Zu Beginn des Projektes wurde der Aufwand für die Einführung der verschiedenen Neuerungen unterschätzt. Die Nutzung eines völlig neuen Technologie-Stacks in der Entwicklung, mit neuen Werkzeugen und Arbeitsweisen, erfordert Einarbeitungszeit und Lernbereitschaft. Insbesondere der Aufbau und die Nutzung der Engineered Systems stellte den Betrieb vor einige Herausforderungen. Das hatte natürlich auch erheblich Auswirkungen auf Entwicklung und Architektur. Im Last- und Performancetest, konnte der Technologie-Stack allerdings sein Leistungspotential zeigen. Zusätzlich verlangte auch die Einführung der agilen Methode Scrum den Entwicklern einiges ab. Gewohnte Arbeitsweisen mussten verändert werden. Die Entwicklertätigkeit wird durch User Stories und Taskboards transparenter. Zusätzlich wird Feedback zur geleisteten Arbeit wesentlich früher mitgeteilt (Review). Die Nutzung einer Microservice-basierten Architektur erfordert bei Entwicklern ein Umdenken in der täglichen Arbeitsweise. Die strikte Kapselung und unbedingte Vermeidung von Abhängigkeiten, waren häufig der Anlass für Diskussionen und Erklärungsbedarf.

Insgesamt bleibt festzustellen, dass die Technologie selten das eigentliche Problem in einem Projekt darstellt. Vielmehr ist der Faktor Mensch entscheidend! Die Projektmitglieder müssen entsprechend auf die Veränderungen und Neuerungen vorbereitet werden. Insbesondere muss die notwendige Zeit den Projektmitgliedern zugestanden werden. Dann steht einem positiven Projektverlauf – auch mit vielen Neuerungen – nichts mehr im Wege!