Seite 2: Nutzen und Risiken

Inhaltsverzeichnis

Nutzen

Die Wahl der Open-Source-Lösung ermöglichste den Wechsel auf eine neue, deutlich preisgünstigere und gut skalierende Hardware- und Betriebssystemumgebung. Zudem kann man aufgrund der niedrigen Kosten die Linux-Blades in Produktion, Abnahme und Entwicklung identisch halten. Das macht es möglich, frühzeitig Performance- und Auslastungsaussagen zu treffen und Ressourcen umzuverteilen. Aus der günstigeren Hardware und den eingesparten Lizenzkosten resultierte ein ROI von unter drei Jahren.

Der wichtigste Aspekt im Projekt war allerdings, durch die Nutzung offener Standards eine Austauschbarkeit der Komponenten zu erreichen und aus den Quelltexten der eingesetzten Open-Source-Projekte ein besseres Verständnis der Plattform bei der Implementierung der eigenen Anwendungen zu erreichen.

Risiken

Allerdings birgt der Einsatz von Open-Source-Software auch spezielle Risiken. Der größten Gefahr – auf eine Lösung zu setzen, die mittel- oder langfristig nicht mehr von einer Community gepflegt und weiterentwickelt wird – begegnete man durch die Wahl eines Tools mit einer breiten Community und einem technisch hoch entwickelten Softwarestand.

Damit blieben noch zwei Herausforderungen: Zum einen tritt früher oder später immer das Problem auf, zusätzliche Features zu benötigen, die das Projekt möglicherweise nicht übernimmt. Dem muss man durch Maßnahmen im Entwicklungsprozess und durch ausreichende Dokumentation Rechnung tragen. Die Empfehlung hier kann nur lauten, möglichst wenige eigene Erweiterungen vorzunehmen.

Die zweite Herausforderung ist der Aufbau eines Inhouse-Releasemanagement: Bei Open Source muss intern geprüft werden, welche Komponenten in welcher Version lauffähig sind und wie sich ein Update auf den bestehenden Code und die Anwendungen auswirken wird.

Die Migration

Mit dem Ergebnis des Proof of Concept und dem Businessplan für die Migration und den späteren Betrieb fiel schließlich die strategische Entscheidung für die Durchführung der Migration durch den Vorstand der Union Investment Gruppe und die Geschäftsführung der Union IT Services GmbH: Das Migrationsprojekt OSIRIS (Open Standards Integrationsinfrastruktur) war geboren. Auf der Grundlage von über einem Jahr Forschungsarbeit bis zum Startzeitpunkt im April 2007 war ein vollständiger Migrationsplan für die bestehenden EAI-Anwendungen mit den notwendigen Vorarbeiten (etwa der Erstellung von neuen Basiskomponenten) und Testszenarien schnell erstellt.

Eine wichtige Grundprämisse dabei war, den Testaufwand in den Fachbereichen durch eine Eins-zu-eins-Migration der alten kommerziellen Lösung so gering wie möglich zu halten, indem möglichst viele selbst erstellte Java-Komponten der alten Plattform über geeignete Kapselung direkt in die neue Zielumgebung migriert und bestehende Transformationen (zumeist XSLT oder Java-Code) ohne Änderung übernommen wurden.

So konnte die produktive EAI-Landschaft als Referenzumgebung für Testfälle auf der neuen Plattform dienen, was den Abnahmeaufwand für die Fachbereiche auf ein Minimum beschränkte. Das ließ sich bei etwa 80 Prozent der Anwendungen umsetzen.

Die Migrationsplanung berücksichtigte die bereits geplanten fachlichen Projekte und die davon betroffenen EAI-Systeme, um die Weiterentwicklung der Fachanwendungen nicht zu behindern. Zudem ließen sich so bereits eingeplante Tests und Ressourcen mitnutzen, indem die Änderungen unmittelbar in der Zielarchitektur erfolgten.

Bei der Migration stand für jedes System eine Fallback-Option bereit:

• Anwendungen, die ohne Änderung migriert wurden, konnten bis zur Behebung eventueller Probleme wieder auf dem Altsystem zu starten.
• Änderungen während oder kurz vor der Migration wurden über das Change-Management verfolgt. Betroffene Anwendungen wurden teilweise doppelt auf dem Altsystem und dem neuen System implementiert.
• Änderungen, die für kurz nach der Migration anstanden, wurden ausschließlich in der neuen Technologie umgesetzt, um eine doppelte Implementierung und insbesondere doppelte Tests zu vermeiden.

Durch die frühzeitige Planung und die Einbeziehung der laufenden Projekte ließen sich "Frozen Zones" weitgehend verhindern oder durch etwas Umplanung und Umpriorisierung beide Belange – Projektziel und Migrationsziel – berücksichtigen. Das auf 14 Monate geplante Migrationsprojekt konnte mit wenigen Wochen Verspätung erfolgreich abgeschlossen werden.

Release-Planung

Eine besondere Herausforderung des Open-Source-Ansatzes ist die Planung zukünftiger Releases der Basisinfrastruktur. Anders als beim Einsatz eines Lizenzproduktes, das als Paket ausgeliefert und installiert wird, besteht die hier vorgestellte Zielarchitektur aus einer Reihe von unabhängig entwickelten Open-Source-Komponenten, die zwar nach den bisherigen Erfahrungen reibungslos zusammenarbeiten, für die sich aber bei Bugfixes, dem Austausch oder Upgrade einer Komponente sofort die Frage nach dem erforderlichen Testaufwand und möglichen Risiken stellt.

Um auch hier so pragmatisch wie möglich vorzugehen, wird zwischen verschiedenen Szenarien unterschieden:

• Eine Basiskomponente ändert sich aufgrund von Bugfixes oder funktionalen Erweiterungen: In diesem Fall bewertet ein Architekturgremium, wie hoch das Risiko für die Anwendungslandschaft ist. Je nach Risiko können dann vor dem Ausrollen der Komponente zusätzliche Tests veranlasst werden.
• Eine funktionale Erweiterung oder der Ersatz einer Komponente oder Library läßt sich nicht abwärtskompatibel umsetzen: Auch hier führt das Architekturgremium eine Impact-Analyse durch, bei der die erforderlichen Modifikationen an Anwendungen bewertet werden. Typischerweise sind vor dem Rollout dann mindestens Lasttests, stichprobenartige fachliche Tests oder der Einsatz von vorhandenen Regressionstests erforderlich.
• Ein Technologiewechsel macht Änderungen an der Implementierung von Anwendungen erforderlich: In diesem Fall ist eine erneute fachliche Abnahme unvermeidlich. Im günstigsten Falle gelingt die zeitliche Synchronisation mit einer neuen Fachbereichsanforderung oder einem neuen fachlichen Projekt, sodass sich der Testaufwand bündeln lässt.

Das Ziel in allen diesen Fällen ist es, für eine größtmögliche Stabilität der Basisinfrastruktur zu sorgen und die Auswirkungen auf die Fachbereiche so gering wie möglich zu halten. Vorteilhaft ist dabei, dass durch den breiten Einsatz freier Software die erforderliche Planungsfreiheit gegeben ist.

Application Server und ESB

Wie schon erwähnt, kommt als J2EE-Server der JBoss Application Server in der Version 4.0.4.GA zum Einsatz. Für den Enterprise Service Bus fiel die Entscheidung auf die freie JBI-Implementierung ServiceMix in der Version 3.1, die inzwischen als Apache-Projekt verfügbar ist. Dabei stellt JBoss das JMS Messaging, den Transaction Manager sowie die Verbindung zu den Datenbanken und dem Hostsystem bereit. ServiceMix liefert den JBI-Container, in dem die eigentlichen Anwendungen und Prozesse ablaufen.

Die Gesamtarchitektur weicht damit von einem klassischen J2EE-Szenario mit Webanwendung und EJB ab: Während bei einer Webfarm im Prinzip alle Komponenten gleichberechtigt auf allen JBoss-Knoten laufen, betreiben die JBI-Container, die unabhängig voneinander auf jedem JBoss-Node laufen, nur jeweils eine bestimmte Anwendung oder einen Teilprozess. Das liegt zum einen daran, dass die JBI-Komponenten (JBI Binding Components), die Daten von Randsystemen abholen, nur einmal im Cluster laufen dürfen; zum anderen darf durch Anforderungen wie Reihenfolgetreue beim Übertragen von Daten ebenfalls nur eine Instanz der Anwendung die Daten verarbeiten.

Hardware

Alle Systeme des gesamten Entwicklungszyklus (von der Entwicklungsumgebung bis zur Produktion) laufen auf der gleichen Hardware, und zwar auf Blades in Bladecentern, die in zwei Rechenzentren ausfallsicher verteilt sind. Jede der Blades verfügt über jeweils zwei Doppelkern-Opteron-Prozessoren von AMD und acht Gigabyte Hauptspeicher. Als Betriebssystem kommt Red Hat Enterprise Linux 4 zum Einsatz.

Damit sich mehrere Blades zu einer Abnahme- oder Produktionsumgebung zusammenführen lassen, sind alle Rechner an ein Network Attached Storage (NAS) angeschlossen und die Daten in beiden Rechenzentren ausfallsicher gespiegelt. Dieses zentrale Dateisystem wird auch für die Installationen und Deployments genutzt, indem alle JBoss-Knoten auf allen Servern dieselbe Konfiguration starten. Damit sind alle Objekte, die per Dateikopie in das Deployment-Verzeichnis der Installation gelegt werden, sofort für alle JBoss-Knoten verfügbar.

Nun lässt sich einfach festlegen, auf welchem Node eine Anwendung laufen soll. Damit die einzelnen Anwendungen auch beim Ausfall eines JBoss-Knotens möglichst unabhängig voneinander laufen können, werden, anders als in einem klassischen Web-Application-Szenario, auf einem Rechner mehrere JBoss-Nodes gestartet.

Mit diesem Aufbau ist grundsätzlich eine wesentliche Anforderung an die EAI- und SOA-Infrastruktur erfüllt, da sich bei steigendem Lastbedarf einfach neue Blades zu dem Cluster hinzugefügen lassen.