By Tzach Livyatan This post is a response to the excellent presentation “Java Application Servers Are Dead!” by Eberhard Wolff. Go read his slides and come back here.

Back already? Assuming you agree with Eberhard’s claims, let me demonstrate how most of his points on Java Application Servers can be applied to a generic OS (one designed for hardware servers) in the cloud as well.

First let me scope the discussion. An operating system can run on your mobile, desktop, back office, or as a VM on the cloud. For this post, I’m referring specifically to the cloud use case, which can be public or private. Cloud deployments are the important case to concentrate on, as new Java application servers are mostly deployed on VMs these days.

Illustration: Omarcito for Wikimedia Commons (http://commons.wikimedia.org/wiki/File:Omarcito.gif)

Eberhard present different properties of the Java Application Server, and for each, demonstrates why it is no longer relevant. I will follow his footsteps, applying the same methodology to generic OS, for two of the properties: Container for multiple applications and Deployment.

Container for multiple applications

Both the Java application server and the OS are supposed to isolate applications from each other. Both do a good job at it, and OS isolation is definitely somewhat stronger. However, it is still not good enough for multitenancy, even with OS-level containers. This is why we have hypervisors, and this is why most deployment in the clouds include one application per VM.

Deployment

I agree with Eberhard’s claim that Java deployments (JAR, WAR, EAR) are problematic. Linux-style packaging, using RPM or deb packages, is not a full solution either.

In a cloud environment, there is no reason to start with a blank OS, and spend 15 minutes downloading and installing the application. It makes more sense to use a pre-installed server image (AMI, in AWS terms) with the application already installed. Indeed, using a ready-made AMI is a common practice.

Containers are another successful attempt to fix this problem, but running containers on a virtual machine brings an extra layer of complexity. More on that here. Obviously, there is still a requirement to install urgent patches on both AMI and containers.

To summarize, both the Java application server and the generic OS were created to provide a set of services which is no longer required.

With Java AS and generic OS dead, what’s next?

** Micro Services **

“an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API” Martin Fowler Illustration: Martin Fowler (http://martinfowler.com/articles/microservices.html)

Each micro service can can have its own end to end stack, from the OS up to the application. As explained above, an ideal scenario would be to deploy the micro service logic directly on a hypervisor, cutting two middle layers: the application server and the generic OS.

At this point you might doubt my sanity. Run my application on EC2 with no OS at all to support it? Not quite.

As you recall from the “AS are dead” presentation, the application server has become an application library, dedicated to supporting a single application. With the Library OS concept, the the same process can also be applied to the OS, making it a library of the application.

For every micro service, one can use a tool like Capstan to cook a new VM, pre integrating the application, JVM and the OS - to a ready to be deployed VM. Just take it and deploy it on your favorite cloud provider.

Take Capstan for a spin

For more info on Capstan and other OSv subjects, please join the osv-dev mailing list.
You can get updates on by subscribing to the OSv blog RSS feed or following @CloudiusSystems on Twitter.