Simpler Java deployment?

“The service went down because another service running on the same application server went down.” “You can’t use the improved version of your programming language because you’re running on the same application server as some old applications.” “We can’t help you deploy your application on the application server, because we’re busy with some other application.”

If you’ve ever heard any of these statements, you’ve been victim to the accidental complexity of the application server.

[caption id="" align=“alignright” width=“162” caption=“Independent applications”]Independent applications[/caption] How can we make our work easier? The most successful way the field of software development has reduced complexity is by reducing coupling, or more informally, by making stuff independent. The further apart two things are in an organization, the costlier it is to have them depend on each other. Why, then, does the most popular piece of technology within Java Enterprise development increase dependencies? As a matter of fact, to many application developers, the act of installing your application to production seems frightfully difficult. How can we possibly move fast when we’re afraid of what we need to do to get done?

A more pleasant experience installing your application

This is what I want for my installation instructions:

  1. Build a release version the application with a single command.
  2. Copy the resulting executable Jar to your application server nodes.
  3. First time only: Add a or entry to your web server
  4. First time only: Run “java -jar application install” to set up the environment.
  5. Run “java -jar application start” to start the application. The current working directory determines the application settings, so you can run multiple copies on the same node.
  6. Run “java -jar application upgrade new version number” to install an updated version of your application

Does this sound simpler than your current process? Does it sound like you could keep the separate applications separate? Yes, you might want to support executing the commands on a set of application server nodes. But after developing this added functionality and seeing absolutely no interest from the operations department, I’m not convinced that it would be used.

Within reach

I have successfully implemented the approach above. However, the tools I used to do so, Maven, Jetty and plain old Java, don’t really expect the approach, and so there’s a long way to making it streamlined and easy to introduce to new projects. You can consider this post to be a teaser. If you believe the approach I outline has merit above the application server approach, I’d like to know. If you have suggestions for feasible improvements, I’d love to know.

Recently, I’ve not posted as frequently on my blog as I used to. This is in part due to Twitter. I’m practicing brevity by posting most of my ideas there instead of on my blog. I’d love more followers.

Comments:

[kiowa] - Jan 26, 2009

You could also check out Cargo</. Cargo has an maven plugin that enables you to deploy to a wide range of application servers such as web logic, tomcat, jboss, etc..

Anders S - Jan 27, 2009

I love this approach, but I guess that’s no surprise. It’s hard to convince other people though. I guess I’m a believer because I don’t like wasting my time. In any way. And I would like to roll changes as often as possible. Running software is the only measure of progress. ;)

Mike - Jan 26, 2009

Environmentally Aware applications. Nice for when you have a series of servers to deploy to or a cluster of servers. That way an application.jar can literally be moved from testing to acceptance to production with zero changes to the codebase.