You just baked the first release of your application using Maven. Next you start up the administrative console of the application server in the development environment. Then you deploy the fresh loaf of ear-file to the server and fire up your browser to see if you can reach the application. As you try to load the page, you get a DNS error, "Host not found". Time to phone Bob! - the friendly operator of all that funky infrastructure and middleware. Bob is of course happy to add a DNS record that will point www.app-in-dev.com to an Apache server. "Wait! An Apache server?"-you exclaim! "But it should point to our application server, not an HTTP server thing."

Bob, by now used to having to teach young developers the intricacies of modern network topologies, calmly explains that all requests coming from a browser first must go through a cluster of HTTP servers before the requests are routed to the application servers. "You also need to configure Apache!" he says. "But I am developing a Java application, I only need to deploy to an application server and then I am done." you respond. Bob, sighs. "Listen son, pressing the deploy button in the administrative console is only a small sentence in the big deployment story."

The goal of a deployment

Before I start talking about the full deployment story, you first have to realize what the goal of a deployment is.
It is: "Making an application available to end users". This means that the end user has opened his/her browser, types "www.app.com" and sees the application in production, hence the www.app.com URL, fully functional!

So what is needed to run the application? Let's follow the end user's browser request and see what components it hits;
First it hits a firewall, then an http server, another firewall, the application server and finally the application running in the application server which uses a database to retrieve some data. In total there are 5 components involved to get the application successfully available: we need to not only configure all 5 components but also place some data on some of those components and make sure they are (re-)started in the correct order to get the pretty picture to the end-user.

If I were to write down all the steps needed to do a full deployment of the application in production it would be something like

a. Run create table definition SQL scripts against the database.
b. Configure JDBC data source in the application server
c. Configure http ports and virtual hosts in the application server so the application is reachable for http requests
d. Install the application on the application server
e. Start the application
f. Configure the firewall, by opening ports to allow communication between the http server and the application server
g. Configure an http server so requests that are coming in for "www.app.com" that do NOT end with e.g. .js,.html,.gif are routed through to the application server
h. Place the static html content on the http server
i. (re-)Start the http server so it reads in the new configuration
j. Configure the outside firewall, to allow access from "www.app.com" to route to the right http server

Of course, a more complex environment just adds steps to the deployment step list. For example, in a high available clustered environment, I have to do everything at least twice and make sure that all the components are configured and (re-)started to run in that clustered environment.

A deployment really is...

The above steps make sure that "an application is available to end users" in production. They can generally be broken down into the following deployment categories, and thus this is what a deployment really is:

1. Installing applications (Step d.)
This is the core part of the deployment, where the actual application logic is installed on the server, in J(2)EE/Java this usually means installing an EAR or WAR file.

2. Configuring resources (Step b.)
The application might need data from other systems, like databases or mainframes. The application can use resources to query for or receive data. Resources are typically configured in the application server.

3. Configuring middleware components (Step a, c, f, g, h, j.)
To reach the application or to provide an instance where the application can run or house data on (e.g. create application server clusters, http server instances, create database instance, create/update tables) middleware must be configured.

4. Starting/Stopping components (Step e, i.)
To make sure that a component can function properly, it might need to be (re-)started.

5. and doing all the above (1, 2, 3, 4) in the right order.
To make sure the application starts up nicely, without errors some order has to be maintained as what component needs to (re-)start at what time. E.g. If you install the application (step d.) and start it before the data source is configured (step b), the application might not start up properly. This becomes even more important when deploying a new version of your application in a high available clustered environment.

There is one additional category for companies that use a DTAP (Development, Test, Acceptance, Production) environment setup:
6. Configuring the installed application for different environments
A deployment must make sure to customize the configuration to suit a specific environment. E.g. when you install an application on development it needs some data from the development database, the same application in test needs data from the database in test, and so on.

What a deployment is not...

A lot of people seem to think that installing the application on an application server is the actual deployment. Sure, the button in the application server administration console says, "Deploy application" but that will only do the application server part and will only work in simple environments, like the development or developer workstation environments. As soon as the application reaches a more complex environment with multiple middleware components it just does not cut it anymore and you need additional steps to make the application accessible to test/end users.

What or who can do a real deployment

Most people are relying on other people to make the real deployment happen, manually configuring middleware, pressing the deploy button in the administration console and all that other stuff. Some are trying to automate deployments and are relying on deployment scripts or products like Phurnace or Buildforge, but these will only do a very small part of the real deployment, only installing applications (see category 1 above) and configuring resources (see category 2 above). There aren't many products around on the market that can do "real" deployment. XebiaLabs offers a product named Deployit that has supports for all 6 deployment categories.

Be aware of what it takes

So if you aren't in the lucky position of having access to a product that does real deployment, be aware of what needs to be done to get your application available to the end user. Do some scripting, make use of deployment tools and reserve time in your project to let (operations) people configure those middleware components manually.

Filed under Deployment, Xebia Labs | No Comments »