Suche
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
  1. Till2014-07-02 15:41:48

    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.

    1. soylent2014-07-09 18:02:24

      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.

      1. Eberhard Wolff2014-07-10 13:39:39

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

  2. Eberhard Wolff2014-07-08 12:44:15

    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

    1. JustBeep2014-07-11 14:31:02

      "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!

      1. Eberhard Wolff2014-07-14 19:27:32

        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

  3. Marc Teufel2014-07-10 04:25:38

    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, wenn ich mich für ein kommerzielles Application Server Produkt entscheide, ich die Sicherheit von externen Dienstleistern habe also auf den Hersteller des Produkts zurückgreifen kann. Das stelle ich mir, zumindest in der aktuellen Situation im Zusammenspiel mit Microservices noch schwierig vor. Die Idee ist sicherlich spannend, man wird aber erstmal sehen müssen, ob und wie sich dieser neue Ansatz durchsetzen wird. Noch bin ich skeptisch.

  4. Eberhard Wolff2014-07-10 13:23:11

    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 Technologien wie Drop Wizard, die ohne Application Server auskommen, normale monolithische Java-Enterprise-Anwendungen zu entwickeln. Die Argumentation läuft eher in die Richtung, dass gerade bei Micro Services der Overhead eines Application Servers noch schwerer wiegt.
    Eberhard Wolff

    1. Marc Teufel2014-07-11 15:20:35

      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.

  5. Eberhard Wolff2014-07-14 19:25:28

    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

  6. hoeferh2014-07-20 14:27:48

    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 Ops zu 100% automatisiert ist, dann sind Microservices einfach nur eine Optimierung für bessere Verteilbarkeit.

    Wer bisher einen Application-Server verwendet, hat aber oft eine sehr andere Umgebung und sehr andere Anforderungen! Ich bin nicht davon überzeugt, dass es sinnvoll sein soll, einfach nur eine monolithische Anwendung in 20 Services zu zerlegen – immerhin handelt man sich 20× Serialisierung-Deserialisierung und u.U. 20× Latenzzeit ein.

    Wenn es darum geht, dass die Entwicklung schneller auf Änderungsanforderungen reagieren können soll, dann führt ohnehin kein Weg an Komponentenorientierung vorbei. Und dann kann man eben auch Spring Beans oder Vert.X Verticles oder OSGi Bundles oder auch nur saubere Package-Grenzen und Interfaces nehmen – Microservices sind den Verwaltungsaufwand nur wert, wenn ich die Anwendung sowieso verteilt betreiben muss.

  7. FrankB2014-12-12 16:45:36

    Totgesagte leben länger...

  8. Thomas Junk2015-01-07 09:55:04

    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 hat einen genau bestimmbaren Single Point of Failure. Das Deployment von einander unabhängigen Teilbereichen geschieht auch unabhängig voneinander. Teilweise können mehrere Versionen von Services parallel betrieben werden, so dass man partielle Upgrades an der Applikation vornehmen kann, ohne gleich alle Komponenten umstricken zu müssen. Alles in allem aus Entwicklersicht ein voller Gewinn.

    Auch der Betrieb profitiert davon: Microservices heißt auch, dass Funktionsbereiche unabhängig voneinander gemonitored ("überwachen" finde ich derzeit ein wenig unpassend) und skaliert werden können. Performance wird kalkulierbarer.

    Hinzu kommt, durch Docker und Vagrant induziert, das "Wegwerfprinzip" Einzug in den Betrieb erhält: Statt ständig wechselnden Infrastrukturkomponenten / Softwarepaketen hinterherzujapsen werden Komponenten deployed und beim nächsten Release ggf. wieder weggeworfen. So wird man dynamischen Anfoderungen zeitnah gerecht - Stichworte: Continous Deployment / Delivery um ein paar Buzzwords einzustreuen ;)

Schreibe einen Kommentar

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