Microservices in Java

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Wer mit Cloud-nativen Microservices in Java auf die Überholspur massiver Skalierbarkeit wechseln möchte, braucht das Rad nicht neu zu erfinden. Code-Refactoring muss nicht zwangsweise im Zusammenbruch der Entwickler-Produktivität ausarten. Eine Handvoll innovativer Tools schafft Abhilfe.

Analysten zufolge handelt es sich um Microservices um einen anhaltenden Trend, der bald ganz neue Dimensionen erreichen dürfte. Im Zeitalter Cloud-orchestrierter Microservices wächst der Druck auf die Anwendungsentwickler, ein höheres Maß an Produktivität und Effizienz an den Tag zu legen, als dies mit monolithischen Anwendungen in Java möglich ist.

Das Forschungsinstitut Allied Market Research sagt dem Marktsegment der Microservices ein Wachstum von 2,073 Mrd USD in 2018 auf sagenhafte 8,073 Mrd USD in 2026 voraus. Der Markt soll demnach im Prognosezeitraum eine durchschnittliche zusammengesetzte jährliche Wachstumsrate (Engl. „compound annual growth rate“, kurz: CAGR) in Höhe von gesunden 18,6 Prozent erreichen („Microservices Architecture Market by Component, Deployment type, Organization Size, and Industry Vertical: Global Opportunity Analysis and Industry Forecast, 2018–2026“).

Zum Glück sind für die Entwickler monolithischer Java-Anwendungen Hopfen und Malz noch nicht verloren. Denn die elastische Skalierbarkeit Cloud-nativer Microservices lässt sich durchaus auch in Java umsetzen – es fragt sich nur, mit welchen Tools.

Die Qual der Wahl

Sechs von zehn befragten Java-Entwicklern setzen auf das quelloffene Spring Framework, fand Snyk, ein Anbieter von Sicherheitslösungen für Java, in einer aktuellen Umfrage heraus. Rund zwei Drittel dieser Teilnehmer arbeiten mit der neuesten Version des Frameworks (5.x).

Knapp zwei Drittel der Java-Entwickler nutzen demnach die Enterprise Edition (J2EE, Java EE, Jakarta EE etc.). Doch die überwiegende Mehrheit der EE-Entwickler setzt interessanterweise nicht auf Oracles Java EE (nur rund einer von fünf aller Java-Entwicklern), sondern auf eine Alternative wie etwa das Spring Framework, JPA oder Servlets (etwa vier von zehn Java-Entwicklern). Die Popularität von Java EE blieb gegenüber dem Vorjahr im Übrigen unverändert.

Java-Microservices mit Spring Boot

Spring, das mit Abstand beliebteste App Development Framework für Java, bietet einige der leistungsstärksten Tools für die Entwicklung von Microservices. Eines davon ist Spring Boot, ein Projektinitialisierungs-Framework für Cloud-native Anwendungsarchitekturen.

Mit Spring Initializr, dem visuellen Projektassistenten von Spring Boot, gelingt die Erstellung eigenständiger Anwendungskomponenten aus den verschiedenen Spring-Bausteinen (darunter auch Spring MVC im Rahmen von spring-web) mit nur minimaler Konfiguration. Das Ganze wird in JAR verpackt

Zu den besonderen Highlights des Spring Frameworks zählen die ausgereifte Abhängigkeitsinjektion und IoC (Inversion of Control). Obwohl die Mehrheit der Entwickler nach wie vor auf das Spring Framework setzen, gibt es mit Helidon SE, JRebel und XRebel, Ktor, Micronaut.io und Quarkus überaus interessante Alternativen.

Durch die Isolierung von Microservices werden die starren Beschränkungen älterer monolithischer Java-Anwendungen aufgehoben. Während eine monolithische Anwendungsarchitektur voraussetzt, dass alle Entwickler dieselben Technologien verwenden, ist dies im Falle von Microservices weder nötig noch sinnvoll.

Teams, die an verschiedenen Diensten arbeiten, sind nicht alle in einem Tech-Stack eingeschlossen. Sogar einzelne Entwickler können die Sprache, die Plattform und die verschiedenen Elemente ihres Toolchains frei aussuchen. Die Segmentierung von Microservices erleichtert das Aktualisieren und Patchen deutlich.

Dies führt dazu, dass von einer Version zur nächsten weniger Legacy-Code als bei monolithischen Anwendungen verwaltet wird. Daher sind sie weitaus weniger anfällig für Sicherheitsmängel. Durch die kleinere Angriffsfläche kann das dem jeweiligen Dienst zugewiesene Team besser bestimmen, wo Sicherheitspatches benötigt werden, und sich für den Schutz dieser einzelnen Funktion einsetzen.

Micronaut

Micronaut ist ein JVM-basiertes Full-Stack-Framework zur Entwicklung von Microservices und Serverless-Anwendungen. Es stammt aus der Feder der Entwickler von Grails, eines Groovy-basierten Frameworks für die JVM, welches sich auf Spring Boot stützt. Micronaut macht Anleihen bei Grails und Spring. Es unterstützt neben Java auch Kotlin und Groovy.

Die Entwickler von Micronaut haben sich bemüht, die Systemvoraussetzungen auf einen möglichst geringen Fußabdruck zu trimmen. Hierzu werden die Abhängigkeiten erst zum Kompilierungszeitpunkt eingefügt, welches im Vergleich zu Spring Boot zu einem deutlich geringeren Speicherverbrauch und damit zu einem schnelleren Start der Anwendung führt.

JRebel und XRebel

Das JVM-Plug-In JRebel überspringt die Arbeitsschritte Rebuild und Redeploy und stellt Code-Änderungen in Echtzeit bereit, ohne den Anwendungsstatus zu verändern. „Ich schätze mal, JRebel spart mir so um die zehn Prozent meiner Arbeitszeit jeden Tag, manchmal sogar mehr“, sagt Petri Heinonen, Sr. Vaadin Expert bei Vaadin, dem Anbieter des gleichnamigen Java-Frameworks für progressive Web-Apps.

Für Miro Kopecky, Software Research und Development Engineer bei der Berliner Heliocentris Energy Solutions AG, belaufe sich die Zeitersparnis sogar auf satte 50 Prozent seiner aktiven Entwicklung. Zur Echtzeit-Überwachung der Laufzeitperformance Microservice-basierter Anwendungen können Entwickler zusätzlich zu JRebel das JVM-Plug-In XRebel zu Rate ziehen.

Quarkus

Bei Quarkus handelt es sich um ein Kubernetes-natives Java-Framework von Red Hat, welches auf die OpenJDK HotSpot Runtime und Oracles GraalVM zugeschnitten ist. Den eigenen Worten der Entwickler zufolge schöpft Quarkus „aus den besten Java-Bibliotheken und -Standards“.

Red Hat verfolge damit das Ziel, „Java zu einer führenden Plattform in Kubernetes und in serverlosen Umgebungen zu machen“ und dies mit einem einheitlichen reaktiven und imperativen Programmiermodell, um so „ein breiteres Spektrum“ verteilter Anwendungsarchitekturen „optimal zu adressieren“. Quarkus setzt auf JDK ab der Version 8 auf und versteht sich zudem auch auf Kotlin, Googles bevorzugte Java-Alternative aus dem Hause JetBrains. Quarkus unterstützt Apache Maven ab 3.5.3 und Gradle.

GraalVM Enterprise Edition ist eine leistungsstarke, einbettbare, vielsprachige virtuelle Maschine zum Ausführen von Anwendungen in JavaScript, Python, Ruby, R, JVM-basierten Sprachen wie Java, Scala, Kotlin und LLVM-basierten Sprachen wie C und C ++. Diese effiziente Interoperabilität zwischen Programmiersprachen zählt zu den Highlights von GraalVM EE.

Sourcetrail

Sourcetrail ist ein quelloffener interaktiver Sourcecode-Explorer des österreichischen Entwicklers Eberhard Gräther aus Wien. Das leistungsstarke Werkzeug erleichtert Entwicklern die schnelle Einarbeitung in fremden Code und hat sich beim Refactoring monolithischer Java-Anwendungen vielerorts bewährt.

Sourcetrail unterstützt Java, C/C++ und Python in allen führenden IDEs bzw. Code-Editoren einschließlich IntelliJ IDEA, Visual Studio, Visual Studio Code, Eclipse und einer Handvoll anderer. Es visualisiert Zusammenhänge zwischen einem beliebigen ausgewählten Typ, einer Funktion oder Variablen mit der übrigen Codebasis in Form von interaktiven, dynamisch generierten Code-Maps.

Zusätzlich zu der bereits sehr intuitiven Code-Visualisierung zeigt Sourcetrail gleich auch die relevanten Codefragmente mit an, um die Zusammenhänge gleich auf der Stelle zu verdeutlichen. Eine umfangreiche Code-Suche rundet das Leistungsspektrum ab.

Der Entwickler von Sourcetrail hat sich den Datenschutz auf die Fahnen geschrieben. Das Tool handhabt die gesamte Codebasis offline, ohne Cloud-Anbindung. Somit eignet sich die Lösung hervorragend auch für vertrauliche Projekte, z.B. Java-Software mit NDA-Klauseln. Die Internetverbindung dient einzig und allein dazu, um nach Software-Updates zu suchen.

Sourcetrail kann nebenbei erwähnt auch relativ umfassende Projekte handhaben. Erst ab ca. zehn Millionen Zeilen Code geht der Indizierer dann doch in die Knie, warnt der Chefentwickler. Wer eine derart große Codebasis verarbeiten müsse, dem empfiehlt Gräther, sich nach einer noch skalierbareren Lösung umzuschauen. Für die meisten Microservice-Anwendungen in Java dürfte Sourcetrail aber vollauf genügen.

Eine groß angelegte Schrumpfkur des Ökosystems

Seit Oracle die Lizenzierung von JDK umgekrempelt hatte, mussten sich insbesondere die kleineren und mittelgroßen Softwareschmieden langfristig neu orientieren. Eine groß angelegte Schrumpfkur des Ökosystems und eine wachsende Diversifizierung sind die Folgen.

Laut einer Umfrage von Snyk von 2020 kommt Oracles JDK auf einen Anteil von gerade einmal 34 Prozent am gesamten Ökosystem, ein Rückgang um mehr als die Hälfte gegenüber Vorjahr (Quelle: JVM Ecosystem Report 2020), als Oracle mit satten 70 Prozent eine nahezu erdrückende Dominanz genießen konnte. Auch Eclipse J9/IBM J9 hat einen Rückgang verzeichnet und liegt derzeit nur noch bei drei Prozent.

Die massive Migration der Entwickler hin zu JDK-Alternativen hat im Ökosystem tiefe Spuren hinterlassen. Die OpenJDK-Distributionen konnten gegenüber dem Vorjahr einen Zuwachs in Höhe von 36 Prozent verzeichnen; selbst Azul hat um drei Prozent zugenommen. Knapp einer von vier JDK-Nutzern entwickelt sein wichtigstes Projekt mit der AdoptOpenJDK-Distribution.

Die Mehrheit der Java-Softwareschmieden nimmt kostenpflichtigen JDK-Support nicht in Anspruch. Nur neun Prozent der befragten Entwickler in der aktuellen Umfrage von Snyk zum Stand des JVM-Ökosystems zahlt für den JDK-Support. Im Übrigen: Obwohl Oracle für die Nutzung des kommerziellen Oracle JDK die betroffenen Entwickler zur Kasse bittet, werkelt im Inneren der Plattform das kostenfreie und quelloffene OpenJDK.

Die javax-Kontroverse

Auch mit der javax-Kontroverse konnte Oracle bei den Java-Entwicklern nicht wirklich punkten. Trotz monatelanger Verhandlungen konnten Oracle und die Eclipse Foundation über die Nutzung des javax-Paketnamensraums durch die Gemeinde der Eclipse Foundation keinerlei Übereinkunft erzielen.

Oracle hat den javax-Namespace mit einem Warenzeichen geschützt, um den zugehörigen Code als sein Eigentum zu kennzeichnen. Alle Verbesserungen an Jakarta EE durch die Eclipse Foundation müssen künftig einen anderen Paketnamen verwenden. Diese Änderungen betreffen jede einzelne API der Enterprise Edition, da sie alle mit dem Namensraum javax beginnen.

Jegliche Modifikationen an Jakarta EE gehen künftig mit der Migration von Bibliothekscode einher. Zwei von drei JVM-Entwicklern zeigen sich von Oracles „Lösung“ zutiefst enttäuscht. Dennoch werden nahezu zwei Drittel der Entwickler trotz dieser lästigen Namensraumänderung „höchstwahrscheinlich oder ganz sicher“ das Framework nicht wechseln. Somit hat Oracle offenbar das Ziel knapp verfehlt.

Fazit

Java, insbesondere mit geeigneten Tools und Frameworks wie Spring Boot, kann in Sachen Microservices anderen Sprachen den Rang ablaufen. Das Schöne an Microservice-Architekturen im Java-Stil ist die Fähigkeit, ohne den Verzicht auf solide Codebasis mit anderen Technologien zu experimentieren.

Nach rund 30 Jahren im Praxiseinsatz zeigt Java immer noch keine nennenswerten Alterungserscheinungen, sondern vielmehr eher Zeichen anhaltender Langlebigkeit. Auf die massive Codebasis der Unternehmen trifft diese Langlebigkeit jedoch nicht zu. Vielen Java-Entwicklungsschmieden steht ein umfassendes Refactoring ihrer monolithischen Code-Basis ins Haus.

Wer in Java mit der Zeit gehen will, muss das Potenzial Cloud-nativer Microservices ausloten. Nichts macht sich hier von selbst. Die Reise ins Ungewisse gelingt aber durchaus mit einem robusten Toolchain und einem geeigneten Framework.

Parallelverarbeitung mit Java-Threads

Nutzung von Parallelrechnern stellt hohe Anforderung an Softwareentwicklung

„Teile und herrsche“: Wo Microservice-Architekturen sinnvoll sind

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

(ID:46639581)