Cloud

Anwendungsmodernisierung mit Einblick

Share this post:

Anwendungsmodernisierung mit Einblick

Ihre bestehenden Anwendungen sind nicht mehr agil genug und Sie möchten sie modernisieren? Doch wie soll das gehen, wenn Ihre Anwendungen über viele Jahre gewachsen sind und die Entwickler nicht mehr verfügbar sind? Das geht vielen Unternehmen so. In diesem Blog zeige ich Ihnen, wie Sie mithilfe von IBM Lösungen den benötigten Einblick in Ihre Anwendungen erhalten und somit basierend auf Fakten eine Modernisierungsstrategie entwerfen können.

Warum modernisieren?

Geschäftliche Anforderungen erfordern eine immer schnellere Markteinführung. Gleichzeitig werden Wartungsfenster immer kürzer und es wird erwartet, dass die Anwendungen 24 Stunden am Tag verfügbar sind. Bestehende Anwendungen hingegen sind oft sehr monolithisch aufgebaut, einzelne Komponenten können nicht angepasst oder erweitert werden, ohne dass die gesamte Anwendung erneut getestet werden muss. Um die heutigen Anforderungen zu erfüllen bedarf es also einer Modernisierung der bestehenden Anwendungen. Modernisierungsansätze beinhalten zum Beispiel eine Restrukturierung der Anwendungen als cloud-native Microservices und eine Verlagerung traditioneller Anwendungen in Container-Plattformen. Der beste Ansatz zur Modernisierung hängt jedoch vom vorhandenen Bestand ab.

Initiale Bestands-Analyse:

Zunächst einmal sollten Sie sich bewusst werden, wie wichtig eine Anwendung ist und auch in Zukunft sein wird und welche Randbedingungen es für die jeweilige Anwendung zusätzlich gibt.

So gibt es Anwendungen, die in absehbarer Zeit nicht mehr benötigt oder durch eine „As-a-Service“ Lösung ersetzt werden. Für diese Anwendungen macht eine Modernisieren oft wenig Sinn.

Daneben können Anwendungen oft nicht modernisiert werden, da der Quell-Code nicht zur Verfügung steht oder benötigte Bibliotheken oder andere Komponenten vom Hersteller nicht in anderen Umgebungen unterstützt werden.

Damit reduziert sich die Anzahl an potentiellen Modernisierungs-Kandidaten meistens schon um die Hälfte. Für diese Anwendungen stellt sich nun die Frage, welchen Modernisierungsansatz Sie nutzen sollten.

Es gibt verschiedene Modernisierungsansätze:

Re-Host, Re-Platform, Refactor oder Rearchitect – was ist der richtige Pfad?

Bei „Lift and Shift“, auch bekannt als re-host, verlagert man die Anwendung ohne Anpassungen in die Cloud. Die Prozesse rundherum bleiben aber gleich. Daher ist der Ansatz gut, sofern man primär Infrastruktur-Kosten sparen möchte, der Ansatz macht aber in der Regel die Anwendung nicht agiler.

Der Ansatz, bestehende Anwendungen auf Basis von Microservices nachzubauen (rearchtitect), hat sich in vielen Projekten nicht bewährt, da der Ansatz nur eingeschränkt Wiederverwendung des bestehenden Codes ermöglicht und daher sehr aufwändig und mit einem hohen Risiko behaftet ist.

Ein bewährter Ansatz ist, die bestehende Anwendung wenn möglich erst einmal zu containerisieren, um so die Vorteile einer Containerplattform nutzen zu können wie zum Beispiel zentrale Administration, zentrales Logging und Monitoring, einheitliche Deployment-Prozesse, bessere Isolierung, Skalierbarkeit und Hochverfürbarkeit. Gleichzeitig sollte man versuchen, die Anwendung auf einen schlankeren Application Server zu heben (re-platform), optimalerweise auf eine Cloud-native Laufzeitumgebung wie Liberty.

Sofern diese Schritte für die benötigte Flexibilität nicht ausreichen, so ist der nächste Schritt eine Zerlegung der Anwendungen in kleinere Teile (refactor). Das können Microservices sein, oft setzt man hier auch auf Macroservices. Falls das dann immer noch nicht ausreicht, so kann man die entsprechenden Anwendungsteile immer noch in Microservices nachbauen. Der Weg mag wie ein Umweg wirken, birgt aber ein deutlich geringeres Risiko und bringt Vorteile in jedem Teilschritt. Der Pfad wird in dem nachfolgendem Diagramm dargestellt.

Basierend darauf könnten Sie nun den Eindruck erhalten, Sie könnten jede Anwendung mit recht wenig Aufwand containerisieren. Aber das ist nicht so. Letztendlich sollten Sie jede Anwendung oder Gruppe von Anwendungen betrachten und eine Entscheidung treffen, wie Sie modernisieren möchten. Dabei dürfen Sie nicht aus den Augen verlieren, was das Ziel der Modernisierung sein soll. Daher sollten Sie sich jede Anwendung im Detail anschauen, um zu entscheiden, welcher Ansatz kommerziell der Sinnvollste ist. Einige der Faktoren dabei sind:

  • Geschäftswert – Welchen Mehrwert bringt die Anwendung und eine Modernisierung der Anwendung?
  • Betriebskosten – Welche Kosten verursacht die Anwendung zum Beispiel für Betrieb und Wartung?
  • Abhängigkeiten – Welche Abhängigkeiten zu anderen Systemen hat die Anwendung?
  • Technologien – Welche Technologien und Standards nutzt die Anwendung?
  • Modernisierungsaufwände – Welche Aufwände entstehen bei welchem Modernisierungsansatz?

Die ersten beiden Faktoren können Sie selbst recht einfach bestimmen, für die anderen Punkte gibt es Lösungen der IBM. Im weiteren Verlauf werde ich Ihnen zwei dieser Lösungen vorstellen, den IBM Cloud Transformation Advisor und IBM Mono2Micro.

IBM Cloud Transformation Advisor:

Der IBM Cloud Transformation Advisor (kurz TA) ermöglicht die Analyse von beliebigen Java™ EE Anwendungen und kann zusätzlich auch die Konfiguration der gängigen Java™ EE Anwendungsserver (IBM® WebSphere® Application Server, Apache Tomcat®,  Red Hat® JBoss® Application Server oder Oracle WebLogic Server) analysieren. Ziel der Analyse ist eine Bewertung, ob Ihre Anwendung auf einem modernen Anwendungsserver wie Liberty laufen kann und ob es zum Beispiel durch Abhängigkeiten diverse Hürden beim Gang in die Cloud gibt.

Der Transformation Advisor besteht aus zwei Phasen:

  1. Einsammeln der Daten über die Anwendung.
    Ein Collector-Skript wird dabei auf Ihrer Umgebung ausgeführt und ermittelt die eingesetzten Technologien und die Konfiguration des Anwendungsservers. Das Skript erstellt eine komprimierte Datei (genannt Collection) mit den verschiedene Reports. Die Reports sind lesbar und daher auch schon für eine initiale Analyse geeignet.
  2. Zusammenführen und Bewertung der Daten
    Die Collection wird in den Transformation Advisor hochgeladen. Dort werden die Daten weitergehen analysiert und aufbereitet. Als Ergebnis erhalten Sie eine Übersicht über die analysierten Anwendungen mit Details zu den verwendeten Technologien, Abhängigkeiten und Aufwandsabschätzungen.

Analyse-Überblick

Der Analyse-Überblick liefert einen ersten Einblick:

Sie erhalten für jede Anwendungen eine Bewertung der Komplexität und geschätzte Entwicklungsaufwände. Dieses hilft Ihnen bei der Priorisierung,

Neben den Migrationszielen WebSphere Liberty und Open Liberty wird auch WebSphere Application Server Traditional als Ziel unterstützt.

Für jede Anwendungen und jedes Migrationsziel erhalten Sie weitergehende Details.

Technologie-Probleme

Hier erhalten Sie eine Liste der problematischen Technologien, die in der Anwendung genutzt werden und welche Aufwände diese verursachen.

In dem dazugehörigen Technology-Report sehen Sie, in welchen Anwendungs-Komponenten die Technologien genutzt werden und erhält eine oder mehrere Empfehlung oder Optionen, wie Sie die Probleme lösen können. Im Falle der Entity EJBs zum Beispiel liegt das Problem darin, dass diese Technologie in modernen Anwendungsservern nicht mehr unterstützt wird. Die Empfehlung ist, die Daten-Persistenz auf JPA umzustellen. Unsere Migrations-Spezialisten schätzen dafür einen Programmier-Aufwand von 20 Tagen.

Externe Abhängigkeiten

Transformation Advisor zeigt Ihnen die erkannten Abhängigkeiten.

Auch wenn es auf den ersten Blick keine Probleme gibt, so sollten Sie hinterfragen, wie aktuell und auch später zum Beispiel auf die Datenbank oder das LDAP zugegriffen wird, um potentielle Probleme im Bereich Firewall oder Network-Latency frühzeitig zu erkennen. Ein Spezialfall sind hier die Remote EJB Providers. Diese können massive Probleme erzeugen, da Remote EJBs über das Protokoll RMI/IIOP, das weder Firewall-freundlich noch Container-freundlich ist, aufgerufen werden. Es kann also sein, dass Sie diese Anwendung in einen Container packen könnten aber einige Vorteile einer Container-Plattform wie Skalierbarkeit und Hochverfügbarkeit verliert.

Anwendungsinventar

Über den Inventory-Report erhalten Sie zusätzliche Informationen, wie die Anwendung im Detail aufgebaut ist und welche Komponenten gefunden wurden, die Deployment-Probleme verursachen könnten – seien es zum Beispiel Duplikate oder Java EE/SE-Klassen.

Wenn Sie eine Anwendung modernisieren, so sollten Sie in dem Zusammenhang die entsprechenden potentiellen Probleme gleich mit beheben.

IBM Cloud Transformation Advisor liefert Erkenntnisse und mehr

Wie Sie sehen, erhalten Sie mit dem Transformation Advisor ohne viel Aufwand sehr viele Erkenntnisse über Ihre Anwendungen. Basierend darauf können Sie dann eine gute Entscheidung treffen, ob Sie Ihre Anwendungen containerisieren können und auf welcher Plattform. Zusätzlich erhalten Sie auch die Anwendungsserver-Konfiguration, sei es die server.xml für Liberty oder die Jython-Skripte für WebSphere Application Server Traditional, sowie zugehörige Dockerfiles und Operators für das Deployment auf Docker und Kubernetes.

IBM Mono2Micro

Auch wenn Sie mit dem Gedanken spielen, Ihre Java-Enterprise-Anwendung in kleinere Teile zu zerlegen, so sollten Sie die Anwendung einer genauen Analyse unterziehen. Die Herausforderung bei der Zerlegung einer Anwendung in kleinere Komponenten ist, dass diese Komponenten (Services) danach unabhängig sein sollten, so dass man diese getrennt voneinander entwickeln und betreiben kann. Dazu ist es insbesondere wichtig, dass die verschiedenen Komponenten keine Datenobjekte teilen. Man möchte also verhindern, dass Klassen, die auf gemeinsamen Datenobjekten arbeiten, in verschiedenen Services landen (Stichwork Cross-Cutting), da dadurch entweder Abhängigkeiten oder erhöhte Programmieraufwände entstehen. Gleichzeitig möchte man aber die Anzahl an Anwendungsfällen, die durch einen Service abgedeckt werden, reduzieren, so dass man einen Anwendungsfall optimal skalieren kann.

Herausforderungen mit Datenabhängigkeiten – Cross-Cutting

Abb: Beispiel von Cross-Cutting.

Das Datenobjekt AccountDataBean enthält das Datenobjekt OrderDataBean.
Würde man nun die beiden Datenobjekte in getrennte Microservices packen, so müsste man entweder Micro1 umprogrammieren oder wie bisher das OrderDataBean in Micro1 und Micro2 nutzen, was eine Abhängigkeit zwischen den beiden Microservices erzeugen würde. Eine Änderung der OrderDataBean würde dann nicht nur Änderungen in Micro2 sondern auch in Micro1 erfordern. Das jedoch möchte man vermeiden.

Herausforderung Anwendungsfälle

Ein Ziel der Zerlegung der Anwendung ist, verschiedene Anwendungsfälle unabhängig voneinander skalieren zu können. Daher macht es keinen Sinn, wenn sich zu viele Anwendungsfälle die gleichen Microservices teilen. Gleichzeitig möchte man auch verhindern, dass ein Anwendungsfall auf zu viele Microservices verteilt wird, da dieses die Performance der Anwendung deutlich verschlechtern kann.

Wo hilft Ihnen Mono2Micro?

Eine optimierte Aufteilung einer Anwendung ist ein Kompromiss zwischen den Abhängigkeiten in Bezug auf Daten und Anwendungsfällen.

Und genau dabei hilft Ihnen die IBM Lösung Mono2Micro. Wie der Name vermuten lässt ist das Ziel von Mono2Micro, Ihren bestehenden Monolithen in Microservices zu zerlegen.

Mono2Micro basiert dabei auf den folgenden Microservices-Konzepten:

  1. Stateless and Share Nothing Processes
    Alle Anwendungsprozesse sind zustandslos und teilen sich nichts – insbesondere keine Datenobjekte.
  1. Independent Scalability and Disposability
    Alle Services skalieren unabhängig voneinander

Mono2Micro findet eine optimierte Aufteilung basierend auf künstlicher Intelligenz

Die Vorgehensweise um eine optimierte Aufteilung zu finden ist wie folgt:

  1. Zunächst wird über ein Skript eine statische Sourcecode-Analyse durchgeführt, um die Klassen, Methoden und Aufruf-Parameter herauszufinden.
    Diese Erkenntnisse werden in verschiedenen Dateien protokolliert.
    Zusätzlich instrumentiert das Skript den Sourcecode, so dass beim Ablauf des Programms verschiedene Laufzeit-Informationen erzeugt werden.
  2. Für die Anwendung werden nun Laufzeitanalysen durchgeführt. Dazu werden in der Anwendung nacheinander die verschiedenen Anwendungsfälle durchlaufen und dokumentiert. Da der Code instrumentiert ist, werden automatisch die Interaktionen zwischen den Anwendungsklassen und Methoden protokolliert.
  3. Die Protokolle der statischen Sourcecode-Analyse und der Laufzeitanalyse werden danach in Mono2Micro hochgeladen.
  4. Mono2Micro erzeugt nun Graphen für Datenabhängigkeiten als auch für die Anwendungsfälle.
  5. Mithilfe von künstlicher Intelligenz wird nun aus den beiden Graphen ein optimierter Graph erzeugt, der sowohl die Datenabhängigkeiten als auch die Interaktionen innerhalb der einzelnen Anwendungsfälle berücksichtigt.

Graph basierend auf Datenabhängigkeiten und Interaktionen

  • Die Ecken stellen eine Gruppe von Klassen dar.
  • Die Verbindungen zwischen den Gruppen stellen die Interaktionen dar, die Dicke der Linie deutet die Frequenz der Interaktionen an.
  • Die gestrichelten Linien deuten einen anderen Anwendungsfall dar

Optimierte Partitionen basierend auf den Anwendungsfällen

Mono2Micro erzeugt eine Empfehlung für eine Partitionierung und stellt diese grafisch dar. Die verschiedenen Partitionen kann man zur besseren Sichtbarkeit ein oder ausblenden sowie auch grafisch anordnen.

Abb: Mono2Micro Empfehlung für Microservices Partitionen basierend auf den Anwendungsfällen

Wie man sieht, erhält man in unserem Beispiel 6 Microservices, zusätzlich eine Vielzahl an Klassen, die keiner Partition zugeordnet sind. Diese partitionslosen Klassen sind Klassen, die in der statischen Code-Analyse dokumentiert wurden aber nicht in der Laufzeit-Analyse auftauchen. Das deutet entweder darauf hin, dass es zusätzliche Anwendungsfälle gibt, die zum Beispiel nur in einer bestimmten Umgebung zum Tragen kommen oder aber dass es sich bei diesen Klassen um Code handelt, der nicht mehr benutzt wird. Sofern die Klassen nicht mehr genutzt werden, so sollten sie entfernt werden um den Code zu verschlanken.

Mono2Micro: Empfohlene Partitionen – Detailanzeige

Für jeden Microservices erhalten Sie Details über

  • die enthaltenen Klassen
  • die Interaktionen mit anderen Klassen und Microservices
  • die abgedeckten Anwendungsfälle

Abb: Mono2Micro Microservices Partitionen – Details

Schnittstellen-Dokumentation

Neben der grafischen Darstellung bietet Mono2Micro auch eine tabellarische Darstellung.

Die Liste der Schnittstellen zwischen den Microservices zeigt Ihnen, an welcher Stelle nicht-primitive Datenobjekte zwischen Microservices ausgetauscht werden. Dadurch erkennen Sie, wo noch Programmieraufwand notwendig ist, um eine Unabhängigkeit zwischen den verschiedenen Microservices zu erreichen.

Abb: Mono2Micro Schnittstellen zwischen den Microservices

Basierend auf diesen Informationen können Sie gut beurteilen, wie viel Aufwand Sie erwartet, wenn Sie die bestehende Anwendung in kleinere Teile zerlegen möchten.

Zusammenfassung:

IBM Cloud Transformation Advisor und IBM Mono2Micro können Ihnen helfen, ohne viel Aufwand einen guten Einblick in Ihre Anwendungen erhalten.

Beide Lösungen bieten Ihnen Empfehlungen an, wie Sie Ihre Anwendung modernisieren können, sei es in Richtung Containerisierung oder Re-Factoring.

Als Teil der Analyse erhalten Sie die entsprechenden Erkenntnisse, um Ihre Entscheidung für eine Modernisierungsstrategie nicht basierend auf Gefühlen sondern auf Fakten treffen zu können.

Als Laufzeitumgebung für Ihre Zielumgebung empfehle ich Liberty, die nach unseren Messungen zurzeit wohl schnellste Java-Enterprise Laufzeitumgebung. Ein wesentlicher Vorteil von Liberty gegenüber anderen Laufzeitumgebungen ist, dass Liberty sowohl die Java Enterprise Standards wie Java EE 7 Full Profile und Jakarta EE als auch moderne Cloud-Native-Standards wie MicroProfile unterstützt. Beim Design wurde darauf geachtet, dass Liberty schlank und für Container optimiert ist. Durch die Unterstützung diverser Standards können Sie gerade im Rahmen einer Modernisierung viele Bestandsanwendungen ohne Aufwand auf Liberty portieren und die gleiche Laufzeitumgebung auch für Anwendungserweiterungen auf Basis von Microservices nutzen. Details zu Liberty finden Sie hier.

Sie haben Fragen, Wünsche und Anregungen?

Weitere Informationen zum Thema Digitalen Wandel finden Sie unter: Den Digitalen Wandel Wagen

Wenn Sie unsere Lösungen gerne einmal live sehen möchten oder mehr zum Thema Anwendungsmodernisierung im allgemeinen erfahren möchten, stehen Ihnen die Vorträge des IBM Forum Anwendungsmodernisierung vom 16. September 2020 weiterhin kostenfrei zur Verfügung.  https://www.fairorg.de/IBM/Think/checkin.cfm/popup20/#dl12_1_18527

Etwas tiefer in die Technik geht es am 1. Dezember 2020 von 13 Uhr bis 16 Uhr in unserem virtuellen Event Lab Comes To You
„Anwendungsmodernisierung – ein technischer Blick hinter die Kulissen“ https://www.ibm.com/de-de/events/think/events/labComes2You2/

Oder kontaktieren Sie mich direkt unter: Lars.Besselmann@de.ibm.com oder https://www.linkedin.com/in/lars-besselmann

EMEA Technical Sales Lead on Application Modernization

More Cloud stories
By Felizitas Müller and Hermann Stolle on Januar 12, 2021

IBM erhält GEFMA-Zertifizierung für IBM TRIRIGA Facilities Management Software

TRIRIGA, IBMs KI-basierte Facility-Management (FM) Lösung, die wichtige Erkenntnisse aus IoT und KI in einer einzigen, integrierten Plattform vereint und sichere, effizientere und ansprechendere Arbeitsplätze schafft, ist GEFMA-zertifiziert.  Facility Management hat laut GEFMA in Deutschland eine Bruttowertschöpfung von 134 Milliarden Euro, einen Anteil von etwa 4,75 Prozent am BIP und über 4,6 Millionen Erwerbstätige [1]. […]

Continue reading

By Franziska Haller and Ralph Papendiek on Dezember 16, 2020

Chance und Härtetest für den Smarten Versicherer

Survive COVID-19 „Wenn uns die Pandemie eines gelehrt hat, dann die entscheidende Bedeutung von technologischen Lösungen, welche Schnelligkeit, Flexibilität, Einsicht und Innovation ermöglichen” – Arvind Krishna, IBM CEO [1] 2020 und damit die „Covid-19 Zeit“ bietet fraglos massive politische, gesellschaftliche, technologische und menschliche Herausforderungen. Aus rein unternehmerischer und innovations-analytischer Sicht betrachtet, ist sie allerdings auch […]

Continue reading

Digital Bad Banks: Preparing for the Next NPL-Wave

Preparing for the Next Wave of Non-Performing Loans The Covid-19 pandemic has contributed to accelerating the shift to a new lifestyle supported by technology. The virus-lead market disruption has pressured governments to increase their balance sheets and inject unprecedented amounts of money into the economy. Despite this support, a market disruption of such magnitude will […]

Continue reading