In 50 Tagen von IBM zu Open Source

Transkript

1 In 50 Tagen von IBM zu Open Source Migration einer 1,5 MLOC Anwendung von WebSphere nach JBoss Martin Weber akquinet Zu meiner Person : Leiter der Anwendungsentwicklung : Geschäftsleitung Tech&Spree Engineering GmbH Seit 2008: Geschäftsführer der akquinet tech&spree GmbH 2 1

2 Unsere Kompetenzen Business Consulting JAVA SAP Microsoft /.NET Outsourcing JAVA Business Solutions JBoss Websphere OSGi Mobile Solutions Android iphone Mobile Web Innovative Solutions User Experience Analyse Konzeption Open Source 3 Das Wesen einer Erfolgsgeschichte

3 5 Kanalreinigungsaufträge Schilder beantragen GIS Schilder konkretisieren Schildergenehmigung Arbeitsvorbereitung Auftragsarchiv Schilder stellen Schilder abräumen Mobile Device Kanalreinigung Zustandsrückmeldung KN DB 6 3

4 Reinigungsaufträge zusammenstellen 7 UBI Auftragszusammensteller 8 4

5 Schilder beantragen 9 UBI Schilderantragsteller 10 5

6 Einsatzplanung 11 UBI Einsatzplaner 12 6

7 Auftragsrückmeldung 13 UBI Mobiler Rückmelder (Zustand+Zeiten) 14 7

8 UBI Architektur (grob) Desktop Synchronisation HTML- Client Mobile Client Servlets UBI-Services SAP DB/2 Datenbank GIS 15 Die technische Ausgangssituation UBI Individualsoftware auf Basis der Java Enterprise Edition EJB 2 als Komponentenmodell, Swing Clients, Web Clients eigener O/R Mapper Strategische Ausrichtung auf IBM E Series AIX als Betriebssystem WebSphere als Applikationserver DB2 als RDBMS Weiterentwicklung In House auf Standardrechnern kein App.server pro Entwickler IBM Entwicklungsumgebungen kaum lauffähig 16 8

9 Stein des Anstoßes Ineffiziente Entwicklungsumgebung Deployzeiten > 10 Minuten (Workaround mit MockEJB) unzufriedene Entwickler geringe Produktivität => frühzeitiger Wunsch auf JBoss zu wechseln... Auslöser: Wechsel von Websphere 5.1 auf 6.x (Umstieg auf Java 5...) Klientenlaufzeitumgebung war nach 3 Monaten auch mit offiziellem Support von IBM in der Kundeninfrastruktur nicht lauffähig => Freigabe für JBoss in.org Version 17 Die grobe Migrationsstrategie Pilot mit minimalem Risiko klein nicht in Entwicklung mit engen Deadlines Sammeln der Erfahrungen Richtlinien, Architekturen Referenzbeispiele Parallele Migration der restlichen Projekte 18 9

10 Der erste Kandidat Die Ablesesteuerung Fachlichkeit Ablesen über SMS Abrechnung in SAP Visualisierung über Web Anwendung Größe: 150 TLOC Projektstand: Modernisierung geplant (EJB3, JPA, Maven) 19 ALS Migration von WebSphere => JBoss War einfach... Anlegen einer Data Source Migration der EJB 2 Komponenten Erweiterung von XDoclet Konfiguration bei JMS Änderung der XDoclet Konfiguration in Ant für JBoss Erstellung eines SVN basierten Konfigurationsmanagements (E, Q, P) Vereinfachung des Klienten (Keine WebSphere Laufzeitumgebung) Aufwand: 9PT 20 10

11 Hat es was gebracht? Aussagen der Projektleitung geschätzte 20 30% Geschwindigkeitszuwachs während der Implementierung Aus dem Controlling in der Iteration nach der Modernisierung bis zu 15% unter der Schätzung => also ganz ok, Zufriedenheit der Entwickler hat sich erhöht 21 Dann weiter Parallele Migration in Teilprojekten: WV, KM, NAB, AV Sperrungen 645 TLOC => 27 PT AE 579 TLOC => 25 PT UZI 78 TLOC => 4 PT 22 11

12 Ein paar Herausforderungen Isolation der Anwendungen eigenes loader-repository pro Anwendung reicht nicht JNDI benötigt CallCyCalue=true Ausschalten der CallByValue Optimierung bei Remote Zugriffen WebSphere benutzt IBM JRE Anpassung für Ausdruck von Grafiken => nichts Gravierendes 23 Alles gut? 7 Wochen im Testbetrieb mit echten Anwendertests => Transport in den Produktivbetrieb 24 12

13 ... Probleme im Produktivbetrieb Speicherüberlauf im Server nach 4 Stunden schon vorher deutliche Verlangsamung massive Störung des Betriebs Rücksetzen auf die alte Anwendung war nicht mehr möglich => : ( 25 Prio 1: Betrieb ermöglichen Prio 2: Fehleranalyse 26 13

14 Das Wesen einer Katastrophe ist das gemeinsame Wirken mehrerer Fehler. Bei UBI: Einführung eines Keep Alive Job aufgrund von JMS Problemen => führte zu massivem Speicherverbrauch => erstmal entschärft => Anwendung hielt etwas länger Weitere Hinweise auf Probleme mit JBoss Remoting (viele technische Objekte im Speicher) Aufdecken inkompatibler Bibliotheken durch teilweise Versionsaktualisierung (Orientierung an EAP half => Wechsel auf EAP beschlossen) bei Messaging Update wurde jboss client all.jar vergessen => Anwendung hielt > 1 Tag durch, lief aber immer noch voll 27 Danach in Ruhe die Fehleranalyse und Behebung... 4 Tage Analyse von 2 Kollegen im Pair mit Ergebnis: Firewall schluckte nach 1h Inaktivität TCP Verbindung ohne Benachrichtigung an Sender/Empfänger Standardkonfiguration von JBoss Remoting erkennt dies nicht Lösung: angepasste Konfiguration von Remoting => keine Probleme mehr 28 14

15 Die Pointe Wahrscheinlich hatte WebSphere die gleichen Probleme Reaktion von WebSphere war aber: Leises Vollaufen der internen JMS Puffer, bis das System stand Praktizierte Lösung: regelmäßiges Löschen über die Kommandozeile Open Source hat Vorteile, Ähnliches Debugging ist bei WebSphere nicht möglich 29 Und die Moral von der Geschichte... 15

16 Unsere Erkenntnisse Voraussetzung für Migration (= kein Lock In) Einsatz von Standards (JEE) und/oder Open Source (Ant/Maven statt WSAD, Einsatz migrierbarer Bibliotheken) Aufwandsgünstige Migration einer JEE Anwendung ist möglich. (0,06 PT 30 min für LOC) Bereitschaft für Überraschungen ist notwendig. 31 Vorteile der Open Source Migration Kein Vendor Lockin 100% Standard Java Enterprise Edition unabhängig Neue Releases schneller verfügbar Geringere Betriebskosten Keine Lizenzkosten Preiswerte Subscription (4.400, ) statt Lizenz Kostenlose Community Edition für Prototypen günstig Schlankere Anwendung Betrieb vereinfacht Höhere Produktivität Leichtere Problemlösungen möglich dank Open Source effizient Erhöhung der Entwicklungsproduktivität um ca. 20% Time to Market deutlich verkürzt 32 16

17 33 17