An Interview with the Appserver.io Crew

What if you could reliably run PHP without Nginx or Apache, but also without relying on its internal server? What if you could do async operations in PHP with true multi threading, fully taking advantage of multi core processors without hacks or a jungle of callbacks? What if you had drag and drop installation support for your PHAR packaged web apps in an environment identical to its production counterpart? Enter Appserver (application server).

The Appserver is developed in PHP for PHP and lets you do all that and more. There’s no point in me boring you with the technical specifications – instead, here’s the Appserver crew doing their best to explain what it is, why it is, and why you want it.

Screenshot from 2013-10-04 15:40:56

Bruno: Joining us today are Tim Wagner, Johann “Hans” Zelger and, occassionally, Stefan Wilkommer. Let’s start out with a short introduction. Who are you as a group, and what are your roles, individually?

Tim: We’re just some guys working for TechDivision GmbH, a web agency in the south of Germany. Hans is actually working as Head of Magento, I’m still Head of Development. We’ve no real roles actually. Whenever we can we try to work together on new features …

Stefan: I started to work for Tim 12 years ago at TechDivision. In 2006 I took over the company together with my brother Josef and we started working on open source web based projects. When Magento was introduced in 2007 we began to grow quite fast. Hans and Tim joined our Team in 2008 and 2009. Since then we worked on lots of projects in the PHP area. As I am a technician I was responsible for technology in the beginning but my role changed in the last years more in the direction of financial controlling and company strategy.

Hans: I have been working with Tim for a long time on several customer projects for TechDivision GmbH. Tim has had the idea for the Application Server in PHP since I’ve known him. I was fascinated from the beginning, so I started working with him on the project whenever I had free time :)

Tim: Hans is focusing more on stuff like the pthreads integration and UI customization like the design and implementation of the new admin interface or the website. I’m more focused on stuff like configuration, optimization and deployment …

Bruno: So, what is Appserver, and why did you develop it?

Hans: Ok, I think thats Tim’s part… he has an accurate perception of the Appserver :)

Tim: The Appserver is a middleware solution that provides services like a servlet container, a persistence container, a message queue, a timer service (can be used as some kind of CRON job) and a web socket server. We started with the servlet container that is more or less a webserver, not like Apache/Nginx, more like Tomcat. As many PHP applications out there are actually not ready to run in a servlet container, because they do not have any servlets yet, we’re integrating a default servlet for such applications to make them work.

Bruno: Some people might be coming across the term “servlet” for the first time. Could you expand on it a little bit?

Tim: A servlet is a class in which the developer can implement his functionality. For example when you use a servlet engine you don’t have an index.php for bootstrapping. Instead, you have a servlet that may have the role of a controller class, and the main bootstrapping will automatically be done by the servlet container.

Hans: Another important point is that Appserver includes a web server (the servletcontainer) so you don’t need Apache or Nginx or any other alternative in front of your webapps.

Bruno: So, PHP itself serves your app? Does it use the internal PHP webserver as available from 5.4, or something else entirely? How does vhost configuration calculate into all this?

Hans: That’s correct. PHP itself serves the apps installed on the Appserver. We aren’t using the internal php webserver included since 5.4 because we will provide the entire functionality of the Appserver written in clean PHP code. So everyone can improve the webserver functionality without learning C first. At the moment you can edit the main configuration file etc/appserver.xml for adding vhosts that point to specific webapps. Some time soon we’ll provide a backend configuration panel for Appserver where you can do this kind of configuration more comfortably.

Bruno: That sounds great! What about performance? Is this type of PHP’s serving ability comparable to old school solutions like Nginx or Apache? Have you run any benchmarks to compare them in any way?

Tim: I discussed this with another PHP developer today :) We made some tests with Magento recently. On my local machine (Mac OS X Mountain Lion) a Magento catalog page will be delivered in about 320 ms, our Appserver needs 340 ms. From what we can tell, most developers will use the application server to serve existing applications like Magento or TYPO3.Neos. We’ll optimize our servlet container for those kinds of applications in the upcoming releases. As we’ve done no performance optimizations yet we’re actually quite sure that the end performance will be around Apache or Nginx. I’ll add some screenshots :)

Bruno: So about threading – which seems to be one of the main selling points of Appserver – can you explain to our beginner level readers what threading actually is and why PHP needs it?

Tim: Hans is the right guy for that question :)

Hans: Multithreading is a very important thing for the Appserver and the future of PHP thanks to Joe Watkins who started the pthreads extension for PHP some years ago. Through pthreads we’re able to handle every user-request coming from browsers to the servlet container (webserver) at the same time asynchronously. Imagine request-handling without being able to do this in threads. Every user would block the other users’ request as long as PHP processes it and serves the response. As many of you will now say “Ok, why aren’t you using event based loops like done with react-php?” The main advantage of using threads in your application is that all cpu cores will be used instead of just one core running at full load. The other big plus is that your code will stay clean and debugabble without having a callback massacre ;)

Bruno: Can’t argue with that :)

Tim: Additionally, beside the application server, we think that threading is a functionality that can bring PHP to the next level of developing web applications. In our projects we always face problems like big data imports where PHP is lacking. As Hans said before, using threads allows us to import data using all the resources of your machine and not have 23 cores waiting while one will do the job.

Bruno: Excellent. Now, while on the topic of threads.. I’ve seen hundreds of questions wondering about PHP and thread safety. Your documentation also says it requires PHP to be compiled thread safe. What exactly is thread safety, and why would anyone compile PHP in a thread unsafe way, if the former is better?

Tim: You’re right Bruno, we had this problem and discussed that a lot. Finally we found a solution that we think will fit nearly everyone :) To solve the problem of everyone having to compile PHP as thread safe by themself, we created a runtime that delivers a separate system independent PHP runtime environment compiled thread safe. This means that you only have to install this runtime and the application server will work. Actually we’ve got packages for Mac OS X 10.8.x and Debian Wheezy. Hopefully with the next release we will also have an RPM working on Fedora and RH Linux. As I’m not a C developer, I hope I can explain it accurately. Thread safety means that the internal globals also have to be thread safe and should be available in every context by every extension that should work in a thread safe compiled environment, but doesn’t collide by creating a local storage. We also discussed that there are many claims out there saying we’ll have a problem because there are many extensions that are not thread safe. This is true, but many of them work well regardless of thread safety, so we delivered the Appserver with all the default stuff many of the hosters out there also deliver, which should be enough for now. Additionally, we’re contacting maintainers of extensions we think may be useful and discuss to fix things if they are not already thread safe. As there are still extensions that are not thread safe and thread safety is not necessary to run most of the applications out there by default PHP will be delivered without thread safety. On windows there are thread safe compiled binaries available because in some Windows multithreaded webserver environments, like Apache 2, you need thread safety enabled for everything to work as expected.

Bruno: So, Appserver is a full package then? Seeing as Appserver serves apps on its own, is it a rounded up whole like an XAMP package, or do users still need to have preinstalled software to get it to run?

Tim: Yes, the application server is a full package, but on Linux systems we only delivered the compiled PHP together with several configuration files and used the libraries delivered by the system (installation will be automatically done by the distributions dependency management). This is to make sure that security fixes will be closed as soon as the distribution delivers an update. Since Mac OS X has no dependency management solution like APT or YUM we deliver everything that is not part of the default Mac OS X distribution but is necessary to run the application server. Also part of the runtime are init scripts to start and stop the application server and plist files for the Mac OS X launch daemons.

Bruno: Am I then correct in assuming that Appserver is encapsulated enough not to bother people’s current installation of PHP? Users can still have their old setup AND run application server alongside it without any side effects?

Hans: Absolutely correct. It was an important point for us to keep the users running-system clean.

Tim: We didn’t find any side effects yet as we don’t overwrite or replace anything delivered by the distribution.

Bruno: Awesome. About the license now – is Appserver fully open source, and if so, do you intend to keep it as such for the foreseeable future, or do you intend to make some parts proprietary?

Tim: Stefan will give you the answer :)

Stefan: As we are all open source enthusiasts, the Appserver will always be delivered with fully open source code, but as we think this product will increase the enterprise capability of the PHP environment we believe that there will be a high demand of customers for enterprise services and support along with this product. The idea to satisfy these customer needs is in delivering special versions with some more sophisticated monitoring and scaling features as well as SLA and Support.

Bruno: I was going to ask this exact thing next – so you are planning to have a sort of “freemium” model? In other words, you will be offering commercial support and fine tuning for implementation and development of enterprise editions?

Stefan: Exactly. We don’t not have any plans or an exactly defined subscription model ready but we are working on that as we really believe this is an important and essential part for enterprise customers. We are not sure if we should call this enterprise edition but we are using that also as a working title at the moment.

Bruno: Alright. So, what’s the one thing you need most from the community right now, in terms of contributions?

Tim: What we need most are guys that will give the application server a try and try to run their favourite application in it. Addionally, we’ll appreciate every developer who is interested in being a part of our development team and is as fascinated as we are with the idea of bringing the application server to all PHP developers out there as the standard solution for implementing enterprise PHP apps :) As solutions like NodeJS appear we think that it’ll be necessary for PHP also to take the next step and jump into this future where it’s necessary to deliver real enterprise applications based on real enterprise middleware solutions.

Bruno: So a test horde? I think we can help with that :)

Hans: Of course there will always be testing, but we hope to find people sharing our enthusiasm in taking PHP and the Appserver to the next level with their ideas and experience.

Bruno: That makes sense, Johann. There’s no product without its community. What’s Appserver’s current development status, and when do you expect it to be production ready?

Tim: We think we are actually having alpha status for the servlet container, the first part we’ll have to deliver. The other services are in heavy development and can only be used for testing purposes. We have a basic roadmap on what version will deliver which features/services, but we don’t consider it final yet. We hope to finish the servlet container this year, meaning 0.7 will be delivered through December. For a production ready system that delivers all services planned for version 1.0, we targeted the middle of next year :)

Bruno: Nice, let’s hope you hit that deadline! Seeing as it’ll be as close to a single-package solution as we can get these days, how easy or hard would it be to upgrade Appserver with additional PHP extensions? For example, I’m a big fan of Phalcon and being able to use something that powerful in a multi threaded environment would surely be a winning combination.

Hans: You can easily upgrade the Appserver components with the integrated composer binary doing /opt/appserver/bin/composer update. And of course there is also the possibility to install your favourite PHP extension assuming its thread-safe compatible. As we deliver the Appserver as complete package you will find all php tools like PECL and PEAR within the “bin” folder.

Tim: I’ve never heard of Phalcon, but after having a quick look at the website it seems really interesting. I’ve compiled it meanwhile and it seems that’ll work :)

Hans: How agile was that, Tim! :D

Stefan: I’m really impressed :)

Tim: You can do this by cloning the github repository and enter /opt/appserver/bin/phpize inside the extension ext directory. After that you can configure and compile the extension with ./configure --with-php-config=/opt/appserver/bin/php-config && make && make install. After that, you have to add the extension with echo extension=phalcon.so >> /opt/appserver/etc/conf.d/phalcon.so and restart the application server with /etc/init.d/appserver restart. That should do it :)

Bruno: Hah. that’s brilliant! I’m going to give that a go immediately after we finish this interview, sounds too good to be true :) You mentioned Composer and the Quora question gave hint that all components can be downloaded through it. Could you elaborate on that?

Tim: Yes, for sure. As every component of the application server is a Composer module you can update the application server itself with Composer. To do this change into the application server’s base directory and type bin/composer update. That’s all :) But as we’re in heavy developent we do actually NOT recommend this, because there is a really high possibility to fetch some things that are actually not compatible. We hope that with the next version we’ll have some tagged packages, so this should not happen any more. BTW you can find all components on github.

Bruno: Great :) Do you have any plans to present Appserver on PHP conferences around the world?

Tim: Yes, we have :) we have a session at PHPConference in Munich on Monday, October 28, 2013 – 5:00pm to 6:00pm (http://phpconference.com/2013/en/sessions) and i also have a session on PHP Developer Conference in Hamburg on 8th of november from 4:00pm to 5:00pm (http://www.developer-conference.eu/session_post/thread-basierte-anwendungsentwicklung-mit-php/)

Bruno: That’s good exposure, no doubt. Maybe we’ll meet on some of those conferences :) So, where can people find some sample applications to play around with? Where can they go to learn more about the project?

Tim: Yes, I hope we do, Bruno :) You can find sample applications on our github respositories too. Actually we have a Magento and a TYPO3.Neos example that works. To give it a try you can clone the repositories and run the init-instance targets by using ANT. That’ll install the examples in the application severs webroot /opt/appserver/webapps. After installation you have to open the URL http:127.0.0.1:8586/magento or http://neos.local:8586/setup (Neos needs a host entry named neos.local in your /etc/hosts file to work) to finish the installation in your browser. Addionally we are working on PHAR based deployment of applications. We’ve finished some tests with Magento and TYPO3.Neos successfully – you can see that in a video on our Facebook page (https://www.facebook.com/appserver.io). This will also be part of the next version 0.5.8 beta that we’ll release this month :) We’ll provide the installable PHAR’s on our website eventually. They’ll have a signature then so that they can be verified when installion in the application server will be done :) To make it easier in the future, we’ll create something like an appstore where you can download the applications you want to run in the application server directly out of the admin interface – this will make starting out a little bit easier we think!

Bruno: Definitely! Good stuff, I’ll definitely keep an eye on the project as it develops. Do you have anything else you’d like our readers to know before we wrap up?

Hans: We’re currently working on documentation, so meanwhile everyone who needs help can join our irc channel on freenode #appserver. Tim and me are there the most time :)

Tim: And… what we really want to say is: Be part of the application server team and have fun developing cool stuff. We’ll start having code sprints together at famous locations, plan things together and release a great software solution that’ll change the PHP ecosystem… hopefully ;)

Hans: Some weeks ago we had our code spring in Mallorca, Spain. Very efficient and relaxing :)

Bruno: Awesome :) Thank you very much guys, and good luck with further development, I’m sure we’ll talk more on IRC in the coming weeks – I’ll definitely be experimenting.