4th Deployment Model Deployment plan (deployment planning)

A component-based application has been developed that is logically constructed as a multilayer structure, such as the three-layered Services application. As described in. You want to distribute it across a set of servers that are physically hierarchical, as described in tiered distribution.

Figure 1: Layer three service Application

Impact factors

When deciding which tier to deploy components to, you must consider the following factors in the context of your actual environment:

• Layered application mainly involves the management of design dependencies between components, while "Tiered distribution" involves optimizing the runtime server configuration to meet system-level operational requirements. Therefore, the criteria on which applications are organized into multi-tiered structures are fundamentally different from the standards used to optimize the deployment of physical components. For example, one of the primary drivers for assigning components to different tiers is to minimize dependencies between components in different tiers. Conversely, the primary driver for optimizing component deployment is to match the resource consumption profile of the component to the appropriate server. This means that direct layer-to-stage correspondence is usually not the optimal distribution strategy. For example, the Open Systems Interconnection (OSI) network protocol stack Reference model is constructed as a seven-tier structure. No one will ask for or even recommend hosting a tier on seven different servers, respectively.
• The construction of multi-tier applications and the construction of hardware infrastructures are usually done by two different categories of people. These two types of people often have different skills, and they have fewer skills in common. For example, the application architecture focuses on the relationship between application components and components, and the system architecture focuses on the servers and the networks that connect them.
• Each additional level of hardware that deploys components increases the complexity, deployment effort, and cost. It is relatively straightforward to deploy all components to the same level. As the progression increases, it becomes increasingly difficult to determine which components should be deployed to which tier. Similarly, the amount of work required to deploy all components to one location is relatively small, and after you add more levels, you must put in additional effort after the build and deploy process to determine which tier should be deployed to. Finally, each additional level increases the fixed and recurring costs of the additional hardware that makes up the tier.
• Each component that makes up an application consumes a different amount of resources, such as memory, processor utilization, file handles, IO sockets, and disk space. Depending on this factor, there are two ways to allocate components for each level: private and general. The dedicated tier is optimized for components that reside with a configuration file that uses a specific resource. Because the servers in the dedicated tier are optimized for a specific profile, the capacity per server for the components that meet the profile is much larger than the server configured by the general method. Therefore, using a dedicated level usually results in a larger number of stages, but fewer servers per level. On the other hand, servers in the general-purpose tier are configured on a regular basis, so deployment decisions take into account the following factors: how many components each server can hold before a given system resource is completely exhausted. Using a common level usually results in fewer series, but there are more servers per level.
• Different components have different operational requirements, such as security, availability, and fault tolerance. For example, components that are accessed from the Web and from the corporate side of the perimeter network (also known as DMZ, network isolation, and screened subnets) have different security requirements. The two methods of the previous influence are equally applicable here. You can increase the dedicated tier to host components with specific operational requirements, or configure a common level to meet all operational requirements.
• Security requirements often drive you to increase the level and enable each level to reside in components that have common security requirements. Each additional level increases the overall security risk in addition to the added complexity, deployment effort, and cost mentioned earlier. Each additional level also increases the number of new servers and other infrastructure that need to be secured.
• Business, political, and legal considerations may require that specific components of the solution reside in a specific geographic location. For example, a database that contains company-sensitive information might need to reside in a secure corporate datacenter, while an application server that contains business logic might reside on a third-party hosting device.
• Each process and server boundary that a component call crosses can adversely affect response time. Component calls across process boundaries are several times slower than in-process calls, and component calls across the network are slower than the number of component calls in the same process.

Solution Solutions

The Application architect designer must work with the system architect to create a deployment plan that explains what level each application component will be deployed to. The key to successful communication is that both parties begin with a clearly defined set of high-quality requirements and are refined down to the testable level. For example, the "Application must be scalable" requirement is not specific enough for testability. A more testable requirement might be: "The application must support 50 concurrent users with a two second response time at startup, and must be extensible to support 500 concurrent users with a response time of three seconds." "This requirement should also be articulated in a way that the system and application architects can understand." In addition to starting from a specific requirement, both parties must also have a thorough understanding of the technical, legal, and business constraints that will be imposed on the solution.

Based on these requirements and constraints, the Application Designer defines a set of components (specified in the three-layered Services application), and the system designer defines a set of levels (specified in the hierarchical distribution). The process of performing this mapping, in a discussion between the two parties, often leads to significant changes in components and levels because each party is aware of the other's point of view.

To expand this communication activity, the aforementioned impact factors should be used as a guideline to map the component roles specified in three-layered Services application to a level. For example, a user interface component can be mapped to a Web-level, and business components are almost always mapped to the application level.

The next step is to consider each component in the application and assign it to a level. In most cases, the component is assigned to a level by determining the role that the component plays in the application and assigning it to the appropriate level in the previous step for that role. However, some components inevitably have unique operational or resource requirements that cause them to map to alternating multilevel. Although these special cases are expected, you may need to modify the initial mapping between roles and levels if the number is too large.

When you assign a component to a level, you may not find a level that is better matched to a component. If this happens, then two teams must work together to determine their costs and benefits by modifying the components to better fit the infrastructure or modifying the infrastructure to better fit the components.

Based on the three-layered Services application, several common enterprise application deployment planning models have been identified: simple Web applications, complex Web applications, extended enterprise applications, and smart client applications.

Simple WEB Application

A simple WEB application configuration deploys all components to a common level. This configuration (2) is understood to be the least complex and simplest configuration.

Figure 2: Simple WEB Application Deployment

Complex WEB applications

The complex WEB application configuration (shown in 3) will represent the separation of component and domain components and deploy them to different levels (specialization to handle their unique requirements).

Figure 3: Complex WEB application Deployment

User interface components (UIC) and the UI Process component (UIP) are exposed to the Internet and may potentially interact with many clients. Because these presentation-tier components are typically exposed outside the corporate firewall, their security requirements are often much more restrictive than the exposed components. In addition, many organizations require that servers that are exposed to the Internet not contain any sensitive data. Therefore, by putting the presentation layer component in a single tier and configuring it for maximum security, you can significantly improve the overall security of your solution while minimizing the impact on components that have less security requirements.

Because the presentation layer component is exposed to the Internet, its performance and scalability requirements are often different from the performance and scalability requirements of domain and data access layer components. The presentation layer component is typically optimized for handling many concurrent users who interact with the component in a burst fashion. Domain and data access layer components are typically optimized for processing stable request flows from a relatively small number of sources. Configuring a level that fully supports these two sets of optimizations can be very difficult. Therefore, the solution is to use level two and make each layer optimized for the type of component that resides.

Extended Enterprise Applications

Extended enterprise applications use the services provided by other applications, and may also expose functionality as a service for use by other applications. Figure 4 shows this deployment configuration.

Figure 4: Extended Enterprise Application Deployment

The reason for placing the service Gateway (SG) and service Interface (SI) at the web level is the same as the reason for placing the component in the Web tier, which is discussed earlier in this schema.

Smart client Applications

The smart client configuration deploys the user interface components to the client level instead of the Web tier. The main motivation for moving the presentation component to the client level is that the rich user interface needs to have the ability to interact highly with the user. These rich user interface requirements are not supported by mainstream WEB technologies. Figure 5 shows the smart client configuration with other levels.

Figure 5: Smart client application Deployment

Note : Large enterprise applications often seem to consist of one or more of the models discussed in this pattern. For example, although most business components in an extended enterprise application are running in an application server, there may be several components running in the Web farm for performance reasons, and there may be one or two running in the browser.

Result context

Communication between application development and the system infrastructure team is critical to the successful deployment of the application. The final deployment plan has the following benefits:

• Assign components to a level to meet the requirements of two teams.
• Facilitates communication between the two teams and details the contracts agreed to by two teams. If one of the teams fails to meet their commitments, then two teams must come together and re-enter new contracts.

Note : communication between the application development team and the system infrastructure team will not produce an optimal deployment plan unless the corporate culture considers the application and system infrastructure views to be equally important. The two teams must be flexible and willing to reach a compromise so that both parties can meet their requirements.

4th Deployment Model Deployment plan (deployment planning)