Sind sie noch zeitgemäß?

Der Tod der Java Application Server

Eberhard Wolff
© iStockphoto.com/Corben_D © iStockphoto.com/jamtoons

Application Server und Enterprise Java werden oft gleichgesetzt. Aber das Konzept des Application Servers ist mehr als zehn Jahre alt – Zeit für eine kritische Bewertung. Passt die Idee eines Application Servers zu aktuellen Trends wie Micro Services und Embedded Containers?

Zunächst zum Begriff Application Server: Es geht hier nicht nur um vollständige Java-EE-Implementierungen, sondern auch um Servlet Container wie Tomcat oder Jetty. Diese Server versprechen Folgendes:

• Bieten einen Container für mehrere Anwendungen
• Bieten die für die Anwendungen notwendige Infrastruktur
• Unterstützen Betriebsprozesse wie Deployment und Monitoring

Container

Damit ein Application Server tatsächlich mehreren Anwendungen eine Heimat bieten kann, müssen die Anwendungen voneinander isoliert werden. Dazu werden ClassLoader, die in Java-Umgebungen das Laden von Code umsetzen, benötigt. Jede Anwendung bekommt ihren eigenen ClassLoader, sodass sie nur ihre eigenen Klassen nutzen kann. Das führt in der Praxis häufig zu Problemen – wohl jeder Nutzer eines Application Servers hat schon einmal ein Problem im Bereich des Class Loadings untersucht, was oft eine sehr aufwändig Aufgabe ist.

(Den kompletten Artikel finden Sie im Java Magazin 7.14)

Geschrieben von
Eberhard Wolff
Eberhard Wolff
Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Continuous Delivery und Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenz vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps, Microservices und NoSQL.
Kommentare

Hinterlasse einen Kommentar

13 Kommentare auf "Der Tod der Java Application Server"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Till
Gast

Hat sich der Author auch Gedanken über den Betrieb und die Sicherheit von business kritischen Anwendungen gemacht? Es sind ja sicher die Entwickler welche in der Nacht aufstehen wenn die Anwendung nicht läuft ;-). Wie sieht es bezüglich Kosten aus? Hat der Author auch mal gerechnet? Bitte ein wenig weiter denken, bevor man meint dass der Java Application Server Tod sei.

soylent
Gast

Danke Till, guter Kommentar!
Es kann ja nicht sein, dass hier wild irgendwelche Thesen aufgestellt werden, die aber auch durch garnichts belegt werden. Man merkt das schon durchen Sprachgebrauch mit vielen "sollte". Dass Herr Wolff meint eine TCO wäre auch noch schön – im Nachgang zu seinen Behauptungen – finde ich amüsant. Der Lebenswirklichkeit in den großen Unternehmen, die ich kenne entspricht seine Behauptung jedenfalls überhaupt nicht, denn bevor ich App-Server abschaffe, hebe ich erstmal wichtigere Optimierungspotentiale.

Eberhard Wolff
Gast

Hallo,
ich würde diese Thesen nicht aufstellen, wenn sie nicht dem entsprechen würde, was ich in Projekten beobachte.
Eberhard Wolff

Eberhard Wolff
Gast

Hallo,
vielen Dank für den Kommentar! Gerade die Vereinfachungen bzgl. Betrieb sind für mich ein wesentlicher Grund, auf Application Server zu verzichten. Damit einher sollte eine höhere Kosteneffizienz gehen, gerade zusammen mit den Lizenzkosten. Details finden sich im Artikel oder unter http://de.slideshare.net/ewolff/java-application-servers-are-dead . Ein TCO-Berechnung wäre sicher noch spannend.
Gruß,
Eberhard Wolff

JustBeep
Gast

"Eine TCO-Berechnung wäre sicher noch spannend." ???

Application Server für tot zu erklären, OHNE – in Anbetracht von lizenzkostenfreien Servern – über TCO nur ein Wörtchen zu verlieren, das finde ich nun wirklich überraschend.

Da könnte ja auch Dr Oetker um die Ecke kommen und tönen: "Der Konditor ist tot! Es lebe die Backmischung!"
Es lebe der Sommer!

Eberhard Wolff
Gast

Hallo,
vielen Dank für das Feedback! Wie ich schon sagte, geht der Artikel darauf ein, warum bei Betrieb und Entwicklung Produktivitätsvorteile zu erwarten sind und damit auch Kostenvorteile entstehen. Es fehlt nur eine Kalkulation des TCOs.
Gruß,
Eberhard Wolff

Marc Teufel
Gast
Mich überzeugt das Konzept von Micro Services noch nicht. Angenommen ich habe für unser Versandzentrum mehrere kleine Webanwendungen mit denen in verschiedenen Bereichen gearbeitet wird, wo ist der Vorteil wenn ich diese 20 Anwendungen jedesmal separat installieren, ins Betriebssystem einbringen und konfigurieren muss? 20 separate Anwendungen, 20 separate Konfigurationen, 20 Ports die verwaltet werden müssen, 20 mal höherer Aufwand als wenn ich diese 20 Webanwendungen einfach in einen Tomcat deployen würde der einmal richtig konfiguriert ist. Und der arme Administrator! Der muss sich durch 20 nahezu gleiche Installationen durchkämpfen, kommt man da nicht irgendwann durcheinander? Hinzu kommt dass ich mich,… Read more »
Eberhard Wolff
Gast
Hallo Herr Teufel, vielen Dank für den Kommentar! Die erste Frage ist die Größe der Services. Man müsste mal schauen, wie ein sinnvoller fachlicher Schnitt aussieht und ob dann 20 oder größere bzw. kleinere Zahl an Services entsteht. Dann ist die Frage, welche Technologie man nutzt. Beispielsweise kann man mit Vagrant und Docker sehr einfach einen Micro Service aufbauen. Beispiel siehe https://github.com/ewolff/user-registration/tree/master/docker . Das Beispiel benötigt 3 Dateien mit insgesamt 22 Zeilen, um einen Docker Container mit einer Spring Boot Anwendung in einem Vagrant VM aufzubauen. Noch ein Hinweis: Es spricht auch überhaupt nichts dagegen, mit Spring Boot oder anderen… Read more »
Marc Teufel
Gast

Das klingt alles sehr interessant. Auch wenn ich alle diese Konzepte derzeit noch nicht in meinem Produktivbetrieb einsetzen würde, möchte ich mich trotzdem dieser neuen Ideen nicht verwehren. Progressiv denken, offen an neue Ideen herangehen ist hier die Devise. Ich werde mich sicherlich mit den genannten Technologien beschäftigen, in diesem Sinne vielen Dank für die Anregungen.

Eberhard Wolff
Gast

Hallo Herr Teufel,
gerne. Wenn Sie Lust haben, können Sie unter http://www.docker.com/tryit/ Docker zumindest mal ausprobieren. Dauert 10 Minuten, ist im Browser und vermittelt das Konzept schon mal ganz gut. Es geht leider noch nicht auf die Automatisierung mit Dockerfiles ein.
Gruß,
Eberhard Wolff

hoeferh
Gast
Mir kommt es ein bißchen wie an der Börse vor: Das Geld ist ja nicht weg, es hat jetzt nur jemand anderes. Bei Microservices ist die Komplexität der Anwendung auch nicht weg, sie liegt jetzt nur woanders – aus der Entwicklung wird der Aufwand in den Betrieb verlagert. Es ist wohl kein Zufall, dass Microservices gerade jetzt Mode werden, nachdem Firmen wie Netflix oder Amazon das DevOps-Prinzip verbreitet haben: Wenn Entwicklung und Betrieb sowieso von denselben Leuten verantwortet werden ist es egal, wo die Komplexität hinverschoben wird. Und wenn man sowieso alles auf AWS hostet und horizontal skalieren muss und… Read more »
FrankB
Gast

Totgesagte leben länger…

Thomas Junk
Gast
Wie sieht denn der Lebenszyklus einer durchschnittlichen Business-Anwendung / Individualsoftware aus? Die Projekte fangen mit begrenztem Aufgabenspektrum als Monolith an. Im Laufe der Zeit sammelt sich – wie ein Speckgürtel – mehr und mehr an Funktionen an. Die Applikation wird umfangreicher (und selbstredend komplexer). Die natürliche Folge ist, dass die Entwicklung neuer Features ebenfalls komplexer wird und – was wirtschaftlich ebenfalls bedacht werden sollte – die Zeit bis zum deployment wird schwerer kalkulierbar. Releases müssen zwischen Teams abgestimmt werden; Fehler in Teilen führen evtl. zum Rollback des gesamten Releases. Dagegen liegen die Vorteile von Microservices auf der Hand: Jedes Feature… Read more »