A recent manager of mine worked tirelessly to drill this concept into our team: Build, Package, Deploy. If you step back and think, it is a very simple, yet powerful paradigm. I work in an environment that has not fundamentally changed the way we deploy J2EE applications for at least, I am only guessing here, but could be close to 10 years. The group that managed the Internet defined a standard footprint, multi-site J2EE cluster, with all components (Servlet, EJB, etc.) deployed on the same instance. Everyone was given the same configuration and we ended up building a large collection of heavy, monolithic applications. The worst part was that each application was dependent on the specific J2EE container and hardwired to the deployment environment, making an extremely static, inflexible, unscalable solution. Many of us developer’s silently rebelled against the J2EE bandwagon and built simple Servlet-based applications; making sure to use as little as possible, from the provided J2EE container (no connection pools, or even JMS). We pushed to use a simple Servlet container, such as Tomcat or Jetty, but our pleas went unanswered. The default architecture was structured in such a way, that everyone created huge, highly coupled, monolithic web applications; a single WAR that did everything, from vending JSPs, to performing business functions, to accessing the database. Unfortunately, I too was brainwashed by the architecture and stopped thinking about how architecture could be done differently. Fortunately for me, that recent manager was new to the company and had completely different ideas about architecture. Instead of starting a revolution, we embarked on a evolutionary journey to change the way we build software, rather than focusing on how the systems were deployed. One of the first points of enlightenment, to change the way we thought about building system: build it, package it, and then deploy it.
I will tie this paradigm back to the Lean principle of postponing decisions (committing to something) until you actually have to make the decision (the commitment). How does this apply here? When we build applications today, the developers know up front, where and how the system (code) will be deployed. The developer will make design decisions, many of which are unconscious, based on their knowledge of the deployment environment; hardwiring their implementation for what the application will look like when it is deployment. Without giving this much thought, it almost sounds like the right process. Unfortunately, we probably just boxed ourselves right into a corner!
Would it not be better, if the developers simply built components, the true business functionality, without thinking about how the software would ultimately be packaged or deployed? Obviously, there would be some architectural patterns to be followed, but the developer’s would have no idea how their component will be assembled into the final application. Now let’s imagine that we have a Component Packaging Specialist; they would be responsible for bundling up components into deployable packages. This person determines the optimal combination of components, creating a virtual application that performs the required business functionality. This virtual application is bundled in such a way as to create minimal dependencies between bundles, which are independently migrate-able and allow high scalability. Finally, the bundles are given over to a Deployment Specialist, who figures out how best to deploy the virtual application into the environment. Depending on the operational requirements, the virtual application could be deployed in any J2EE or simple Servlet container. How many of each bundles are to be deployed would be determined by the predicted transaction volumes. If the actual volume exceeds the expectations, the Deployment Specialist can easily adjust the environment to accommodate the volumes, without involving the development staff.
The primary point is to allow as much deployment flexibility as we can afford, by not letting the code dictate how or where the application will be deployed. This approach provides less risk (no need to change code) and creates fewer dependencies (better portability). Developers should remember and separate these three tasks as they design and implement systems, even if one person is performing all three roles. By separating these three tasks (actual disciplines), we should end up with better systems, providing the operational flexibility to meet the ever changing business demands.
