In Java sind Application Server Gang und Gäbe – warum nicht davon lernen?

appserver.io 1.0 – Neuerfindung des Enterprise-PHP
Kommentare

Mit dem appserver.io Iron Horse wurde Version 1.0 der ambitionierten Infrastruktur-Lösung veröffentlicht. Der appserver soll klassische Enterprise-Ansätze in die PHP-Welt transferieren und Entwicklern dabei ein ganzes Set von Services bieten, mit denen sich die Arbeit in großen und performanceintensiven Applikationen erleichtern. Das Beste daran: Es bietet Multithreading von Haus aus, ist komplett Open Source und hat keine Probleme mit Systemen, die eigentlich gar nicht dafür entwickelt wurden.

Das ist eindeutig der richtige Zeitpunkt, sich intensiver mit einem Projekt zu beschäftigen, in das die Entwickler mehr als zwei Jahre Arbeit gesteckt haben. Wir haben uns also mit Stefan Willkommer, dem geschäftsführenden Gesellschafter der TechDivision GmbH über den appserver, künftige Pläne und seine Wünsche für das Projekt gesprochen. Viel Spaß bei interessanten Einsichten und spannenden Ausblicken!

appserver.io 1.0.0 – das Iron Horse

PHP Magazin: Stefan, ihr habt den appserver.io in Version 1.0 veröffentlicht. Erzähl mal, worum geht es dabei genau?

Stefan Willkommer: Wir haben uns die letzten zwei Jahre intensiv mit Threading und Multithreading im PHP-Umfeld beschäftigt. Letzten Endes geht es bei dem Projekt darum, wie man einen Application Server wie man ihn aus anderen Sprachen kennt – vor allem natürlich aus Java – nach PHP zu portieren und da PHP-Anwendungen darauf aufbauen zu können, die dem klassischen Enterprise-Ansatz gerecht werden.

Ein Application Server ist letzten Endes ein Set von Services, die man als Entwickler in seiner Infrastruktur nutzen kann. Es ist also eigentlich eine Infrastruktur-Lösung, die weit mehr als ein klassischer Webserver wie Apache oder NGINX bietet, da wir nicht nur wie ein Webserver klassisch Anwendungen ausliefern können, sondern zusätzliche Dienste wie einen Timer-Service, ein Message Queue, einen Persistance-Container und – eigentlich eines der spannendsten Themen, eine Servlet-Engine, die Stateful-Applikationen zulässt, ausliefern können. Mit der Servlet-Engine können wir Applikationen Request-übergreifend im Speicher halten und damit dementsprechend Performance gewinnen.

appserver i.o 1.0.0 Iron Horse

appserver.io

appserver.io ist in Version 1.0.0, Codename Iron Horse, in der Open Source License 3.0 erschienen und steht ab sofort auf GitHub zur Verfügung; spezielle Packages findet man in der Download-Sektion der Website. Übrigens: Im kommenden PHP Magazin (3.15) werden wir in einem Tutorial die ersten Schritte mit dem appserver wagen.

PHP Magazin: Das Vorbild kommt natürlich aus dem Java-Umfeld; gerade dort gibt es aber bereits seit einiger Zeit Diskussionen über Sinn und Unsinn von Application Servern … Wo seht ihr also den Vorteil eines solchen Systems?

Stefan: Diese Diskussionen haben wir natürlich auch verfolgt. In Java gibt es aber meiner Meinung nach das Problem, dass das System über die Jahre hinweg extrem gewachsen und komplex geworden ist; das macht den Einsatz eines Application Servers nicht mehr so leicht, auch wenn es das wahrscheinlich noch nie so richtig war. Aber genau das ist es, was wir mit appserver.io bezwecken wollen.

Wir wollen eine Enterprise-Technologie auf einen Markt bringen, der genau das noch nicht bietet und ihn damit eben Enterprise-fähig machen. Das in der Konfiguration ebenso wie im Handling für den Entwickler. Unser oberstes Ziel lautet, dass es einfach zu benutzen und zu installieren sein muss. Wenn wir diesen Anspruch erfüllen und die Komplexität des Systems vor dem Entwickler verstecken können, dann bin ich überzeugt davon, dass es große Potenziale gibt, die sich damit entfalten lassen.

Das Gute daran ist aber auch: Wenn er einen Blick unter die Haube werfen will, dann kann er das tun. Der Application Server ist vollständig in PHP geschrieben – ein PHP-Entwickler kann also auch tief ins System einsteigen. Dennoch haben wie die Funktionalität so gut gekapselt, dass sie für den Entwickler in erster Linie keinen Overhead darstellt.

PHP Magazin: Einfach zu installieren, einfach zu nutzen … was also genau muss man machen, um den Application Server zum Laufen zu bekommen?

Stefan: Wenn du es lokal testen willst, dann lad ihn dir herunter – im besten Fall hast du einen Mac, dann kannst du einfach das Installer-Paket nutzen. Einfach kurz durchklicken, und innerhalb weniger Sekunden ist er mit einer Congrats-Seite und einer Example-App up & running. In der Example-App sind zahlreiche Beispiele enthalten, die zeigen, wie man die einzelnen Services nutzen kann. Darunter sind auch Beispiele die zeigen, wenn ich das einmal böse formuliere, wie man seine, „Legacy-Applikationen“ darauf laufen lässt – also klassische PHP-Applikationen, die zunächst noch keinen Nutzen aus dem Application Server ziehen können. Die können trotzdem ganz normal über den mitgelieferten PHP-FPM ausgeführt werden.

Im Prinzip ist der appserver.io also erst einmal eine Runtime, die zusätzliche Services bietet. Man kann also jederzeit seine lokale Entwicklungsumgebung durch den appserver ersetzen.

Was die Serverseite angeht, haben wir ebenfalls eine breite Palette abgedeckt. Wir haben Pakete für Debian, CentOS, Fedora, und auch für Windows gibt es mittlerweile einen Installer – wir haben also erst mal alle wichtigen Plattformen abgedeckt.

Die Vorteile des appserver

PHP Magazin: Was muss ich beachten, wenn man als Entwickler eine Anwendung schreiben möchte, die alle Vorteile des appservers nutzt?

Stefan: Als allererstes geht man am besten auf die Get-Started-Sektion auf der Website – dort findet man ein My-First-Web-App-Tutorial. Darin wird in allen Einzelheiten mit Best Practices beschrieben, wie man die Infrastruktur nutzen kann. Es wird auch gezeigt, von welchen Services man bei der Servlet-Engine ableiten muss und welche Schritte notwendig sind, um seine Applikationen stateful in den Speicher zu laden, so dass sie auch über mehrere Requests hinweg im Arbeitsspeicher bleibt. Ich denke, dass man da schon sehr viel daraus ziehen kann.

Darüber hinaus gibt es eine sehr umfangreiche Dokumentation, in der alle Services beschrieben sind. Allerdings gibt es auch abseits davon viele Möglichkeiten, wie man Probleme angehen kann; also nicht nur die von uns vorgeschlagenen Möglichkeiten, wie man an das Thema herangehen kann. So haben wir bereits mit vielen Entwicklern gesprochen, die schon ganz andere Ideen haben. Wir führen beispielsweise gerade Gespräche mit Entwicklern, die so etwas wie Spring bauen möchten. Die gehen gedanklich einen ganz anderen Weg als wir. Das ist gar nicht schlimm – im Gegenteil: Es ist spannend zu sehen, dass es Leute gibt, die verstehen, worum es geht, und die dann Lust haben, damit zu experimentieren.

PHP Magazin: Du erwähntest vorhin „Legacy Applikationen“. Wie sieht eurer Meinung nach also der typische Anwendungsfall aus, in dem eine Applikation vom appserver profitieren kann?

Stefan: Ich bin überzeugt davon, dass sie dann profitieren kann, wenn man zusätzliche Services auf Basis einer bestimmten Applikation entwickelt. Wir haben dafür ein Beispiel mit Magento im Tutorial-Bereich, das zeigt, wie man das E-Commerce-System in den appserver installiert; und wie man daraus perspektivisch gesehen einige Vorteile daraus ziehen kann. Ein Beispiel wäre da, wie man die Cronjobs in Magento über den Timer-Service des appservers laufen lassen kann, was vor allem im Bereich der Ausführung einige Vorteile bietet.

Ein weiterer Punkt wäre, wie man die Rewrite-Engine des Webservers des Appservers nutzen könnte, um beispielsweise in sehr großen Systemen mehr Performance aus den Rewrites herauszukitzeln.

Einer der zentralsten Punkte liegt meiner Meinung nach jedoch im Bereich des Produktdatenimports. Jeder Shopbetreiber muss Produktdaten importieren, und wenn die Anzahl irgendwann einmal sechs- oder gar siebenstellig wird, dann dauert das sehr lange. Das ist nicht nur bei Magento so, sondern das betrifft viele Systeme, teilweise auch solche aus dem Enterprise-Segment. Durch den Multithread-Ansatz, mit dem man alle Kerne der CPU mit einem Import-Prozess nutzen kann, kann man die ganze Sache extrem beschleunigen. Wenn man so etwas also als Service aufsetzen würde, könnte man sich mit einem solchen Setup extreme Vorteile gegenüber einer klassischen Infrastruktur sichern.

Natürlich könnte man sich ein Message Queue auch von einem Drittanbieter installieren – aber so kommt eben alles in einem Paket, das darüber hinaus auch noch vollständig in PHP geschrieben ist.

PHP Magazin: Du erwähnst immer wieder, dass man eine Applikation stateful machen kann. Habt ihr Performance-Vergleichswerte?

Stefan: Ich möchte mich da gar nicht so weit aus dem Fenster lehnen … Wir sind gerade in intensiven Gesprächen mit einem Softwarehersteller, der bereits Performancetests mit dem appserver und einem Prototypen seiner Anwendung gemacht hat; im Vergleich auf Basis eines Apache und eines NGINX. Da war dann vor allem im Bereich der Skalierung schnell ersichtlich, wo die Stärken des appservers liegen. Denn ab einer bestimmten Anzahl von Requests war der Apache einfach mal weg, hat einfach nicht mehr reagiert. Der appserver hat in dieser Situation noch eine sehr gute Performance geliefert. Die Anwendung lag im klassischen Apache ungecached beim Erstaufruf bei ca. 400 bis 500 Millisekunden; im appserver konnte man das auf unter 100 Millisekunden drücken. Das ist schon ein deutlicher Performancegewinn.

In wie weit das in einem Live-Szenario funktioniert, kann ich natürlich nicht beantworten. Wir haben natürlich auch ein paar kleine Tests für uns gemacht, in denen wir zeigen konnten, dass Performancegewinne möglich sind, aber ich denke, dass die Welt da draußen mal zeigen muss, wo der Weg hinführen kann.

Künftige Projekte

PHP Magazin: Du hast mir verraten, dass ihr im Gespräch mit einem E-Commerce-Anbieter seid. Wie weit sind diese Gespräche fortgeschritten, und wie könnte eine mögliche Zusammenarbeit aussehen?

Stefan: Die Gespräche würde ich als durchaus intensiv beschreiben. Letzten Endes ist es so, dass der Hersteller sieht, dass es in manchen Bereichen wie beispielsweise im Import Schwächen gibt. Und diese Probleme lassen sich mit Tools lösen, die zum Teil schon existieren. Eine integrierte Infrastrukturlösung aber wäre für noch einmal ein großer Fortschritt; vor allem dann, wenn auch noch ein Hersteller dahinter steht, der auch noch Services anbietet.

Gerade deswegen sind wir jetzt auch dabei, ein Partnerprogramm aufzuziehen, das wir dann in unterschiedlichen Kategorien supporten können – vom klassischen Vendor, der eine Form von Support benötigt, wenn er seine Software drauf aufbauen und optimieren möchte, bis hin zum Solution-Partner, der den appserver für individuelle Implementierungsszenarien nutzen will. Und zukünftig betrachtet natürlich auch gerne Hosting-Partner, die den appserver als Infrastrukturlösung im Hosting-Setup anbieten wollen.

PHP Magazin: Du hast vorhin erwähnt, dass jemand bereits Interesse gezeigt hat, Spring nachzubauen. Wie kann man sich das vorstellen?

Stefan: Wie weit das ist, kann ich im Moment gar nicht sagen, ich habe das selbst nur am Rande im Chat nachverfolgt – der ist öffentlich, da kann jeder gerne selbst einen Blick riskieren.

Wenn ich das richtig verstanden habe, geht es letzten Endes darum, dass den Entwicklern hinter dieser Idee die Frameworks aus dem PHP-Umfeld an manchen Stellen nicht weit genug gehen, beziehungsweise an anderen Stellen zu weit. So wird ihnen beispielsweise im Bereich der Requests zum Teil zu sehr abstrahiert – ein Bereich, der durch den appserver mit seinem eigenen Webserver ja bereits abgedeckt ist. Sie kommen aus dem Java-Umfeld und versuchen das so ähnlich der Java-Infrastruktur aufzubauen. Das sollte dann auch einem Java-Entwickler einen relativ guten Einstieg in die PHP-Enterprise-Welt bieten.

PHP Magazin: Diese appserver-Geschichte – kann man sich das so vorstellen, dass es eine Art App Store gibt, in der man sich Applikationen oder Services bei Bedarf installieren kann?

Stefan: Wir haben bereits sehr viele Services an Bord, und wir sprechen natürlich auch intern viel über Ideen und Möglichkeiten. So etwas Ähnliches haben wir konzeptionell bereits ausgearbeitet und auf einer Veranstaltung vorgestellt. So könnte man beispielsweise ein zentrales Repository nutzen, in dem PHP-Anwendungen liegen, die man sich über ein Dashboard im appserver einfach herunterziehen kann. So lässt sich auch das Thema Deployment sehr vereinfacht handhaben.

Ideen, auch so etwas aufzubauen, gibt es durchaus. Aber nicht nur im öffentlichen Stil – so könnte sich zum Beispiel eine Agentur oder ein Unternehmen ein abgeschottetes Repository, also einen privaten App Store, mit dem appserver aufbauen, mit dem sich das Deployment verschiedenster PHP-Applikationen sehr einfach bewerkstelligen lässt.

Der Unterbau

PHP Magazin: Du hast gesagt, dass sei alles in PHP geschrieben – welche Versionen unterstützt ihr?

Stefan: Aktuell unterstützen wir PHP 5.5 und PHP 5.4 – allerdings ist PHP 5.4 nicht mehr vollständig getestet; wir empfehlen also auf jeden Fall den Einsatz von PHP 5.5.

PHP Magazin: Wie steht es um die Zukunftsfähigkeit aus? PHP 5.5 erreicht bald den EOL, PHP 5.6 ist aktuell, die nächste Major-Version ist PHP 7 mit einer komplett anderen Engine …

Stefan: Wir haben das natürlich auf dem Radar; es gibt auch bereits diverse Tests mit PHP 5.6. Wir hatten zwar ein paar Issues, aber letzten Endes basiert der komplette Multithreading-Ansatz auf der pthreads-Extension. Genau dort gab es mit der aktuellen PHP-Version ein paar Probleme, die verhindert haben, dass wir alles auf demselben Stabilitätsniveau betreiben können. Um das zu lösen, hätten wir noch weiter auf die C-Ebene heruntergehen müssen. Wir haben zwar einen Entwickler im Haus der sich aktuell damit beschäftigt, aber vom Zeithorizont wäre das zu knapp geworden – daher unterstützen wir aktuell „nur“ PHP 5.5.

Dennoch haben wir die neuen Versionen in unseren Planungen berücksichtigt; vor allem natürlich PHP 7. Wir hoffen natürlich auch, dass der Ansatz, PHP mit der Multithreading-Fähigkeit im Core auszustatten, weiterhin verfolgt wird – also diese Funktionalität nicht wie bisher über ein Modul zu implementieren. Das wäre für uns eine schöne Entwicklung.

PHP Magazin: Habt ich auch mal die HHVM in Betracht gezogen?

Stefan: Wir nutzen die HHVM sogar über die FasctCGI-Schnittstelle in einem Live-Magento-Projekt; sie zu nutzen ist also kein Problem. Lediglich HHVM in Kombination mit Multithreading ist eben ein größeres Problem.

Interessant wäre die Kombination jedoch, wenn man in PHP einen Just-in-Time-Compiler integrieren würde und das dann multithreadingfähig wäre. Das wäre eine Zukunft, die uns durchaus Spaß bereiten würde.

Gelebtes Open Source

PHP Magazin: Ihr habt appserver.io Open Source veröffentlicht – es kann also jeder seinen Teil dazu beitragen?

Stefan: Es ist wirklich ein komplettes Open-Source-Projekt auf GitHub – wir haben also keine zweite Codebase oder so: jeder kann auf GitHub ins Repository gehen und forken, einen Pull-Reuquest stellen, wir sind da offen.

Aktuell handhaben wir das noch so. Fairerweise muss man aber sagen, dass es eine Enterprise Edition geben wird, die separat von dem Open-Source-Projekt laufen wird.

PHP Magazin: Ihr habt jetzt Version 1.0 – Iron Horse – veröffentlicht; Version 1.1 wird Iron Knight heißen. Habt ihr euch einen fixen Releasezyklus vorgenommen?

Stefan: Intern haben wir durchaus eine Roadmap – sowohl für Version 1.1 als auch für die Featuresets der parallelen Enterprise-Editionen. Unser Zeitplan dafür ist allerdings noch nicht final. Ohne jetzt zu viel zu versprechen kann ich sagen, dass es sicherlich nicht superlange dauern wird, bis Version 1.1 erscheint.

Was die Enterprise Edition angeht, kommt es ein wenig darauf an, wie sich die Hersteller, mit denen wir im Gespräch sind, verhalten. Gerade was die Frage nach dem Featureset angeht, da es da unterschiedliche Ansätze und Wünsche gibt. Natürlich steht das Clustering dabei ganz weit oben auf der Liste, aber der eine oder andere hat noch zusätzliche Wünsche, und da kommt es natürlich auf den Support der Hersteller an. Und natürlich spielt es auch eine Rolle, was in der Community passieren wird, das ist wichtig in so einem Projekt. Wir haben jetzt relativ viel investiert, aber langfristig wird sich so etwas nur durchsetzen können, wenn auch die Community mitzieht.

PHP Magazin: Zwei Jahre habt ihr daran gearbeitet – wie viele Entwickler haben daran gearbeitet? Und wie kann man sich den Entwicklungsablauf eines solchen Projekts vorstellen?

Stefan: Rein von der Entwicklungsseite betrachtet sind drei Entwickler im Core-Team; natürlich nicht immer durchgängig über die zwei Jahre. Es gab auch Phasen, in denen nicht so viel im Projekt gemacht werden konnte. Im letzten Jahr aber wurde ziemlich durchgängig in dieser Mannschaftsstärke entwickelt.

Wir mussten in der Zeit viele Probleme und Themen umschiffen, und da gab es so gut wie keine Erfahrung. Das Thema Multithreading beispielsweise ist eben etwas relativ neues, gerade in dieser Komplexität, die wir hier ansetzen. Eine Webserver-Implementierung ist nichts, was man mal eben so nebenbei entwickelt. Und das ist nur eine Komponente davon.

So sind wir immer wieder auf Probleme gestoßen, zu denen man auch im Web nichts gefunden hat – wir mussten uns also selbst entlang hangeln. Daher haben wir auch immer wieder das API umgestellt, viel refactored … im Prinzip sind wir von einem Prototypen in den nächsten geschlittert, bis wir letztes Jahr im Sommer so weit waren, dass wir erkannt haben, wie die Architektur überhaupt aussehen kann.

Im letzten halben Jahr ist also die Version entstanden, die jetzt veröffentlicht wurde. Natürlich mit viel Erfahrungswerten und Code, den wir vorher schon entwickelt haben, aber dieses letzte halbe Jahr wurde die eigentliche Architektur und das Projekt so, wie es jetzt vorliegt, finalisiert.

PHP Magazin: Abschließend betrachtet – wie soll das nächste halbe Jahr für euch laufen? Was sind deine Wünsche?

Stefan: Ich wünsche mir, dass die PHP-Welt offen für diese Technologie ist. Das ist es, womit wir stehen und fallen. Wir brauchen eine Community, die das unterstützen will. Es ist im Vergleich zu bisher einfach ein anderer Ansatz, Anwendungen in PHP zu entwickeln, das sollte man immer im Hinterkopf behalten. Das mag anfänglich vielleicht nicht ganz einfach sein, aber ich glaube, dass man am Ende davon profitieren kann.

Ich wünsche mir also eine Community, die es einfach einmal ausprobiert, damit experimentiert, Feedback gibt und sich daran beteiligt. Parallel wünsche ich mir natürlich auch noch ein paar Hersteller, die das Potenzial erkennen, auf uns zukommen und ihre Produkte auch entsprechend auf dem appserver aufbauen wollen.

Stefan WillkommerStefan Willkommer ist geschäftsführender Gesellschafter der TechDivision GmbH und verantwortet dort den Bereich Technik und Controlling. Er studierte Informatik an der Fachhochschule Rosenheim und beschäftigt sich seit 15 Jahren mit Open-Source-Technologien rund um das Internet. In den Bereichen E-Commerce und Content Management konnte er speziell in den letzten 5 Jahren viele internationale Projekte für namhafte nationale und internationale Kunden erfolgreich begleiten. Darüber hinaus treibt er in der TechDivision GmbH die agilen Transformationsprozesse voran.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -