Kolumne: EnterpriseTales

App-Server auf Diät: Haben klassische Application Server noch eine Zukunft?

Lars Röwekamp

Sind Enterprise-Application-Server, so wie wir sie in den letzten zehn Jahren kennen und lieben gelernt haben, heute noch zeitgemäß? Oder ist das Modell der Rundum-sorglos-Ablaufumgebung inklusive Management- und Monitoringfunktionalität mittlerweile überholt? Eine gute Frage, auf die EnterpriseTales versucht, eine Antwort zu geben.

Neulich auf einer Konferenz habe ich einen Vortrag zum Thema „Microservices: Size doesn’t matter – oder etwa doch?“ gehalten. Im Rahmen des Talks wurde unter anderem auch über „Ablaufumgebungen“ für Microservices diskutiert, wie Spring Boot oder Dropwizard. Im Anschluss kam einer der Teilnehmer mit einer interessanten Frage auf mich zu, die ich den Lesern der EnterpriseTales-Kolumne nicht vorenthalten möchte: „Haben klassische Application Server überhaupt noch eine Zukunft?“

Das Ende einer Ära

Zugegeben, die von mir im Talk geschilderten Szenarien legen einen fetten Application Server als Ablaufumgebung nicht wirklich nahe. Denn der Vorteil eines klassischen Application Servers liegt ja vor allem darin, dass mehrere Anwendungen parallel und gleichzeitig sauber voneinander getrennt auf bzw. in ihm laufen können. Wieso also dann einen Application Server nutzen, wenn man nur eine Anwendung bzw. einen Service auf ihm laufen lassen möchte?

Natürlich bietet ein Application Server noch ein wenig mehr an Mehrwert als nur die reine Ablaufumgebung. Er stellt zum Beispiel die für die Anwendung notwendige Infrastruktur – wie die Anbindung an eine Datenbank oder JMS Queues – sowie Unterstützung für Deployment, Management und Monitoring der Anwendung zur Verfügung. Darüber hinaus bündelt der Server in der Regel eine Reihe von in den Versionen aufeinander abgestimmten – also kompatiblen – Libraries, die der Anwendung nützliche Dienste erweisen und das manuelle Zusammensuchen eben dieser obsolet werden lassen. Die Libraries können entweder einem Standard genügen, wie bei Java EE Application Servern, oder eben einfach nur eine für bestimmte Einsatzzwecke sinnvolle Kombination sein, wie wir es zum Beispiel aus der einen oder anderen Tomcat-Distribution kennen. Jeder, der einmal versucht hat, seine eigene Anwendung um das gewünschte Set von Libraries zu erweitern und dabei versehentlich in die Class-Loader- und Versionshölle geraten ist, weiß, wovon ich rede.

Optimal wäre also ein Server, der die eben genannten Vorteile mit sich bringt, dabei aber gleichzeitig – aus Sicht der jeweils zur Verfügung zu stellenden Anwendung – auf unnötigen Ballast verzichtet. Wenn der Server dann noch Bestandteil der Anwendung selbst werden könnte und somit keine separate Installation und kein Management des Servers notwendig wäre, ja, dann wäre unsere Welt perfekt.

Schmalspurserver

Genau das eben geschilderte Szenario greifen bestehende Lösungen auf, wie Spring Boot, Dropwizard oder Play . Diese haben sich bisher insbesondere (aber nicht nur) im Microservice-Umfeld einen Namen gemacht. Aber auch Vertreter der standardisierten Enterprise-Java-Server-Welt haben inzwischen den Bedarf erkannt und bieten entsprechende Lösungen an. Die interessantesten Vertreter sind derzeit wohl TomEE Shades, WildFly Swarm, Payara Micro GlassFish und KumuluzEE . Allen Lösungen ist gemein, dass sie den von Dropwizard bekannten Ansatz „take only what you need“ auf die Java-EE-Welt übertragen und als Embedded-Server Teil der als JAR deployten Anwendung werden können.

Supporter statt Server

Was aber ist mit Management und Monitoring der Anwendungen? Auch hier bietet ja der Application Server in der Regel umfangreiche und ausgereifte Lösungen inklusive entsprechender Administrationsoberfläche. Sollen bzw. wollen wir zukünftig darauf verzichten? In einer stark verteilten Anwendungslandschaft, wie wir sie bei Microservices vorfinden, liegt eine der großen Herausforderungen weniger darin, eine schicke Oberfläche für das Management und Monitoring vorzufinden, als vielmehr darin, die vielen, vielen Services bzw. Anwendungen und deren aktuellen Health-Status unter Kontrolle zu halten. Hinzu kommt die Besonderheit, dass verteilte Logs verdichtet und korreliert werden müssen, um bestehenden Störungen auf die Schliche zu kommen und herannahende Probleme auf Basis von Metriken möglichst früh aufzuspüren – und zwar bevor sie zu einer Störung werden. Wichtig ist also eher, dass die Ablaufumgebungen der Anwendungen eine genormte Schnittstelle zum Management und Monitoring anbietet, als dass sie über ausgereifte aber gleichzeitig proprietäre Lösungen verfügen. Auf diesen Schnittstellen können dann zum Beispiel Tools wie Graphite in Kombination mit jmxtrans für verteiltes JMX-Monitoring oder der ELK Stack für eine verteilet Loganalyse auf Basis von Elasticsearch aufsetzen. Die Ablaufumgebungen werden so zu Supportern, im Sinne von Datenlieferanten, für übergreifende Management- und Monitoringlösungen. Die Auswertungen dagegen finden an übergeordneter Stelle statt.

Schmalspurserver oder eine Eierlegende-Wollmichsau-Laufzeitumgebung?

Application Server mit dem Anspruch, eine Eierlegende-Wollmichsau-Laufzeitumgebung inklusive Management- und Monitoringleitstelle zu liefern, scheinen heutzutage überholt. Und das nicht nur im Umfeld von Microservices. Als besser geeignet kristallisieren sich dagegen Ablaufumgebungen heraus, die sich individuell an die Bedürfnisse der jeweiligen Anwendung anpassen lassen. Dass sich die beiden Welten nicht vollständig ausschließen und man auch bei einem einbettbaren Schmalspurserver nicht auf Komfort und notwendige Enterprise-Features verzichten muss, haben Lösungen wie Dropwizard und Spring Boot vorgemacht. Erste Anbieter aus dem Java-EE-Umfeld ziehen mittlerweile nach, sodass man auch in der Welt des Java-Enterprise-Standards zukünftig deutlich flexibler agieren kann. Übrigens: Einen weiteren Sprung in puncto Flexibilität könnten wir durch das Modularisierungsprojekt Jigsaw erwarten. Da Jigsaw aber erst mit Java 9 kommen wird und somit nicht unbedingt damit zu rechnen ist, dass es bereits Auswirkungen auf Java EE 8 hat, müssen wir uns hier wohl auf Seiten der standardisierten Server noch bis 2020 gedulden. Andere Lösungen dagegen dürften Jigsaw deutlich früher adaptieren. In diesem Sinne: Stay tuned …

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Kommentare

Schreibe einen Kommentar

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