Als Red Hat Premier Partner setzen wir auf JBoss EAP

Warum JBoss EAP?

JBoss EAP bietet eine JEE-Plattform, die besonders gut für Service-orientierte und verteilte Architekturen und Anwendungen geeignet ist. Viele unserer Kunden betreiben sehr umfangreiche und komplexe Enterprise Systeme. So spielt eine passende Application-Runtime eine wesentliche Rolle. Auch wenn es um die automatisierte Konfiguration und Deployments geht, bietet JBoss EAP sehr stabile und mächtige Mechanismen. Das steht nicht nur für Betrieb, sondern auch für die Entwicklung und Testen von Software sowie für CI/CD im Mittelpunkt.

EAP oder WildFly?

JBoss Enterprise Application Platform (JBoss EAP) ist die von Red Hat unterstützte Version des Applikationsservers. Die Community Version (upstream Version) davon ist WildFly. Sie ist kostenlos.

Speziell in größeren Projekten empfehlen wir den Einsatz von EAP gegenüber WildFly. In unseren Lernprojekten (z.B. Hogarama) setzen wir auch WildFly ein, speziell wenn wir die neuesten Features ausprobieren wollen.

Warum dann EAP? Dazu ein paar Beispiele  aus unserer Erfahrung. All diese Fälle hatten große Aufmerksamkeit des Managements und waren kritisch für den Kunden. Ohne Unterstützung von Entwicklern mit tiefer Kenntnis des Sourcecodes wären sie nicht zu lösen gewesen. Die JBoss-EAP Subscriptions gaben uns Zugang dazu:

• Neue Funktionen werden implementiert und gehen erfolgreich durch alle Stages. In der Produktion bootet der Server einfach nicht fehlerfrei. Niemand weiß warum, was der entscheidende Unterschied zwischen Test- und Produktionsumgebung ist. Nach Einbindung des Supports konnte schnell der Unterschied auf Plattformebene gefunden und das Problem gelöst werden.
• Mit der neuen Version geht ca. eine von 6.000 globalen Transaktionen schief und führt zu falschen Buchungen. Der Fehler fällt erst in Produktion auf. Über den Support bekamen wir Hilfe von einem Entwickler, der am Transaktionssystem mitgeschrieben hat.
• Massive Performanceprobleme beim DB-Zugriff. Wir finden einen hilfreichen Hibernate Pull-Request, der aber schon lange herumliegt und weder in EAP noch in die Upstream WildFly Versionen integriert wurde. Mit Hilfe des Red Hat Supports wurde die Performanceverbesserung in JBoss-EAP integriert.

Darüber hinaus sind die EAP-Versionen besser getestet und bieten im Gegensatz zur Community-Version langfristige Stabilität.

Automatisierung von Deployments

Wir setzen keine JBoss Server manuell auf.

Applikationen, die auf JBoss EAP laufen, sind in der Regel mehr als nur eine WAR oder EAR Datei. Für größere Applikationen sind oft dutzende Schritte nötig, um den Server vollständig zu konfigurieren. Die entsprechende Konfiguration der Runtime (wie Datasources, Queues, Environment-Variablen, JNDI uvm.) ist – unserer Philosophie nach – ein untrennbarer Teil des Deployments und eine Voraussetzung dafür, dass die Applikation fehlerfrei funktioniert.

JBoss CLI kann nicht nur als ein interaktives Tool verwendet werden. Konfigurationsskripte sind auch ein valider Input. Die Skriptdateien sind im Auslieferung-Artefakt enthalten. So wird der Applikationsserver beim Deployment automatisch konfiguriert. Analog zu SQL-Skripten können die Konfigurationsskripte versioniert werden, denn sie sind normale Textdateien. Die Versionierung von Konfigurationen finden wir genauso wichtig wie die Versionierung von Source Code. Da bietet JBoss EAP volle Unterstützung.

EAP als Application-Server oder Application Runtime

Was ist ein Application Server? Nehmen wir als einfache Definition eine Infrastruktur, die vorhanden ist und auf der ein oder mehrere, auch voneinander unabhängige Anwendungen, auch von unterschiedlichen Projekten installiert werden. 

Nach dieser Definition verwenden wir JBoss EAP nicht als Application Server. Wir liefern in der Regel eine Applikation gemeinsam mit der JBoss EAP Instanz aus. EAP ist “nur” die Laufzeitumgebung für unsere Anwendung. Dieses Paketieren des Servers mit der Anwendung macht vieles einfacher und der Overhead ist beim Ressourcenbedarf heutiger Applikationen relativ gering.

EAP in Containern

Der moderne Application-Server nach obiger Definition hat nach unserer Sichtweise als Basis Kubernetes. Anwendungen werden als Linux Container (a.k.a. Docker Container) bereitgestellt. Ist es sinnvoll, EAP in einem Container zu installieren? Kann man machen, speziell wenn man mittels “Lift & Shift” schnell in eine containerisierte Infrastruktur wechseln will. EAP dient dann als reine JEE Runtime. Allerdings werden einige Features von EAP in solchen Architekturen weniger benötigt und wir tendieren zu spezialisierten Microservice Runtimes wie z.B. Quarkus.

Die Zukunft von EAP?

Die JEE Runtime hat weiterhin ihre Berechtigung, aber wir erwarten, dass Quarkus gegenüber JBoss EAP in Kubernetes Plattformen vermehrt eingesetzt werden wird.

JBoss EAP ist eine unserer Kerntechnologien, in der wir jahrelange Erfahrung aufgebaut haben. Wir bieten Trainings, Troubleshooting, Consulting, Betriebs- und Entwicklungsdienstleistungen. Wenn es um JBoss EAP geht, sind wir der richtige Ansprechpartner.