90

There seems to be a current trend in java space to move away from deploying java web applications to a java servlet container (or application server) in the form of a war file (or ear file) and instead package the application as an executable jar with an embedded servlet/HTTP server like jetty. And I mean this more so in the way newer frameworks are influencing how new applications are developed and deployed rather than how applications are delivered to end users (because, for example, I get why Jenkins uses an embedded container, very easy to grab and go). Examples of frameworks adopting the executable jar option: Dropwizard, Spring Boot, and Play (well it doesn't run on a servlet container but the HTTP server is embedded).

My question is, coming from an environment where we have deployed our (up to this point mostly Struts2) applications to a single tomcat application server, what changes, best practices, or considerations need to be made if we plan on using an embedded container approach? Currently, we have about 10 homegrown applications running on a single tomcat server and for these smallish applications the ability to share resources and be managed on one server is nice. Our applications are not intended to be distributed to end users to run within their environment. However, moving forward if we decide to leverage a newer java framework, should this approach change? Is the shift to executable jars spurred on by the increasing use of cloud deployments (e.g., Heroku)?

If you've had experience managing multiple applications in the Play style of deployment versus traditional war file deployment on a single application server, please share your insight.

Brice Roncace
  • 8,771
  • 7
  • 54
  • 64

1 Answers1

83

An interesting question. This is just my view on the topic, so take everything with a grain of salt. I have occasionally deployed and managed applications using both servlet containers and embedded servers. I'm sure there are still many good reasons for using servlet containers but I will try to just focus on why they are less popular today.

Short version: Servlet containers are great to manage multiple applications on a single host but don't seem very useful to manage just one single application. With cloud environments, a single application per virtual machine seems preferable and more common. Modern frameworks want to be cloud compatible, therefore the shift to embedded servers.

So I think cloud services are the main reason for abandoning servlet containers. Just like servlet containers let you manage applications, cloud services let you manage virtual machines, instances, data storage and much more. This sounds more complicated, but with cloud environments, there has been a shift to single app machines. This means you can often treat the whole machine like it is the application. Each application runs on a machine with appropriate size. Cloud instances can pop up and vanish at any time which is great for scaling. If an application needs more resources, you create more instances.

Dedicated servers on the other hand usually are powerful but with a fixed size, so you run multiple applications on a single machine to maximize the use of resources. Managing dozens of application - each with their own configurations, web servers, routes and connections etc. - is not fun, so using a servlet container helps you to keep everything manageable and yourself sane. It is harder to scale though. Servlet containers in the cloud don't seem very useful. They would have to be set up for each tiny instance, without providing much value since they only manage a single application.

Also, clouds are cool and non-cloud stuff is boring (if we still believe the hype). Many frameworks try to be scalable by default, so that they can easily be deployed to the clouds. Embedded servers are fast to deploy and run so they seem like a reasonable solution. Servlet containers are usually still supported but require a more complicated set up.

Some other points:

  • The embedded server could be optimized for the framework or is better integrated with the frameworks tooling (like the play console for example).
  • Not all cloud environments come with customizable machine images. Instead of writing initialization scripts to download and set up servlet containers, using dedicated software for cloud application deployments is much simpler.
  • I have yet to find a Tomcat setup that doesn't greet you with a perm gen space error every few redeployments of your app. Taking a bit longer to (re-)start embedded servers is no problem when you can almost instantly switch between staging and production instances without any downtime.
  • As already mentioned in the question, it's very convenient for the end user to just run the application.
  • Embedded servers are portable and convenient for development. Today everything is rapid, prototypes and MVPs need to be created and delivered as fast as possible. No one wants to spend too much time setting up an environment for every developer.
kapex
  • 26,163
  • 5
  • 97
  • 111
  • 1
    Thanks for answering, you make some good points. The cloud is the driving factor! In our situation I'd feel more comfortable owning a cloud server a la the Amazon Web Services model (Infrastructure as a Service) as opposed to deploying just the application a la Google App Engine (Platform as a Service), but I suppose this is the old school of thought. So the takeaway: unless we plan on leveraging the cloud in a platform as a service way, war deployments are the way to go rather than managing multiple standalone java web applications on a single server. Thanks again for your input. – Brice Roncace May 06 '14 at 20:52
  • 3
    Just 2cc: you can run multiple _jar-apps_ on single machine with some light HTTP server as proxy, i.e.: nginx, it can be additionally used for typical web traffic like custom CDN, load balancer, firewall, etc. So it's reasonable to consider using it when planning large traffic (it has better performance, then handling every single request - even for static resources via your main app). – biesior May 07 '14 at 14:43