Interview mit Falk Sippach zur JAX 2017

„Java EE ist noch nicht besonders gut auf Microservices vorbereitet“

Hartmut Schlosser

Auf der JAX 2017 in Mainz zeigt Speaker Falk Sippach, wie man mit WildFly Swarm ausführbare JARs erstellt, die die notwendigen Teile des WildFly Application Servers, die Applikation selbst und allen benötigten Bibliotheken enthält. Im Interview mit JAXenter spricht er über die Unterschiede zwischen WildFly Swarm und Spring Boot, die Zukunft von Microservices und warum Application Server nach wie vor wichtig sind.

JAXenter: Das Interesse an Microservices ist derzeit sehr hoch – auch wenn die überwiegende Zahl der Java-Anwendungen noch auf dem klassischen Application-Server-Modell basieren dürfte. Siehst du in Microservices den Nachfolger der Application Server oder eher einen Ansatz, der parallel zum klassischen Modell eine Alternative anbietet? Oder anders gefragt: Werden wir in fünf bis zehn Jahren für neue Projekte überhaupt noch Application Server nutzen wollen?

Falk Sippach: Microservices und Application Server schließen sich ja nicht aus. Durch Continuous Delivery, DevOps, Containerisierung und Installationen in der Cloud geht der Trend zwar eindeutig hin zu Fat-JAR Deployments, das können aber genauso gut monolithische Anwendungen sein. In einem Application Server lassen sich andererseits auch relativ einfach kleine und vor allem schlanke EARs/WARs als Microservices deployen.

Was in zehn Jahren sein wird, lässt sich in unserer schnelllebigen Branche nur schwer vorhersagen. Ich denke aber, dass es sowohl Application Server als auch einige Firmen mit speziellen nicht-funktionalen Anforderungen noch geben wird, die Microservices in Form von Fat-JAR-Deployments einsetzen. Aber gerade bei Microservices-Architekturen gilt es zu bedenken, dass einerseits die Komplexität stark ansteigt und die Unternehmensstruktur andererseits deren Entwicklung überhaupt zulassen muss (Conways Law).

DevOps Docker Camp 2017

Das neue DevOps Docker Camp – mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauende Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

JAXenter: Du stellst auf der JAX WildFly Swarm vor; ein anderes sehr populäres Microservices-Projekt ist Spring Boot. Wie unterscheidet sich WildFly Swarm von Spring Boot?

Microservices und Application Server schließen sich nicht gegenseitig aus

Falk Sippach: Die Grundidee ist die gleiche und WildFly Swarm wurde von Spring Boot stark beeinflusst. Der größte Unterschied ist, dass Spring Boot auf dem Spring Framework und dessen Ideen und APIs aufsetzt, während man mit WildFly Swarm theoretisch standardkonforme Java-EE-Anwendungen entwickeln kann. Als Ergebnis kommt bei beiden ein Fat-JAR heraus, welches alle abhängigen Bibliotheken und die Ablaufumgebung in Form eines Servers (Tomcat oder andere Web-Container bei Spring Boot, WildFly bei Swarm) enthält. Dadurch lassen sich die Artefakte einmal bauen und anschließend durch die unterschiedlichen Stages der Delivery Pipeline schleusen sowie mit Container-Technologien auf den verschiedenen Zielumgebungen deployen.

JAXenter: Für Microservices-Architekturen gibt es einige neue Herausforderungen – etwa in Sachen Konfiguration, Logging, Monitoring, Resilience und Service Discovery. Wo bietet WildFly Swarm hier überzeugende Lösungen, wo muss man aber noch nachlegen bzw. auf externe Projekte oder gar auf Eigenentwicklungen zurückgreifen?

Falk Sippach: Bei Spring Boot merkt man, dass es eine Art Vorreiter war sowie die nicht kleine Marktmacht und vor allem Flexibilität des Spring Frameworks im Rücken hat. Darum bietet Spring Boot Stand heute eindeutig mehr Möglichkeiten, um den Herausforderungen von Microservices-Architekturen entgegenzutreten.

WildFly Swarm ist dagegen ein noch vergleichsweise junges Projekt. Es basiert zwar auf dem ausgereiften Java EE konformen Application Server WildFly. Aber gerade der Java-EE-Standard ist aktuell noch nicht gut auf die Erfordernisse von Microservices vorbereitet. WildFly Swarm integriert daher, ähnlich wie Spring Boot, einige Technologien aus dem Netflix OSS Stack wie Hystrix, Ribbon und RxJava. Bei Konfiguration, Logging, Monitoring und Health Checks greift man größtenteils auf Eigenimplementierungen zurück, die aber nicht standardisiert sind und auch noch nicht an die Mächtigkeit der Spring-Boot-Lösungen heranreichen. Für die Service Discovery kann man derzeit entweder das JBoss eigene Protokoll JGroups einsetzen oder HashiCorps Consul integrieren. Weitere Anbindungen werden dort in Zukunft sicher folgen.

JAXenter: Wie steht es um Microservices mit Java-EE-Technologien – aktuell und in Hinblick auf das kommende Java EE 8? Technologien für die Umsetzung von Microservices sind ja grundsätzlich vorhanden – wozu brauchen wir da noch Standardisierungen, wie sie in Java EE oder auch der MicroProfile-Initiative angestrebt werden?

Falk Sippach: Vor etwa einem Jahr war es seitens Oracle komplett still um den Standardisierungsprozess geworden und damit unklar, ob es überhaupt noch ein Java EE 8 geben wird. Nach einem Aufbäumen der Community (Java EE Guardians) und der Initiative verschiedener Hersteller von Application Servern und User Groups (MicroProfile) hat sich dann aber auch Oracle im Sommer 2016 wieder zu Java EE bekannt und einen zunächst unglaubwürdigen Fahrplan aufgestellt. Bis jetzt scheint dieser trotzdem aufzugehen und so soll im Sommer 2017 bereits Java EE 8 erscheinen. An den ursprünglichen Planungen zu dieser Version gab es so kurzfristig allerdings keine komplette Neuausrichtung in Sachen Microservices. Immerhin wurde noch ein Health Check API und ein API zur standardisierten Konfiguration aufgenommen. Das allerdings zu Lasten von anderen Technologien, zum Beispiel wurde JMS 2.1 verworfen und das MVC API komplett gestrichen.

Der Java-EE-Standard ist aktuell noch nicht gut auf die Erfordernisse von Microservices vorbereitet

Desweiteren haben die Planungen und Arbeiten am Java-EE-9-Standard bereits begonnen, der nur ein Jahr später, also 2018, folgen soll. Ob dieser Zeitplan wirklich zu halten sein wird, muss sich noch zeigen. Auf der Agenda stehen derzeit reaktive APIs z. B. für JAX-RS-Server und Clients, Integration von OAuth und OpenID, Unterstützung des Circuit Breaker Design Patterns, ein neues Event-API für Cloud-Anwendungen, die standardisierte Anbindung von diversen NoSQL-Datenbanken und noch einiges mehr.

Beim MicroProfile hat man erstmal kleine Brötchen gebacken und zunächst nur einige wenige Teile des Standards (JAX-RS, CDI, …) gebündelt, um einen zwar kleinen, aber immerhin gemeinsamen Nenner für Microservice-Architekturen mit Java EE zu finden. Mit WildFly Swarm, Payara Micro, Apache TomEE und anderen unterstützen dies bereits verschiedene Implementierungen. Laut eigenen Aussagen gibt es noch keine konkreten Gespräche mit Oracle zu einer Zusammenarbeit. Aber man kann sich vorstellen, dass das MicroProfile mal ein eigenes Java-EE-Profil (analog zu Full und Web) werden könnte.

Zum Thema Standards lässt sich festhalten, dass es ja typischerweise mehrere Implementierungen gibt, sodass man sich einerseits nicht von einem Hersteller abhängig machts und stattdessen aus verschiedenen Lösungen auswählen kann, nachdem man deren Vor- und Nachteile abgewogen hat. Zudem lässt man sich die Option offen, die Bibliothek, das Framework oder den Server jederzeit durch eine Alternative austauschen zu können, ohne die Anwendung komplett neu zu implementieren. Gut, im Falle von Microservices könnte man bestehenden Code einfach wegwerfen und neu implementieren. Aber ich glaube, dass auch in Zukunft der Großteil der Geschäftsanwendungen monolithisch aufgebaut sein wird, weil man die Komplexität von Microservices-Architekturen fürchtet. Gerade große Firmen und ihre Entscheider werden daher weiterhin auf die Vorzüge von Standards bauen. Und um diese Zielgruppe buhlen sowohl Oracle mit seiner Ausrichtung von Java EE auf die Cloud, als auch die Hersteller der klassischen Application Server mit ihrer MicroProfile-Initiative.

Falk Sippach hat über fünfzehn Jahre Erfahrung mit Java und ist beruflich als Trainer, Softwareentwickler und Projektleiter bei der OIO Orientation in Objects GmbH im Umfeld von Java-EE-Technologien unterwegs. Von Zeit zu Zeit schreibt er Blogeinträge, Artikel und tritt gelegentlich bei Konferenzen auf. In seiner Wahlheimat Darmstadt organisiert er mit anderen die örtliche Java User Group.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.