Deployment Plan

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. Please see the patterns & practices guidance for the most current information.

Version 1.0.1

GotDotNet community for collaboration on this pattern

Complete List of patterns & practices

Context

You have developed a component-based application that is logically structured into layers, as described in Three-Layered Services Application. You want to distribute it onto a set of servers that are physically structured into tiers, as described in Tiered Distribution.

Figure 1: Three-Layered Services Application

Problem

How do you determine which tier you should deploy each of your components to?

Forces

When determining which tier to deploy your components onto, you must consider the following forces within the context of your environment:

Layered Application mostly concerns managing design dependencies between components, while Tiered Distribution concerns optimizing the runtime server configuration to meet system-level operational requirements. Therefore, the criteria for structuring your application into layers are fundamentally different from the criteria used for optimizing physical component deployment. For example, one of the driving forces for assigning components to layers is to minimize the dependencies between components in different layers. Conversely, a primary driver for optimizing component deployment is to match a component's resource consumption profile to an appropriate server. This implies that a direct mapping of layers to tiers is often not the best distribution strategy. For instance, the Open Systems Interconnection (OSI) network protocol stack reference model is structured into seven layers. Seven different servers, each hosting a separate layer, are not required or even recommended.

The people who structure the application into layers are often not the same people who structure the hardware infrastructure. People in these two groups often have different skill sets with few skills in common. For example, application architects focus on application components and the relationships between components, while system architects focus on the servers and the networks that connect them.

Each additional tier to which components must be deployed adds complexity, deployment effort, and cost. Deploying all components to one tier is relatively simple. As you add more tiers, it becomes harder to determine which component goes where. Similarly, it takes relatively little effort to deploy all of your components to one location; after you add additional tiers, though, you have to put extra effort into your build and deployment process to decide which component goes where. Finally, each additional tier adds fixed and recurring costs for the additional hardware composing the tier.

The components that compose your application each consume a different amount of resources such as memory, processor utilization, file handles, IO sockets, and disk space. There are two approaches for assigning components to tiers based on this force: specialized tiers and general purpose tiers. Specialized tiers are optimized for hosting components with specific resource utilization profiles. Because the servers in the specialized tier are optimized for a specific profile, each server can host many more components that meet that profile than can a generically configured server. Therefore, using specialized tiers usually results in more tiers with fewer servers per tier. On the other hand, servers in a general purpose tier are generically configured, and so the deployment decision basically becomes: how many components each server can hold before a given system resource is completely consumed. Using general purpose tiers usually results in fewer tiers with more servers per tier.

Different components have different operational requirements such as security, availability, and fault-tolerance. For example, components that are accessed from the Web have different security requirements than do components that are on the corporate side of the perimeter network (also known as DMZ, demilitarized zone, and screened subnet). The same two approaches described for the previous force work here as well. Specialized tiers can be added to host components with specific operational requirements, or a general purpose tier can be configured to meet all operational requirements.

Security requirements often drive you to add tiers, with each tier hosting components that have common security requirements. Beside the added complexity, deployment effort, and cost noted earlier, each additional tier adds to the overall security risk. Each additional tier also adds new servers and other infrastructure that must be secured.

Business, political, or legal considerations may require specific components of a solution to be hosted at specific geographic locations. For example, databases containing sensitive corporate information may need to be hosted at secure corporate data centers, while the application servers that contain the business logic may reside at a third-party hosting facility.

Every process and server boundary that a component invocation crosses adversely affects response time. Component invocations that cross process boundaries are several times slower than in-process invocations, while component invocations that cross the network are an order of magnitude slower than component invocations in the same process.

Solution

The application architects must meet with the system architects to create a deployment plan that describes which tier each of the application's components will be deployed to. Key to the success of this meeting is that both parties are starting from a set of high-quality requirements that are precisely specified down to a testable level. For example, a requirement stated as "The application must be scalable" is not specific enough to be testable. A more testable requirement would be: "The application must support 50 concurrent users with two second response time at launch and must scale up to 500 concurrent users with three second response time." This requirement is also phrased in a way that both system and application architects can understand. In addition starting from specific requirements, both parties must be intimately aware of the technical, legal, and business constraints that will be imposed on the solution.

Based on these requirements and constraints, the application architects define a set of components as specified in Three-Layered Services Application, and the system architects define a set of tiers as specified in Tiered Distribution. The discussion between the two parties while performing this mapping often causes significant changes to the components and tiers as each party becomes aware of the other's perspective.

You start the meeting by mapping the component roles defined in Three-Layered Services Application to tiers, using the forces described earlier as a guide. For example, user interface components may be mapped to the Web tier, whereas business components are almost always mapped to the application tier.

The next step is to go through each component in the application and assign it to a tier. In most cases, you can assign a component to a tier by determining what role it plays in the application and then assigning it to the corresponding tier identified for that role in the previous step. However, some components inevitably have unique operational or resource requirements that will cause them to be mapped to alternative tiers. Although these special cases are expected, too many of them indicate that you may need to modify the initial mapping of roles to tiers.

While assigning components to tiers, you may be unable to find a tier that is a good match for a component. When this happens, the two teams must work together and determine the cost and benefits of modifying the component to better work with the infrastructure, or modifying the infrastructure to better suit the component.

Several common deployment plan models for enterprise applications have been identified, based on Three-Layered Services Application: simple Web application, complex Web application, extended enterprise application, and smart client application.

Simple Web Application

The simple Web application configuration deploys all components into a single general-purpose tier. This configuration, which is shown in Figure 2, is the least complex and simplest configuration to understand.

Figure 2: Simple Web application deployment

Complex Web Application

The complex Web application configuration, shown in Figure 3, separates the presentation and domain components and deploys them to different tiers that have been specialized to address their unique requirements.

Figure 3: Complex Web application deployment

The user interface components (UIC) and user interface process components (UIP) are exposed to the Internet and can potentially interact with numerous clients. Because these presentation layer components are often exposed outside a company's firewall, they typically have much more restrictive security requirements than do components that are not exposed. Also, many organizations mandate that servers exposed to the Internet cannot contain any sensitive data. Therefore, putting the presentation layer components into a separate tier and configuring that tier for maximum security greatly increases the overall security of the solution with minimal impact on the components that have less severe security requirements.

Because presentation layer components are exposed to the Internet, their performance and scalability requirements typically differ from those of domain and data access layer components. Presentation layer components are often optimized to handle many concurrent users who interact with the components in bursts. Domain and data access layer components are often optimized to handle a steady stream of requests from a relatively few number of sources. It can be difficult to configure a single tier to adequately support both sets of optimizations. Therefore, the solution is to use two tiers, each optimized for the type of components they host.

Extended Enterprise Application

Extended enterprise applications consume services provided by other applications and may also expose functionality as services to be consumed by other applications. Figure 4 shows this deployment configuration.

Figure 4: Extended enterprise application deployment

The reasons for placing the service gateways (SG) and service interfaces (SI) in the Web tier are the same as for placing the presentation components in the Web tier, as discussed earlier in this pattern.

Smart Client Application

The smart client configuration deploys the user interface components onto the client tier instead of the Web tier. The primary motivation for moving the presentation components to the client tier is that rich user interfaces demand a high degree of interactivity with the user. Mainstream Web technology does not support these rich user interface requirements. Figure 5 shows the smart client configuration with the additional tier.

Figure 5: Smart client application deployment

Note: Large enterprise applications tend to look like a composite of one or more of the models discussed in this pattern. For instance, while most business components of an extended enterprise application run in the application server, a few might run in the Web farm and one or two might run in the browser for performance reasons.

Resulting Context

The meeting between the application development and system infrastructure teams is critical for successful application deployment. The resulting deployment plan provides the following benefits:

Assigns components to tiers to meet the requirements of both teams.

Facilitates communication between the two teams and defines the contract that both teams agree to abide by. If one of the teams cannot fulfill its commitments, then the two teams must get together and redefine a new contract.

Note: The meeting between the application development and system infrastructure teams will not produce an optimum deployment plan unless the corporate culture recognizes the equal importance of both the application and system architecture views. Both teams must be flexible and willing to seek compromises that enable both teams to fulfill their requirements.