Chapter 4 Deployment Plan and deploymentplan

Chapter 4 Deployment Plan and deploymentplan

A component-based Application is developed. The Application is logically constructed into a multi-layer structure, as described in Three-Layered Services Application. You want to distribute it to a group of physically multi-level servers, as described in Tiered Distribution.

Figure 1: layer-3 service application

Influencing Factors

When determining the level to which the component is deployed, the following factors must be taken into account in the context of the actual environment:

• Layered Application mainly involves managing design dependencies between components, while "hierarchical distribution" involves optimizing Runtime Server configurations to meet system-level operation requirements. Therefore, the criteria based on which applications are organized into multilayer structures are fundamentally different from those used to optimize the deployment of physical components. For example, one of the main driving forces for assigning components to different layers is to minimize dependencies between components in different layers. On the contrary, the main driver for optimizing Component Deployment is to match the resource consumption configuration file of the component with the appropriate server. This means that it is usually not the optimal distribution strategy to directly map layers and levels. For example, the Open System Interconnection (OSI) network protocol stack reference model is constructed as a layer-7 structure. No one would require or even recommend that you host one layer on seven different servers.
• The construction of multi-tier applications and the construction of hardware infrastructure are usually done by two different types of people. These two types of people generally have different skills, and they have very few skills. For example, the application architecture focuses on application components and the relationship between components, while the system architecture focuses on servers and the networks that connect them.
• The complexity, deployment workload, and cost of each additional level of hardware for departmental components will increase accordingly. Deploying all components at the same level is relatively simple. As the number of levels increases, it is more difficult to determine which components should be deployed to which layer. Similarly, deploying all components to a single location requires a relatively small amount of work. After adding more levels, you must invest additional work after the build and deployment process, to determine which components should be deployed to which layer. Finally, each additional level increases the fixed and repetitive costs of additional hardware that makes up this level.
• Each component of the application consumes a different amount of resources, such as memory, processor usage, file handle, IO socket, and disk space. Based on this factor, there are two ways to allocate components at all levels: dedicated level and general level. The dedicated level is optimized to resident components with specific resources using configuration files. Because the dedicated servers are optimized for specific configuration files, the resident capacity of each server for components that meet the configuration file is much larger than that configured in the conventional way. Therefore, using a dedicated level usually leads to a large number of levels, but the number of servers per level is small. On the other hand, servers at the general level are configured according to the general method. Therefore, deployment decisions mainly take into account the following factors: the number of components each server can store before a given system resource is completely exhausted. Using a general level usually leads to a small number of levels, but each level has a large number of servers.
• Different components have different operating requirements, such as security, availability, and fault tolerance. For example, components accessed from the Web and from the company side of the peripheral Network (also known as DMZ, network isolation and subnet shielding) have different security requirements. The previous two ways of influencing factors also apply here. You can add a dedicated level to resident components with specific running requirements, or configure a general level to meet all running requirements.
• Security requirements usually drive you to increase the level and make each level resident components with common security requirements. In addition to the complexity, deployment workload, and cost mentioned above, each additional level also increases overall security risks. At each additional level, new servers and other infrastructure that require security protection will be added.
• Business, political, and legal considerations may require that specific components of the solution reside in a specific geographic location. For example, databases containing sensitive company information may need to reside in secure corporate data centers, while application servers containing business logic may reside in third-party resident devices.
• Each process and server boundary that a component call spans will adversely affect the response time. Component calls that span process boundaries are several times slower than in-process calls, while component calls that span networks are one order of magnitude slower than those in the same process.

Solution

The application architecture designer must work with the system architecture designer to create a deployment plan to deploy each application component. The key to successful communication is that both parties begin from a set of quality requirements that are clearly specified, and further refine them to the testable level. For example, the "Application must be scalable" requirement is not specific enough for testability. More testable requirements may be: "The application must support 50 concurrent users whose response time is two seconds at startup, it must be scalable to support 500 concurrent users whose response time is three seconds. "This requirement should also be expressed in a concise manner that the system and application architecture designers can understand. In addition to specific requirements, both parties must 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 group of parts (specified in Three-Layered Services Application), and the system designer defines a group of levels (specified in "hierarchical distribution ). During the implementation of this ing process, in the discussions between the two parties, each party is aware of the views of the other party, which often leads to major changes in components and levels.

To start this communication activity, the aforementioned influencing factors should be used as a guide to map the component roles specified in Three-Layered Services Application to levels. For example, user interface components can be mapped to Web-level components, while business components are almost always mapped to application-level components.

The next step is to consider each component in the application and allocate it to a certain level. In most cases, the component is assigned to a level by determining the role that the component plays in the application, and then assigning it to the level determined for the role in the previous step. However, some components inevitably have unique operation or resource requirements, resulting in their ing to alternate levels. Although these special situations are expected, if the number is too large, you may need to modify the initial ing between roles and levels.

When a component is assigned to a level, the level that matches a certain component may not be found. In this case, the two teams must work together to select from components to better fit the infrastructure or to better fit the components to determine their cost and benefits.

Based on 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 Applications

Simple Web application configuration deploys all components to a common level. This configuration (as shown in Figure 2) is the least complex and simplest configuration.

Figure 2: Simple Web Application Deployment

Complex Web applications

Complex Web application configuration (as shown in figure 3) means that the components are separated from the domain components and deployed at different levels (already specialized to handle their unique requirements ).

Figure 3: complex Web application deployment

User interface components (UIC) and user interface process components (UIP) are made public to the Internet and may potentially interact with many clients. Because these presentation layer components are usually exposed outside the company's firewall, their security requirements are generally much more restrictive than those of undisclosed components. In addition, many organizations require that servers exposed to the Internet do not contain any sensitive data. Therefore, by placing the presentation layer component into a single level and configuring this level to ensure the highest security, the overall security of the solution can be significantly improved, at the same time, you can minimize the impact on components with relatively low security requirements.

Because the presentation layer components are exposed to the Internet, their performance and scalability requirements are generally different from those of the domain and data access layer components. The presentation layer components are usually optimized to handle many concurrent users who interact with the component in an abrupt manner. The domain and data access layer components are generally optimized to process stable request streams from a relatively small number of sources. It may be very difficult to configure a level that fully supports the two sets of optimization. Therefore, the solution uses two levels, and each layer is optimized for the component type that resides.

Extended Enterprise Applications

Extended enterprise applications use the services provided by other applications, and may expose the functions as services for use by other applications. Figure 4 shows the deployment configuration.

Figure 4: Extended Enterprise Application Deployment

The reason why the Service Gateway (SG) and service interface (SI) are put into the Web level is the same as the reason why the component is put into the Web level. The latter is discussed in the previous section in this mode.

Smart Client Applications

The Smart Client configuration deploys user interface components at the client level rather than the Web level. The main motivation for moving a Representation component to the client level is that a rich user interface requires a high degree of interaction with the user. Mainstream Web technologies do not support these rich user interface requirements. Figure 5 shows other Smart Client configurations.

Figure 5: Smart Client application deployment

Note: :Large enterprise applications usually seem to be grouped by one or more models discussed in this model. For example, although most business components in an extended enterprise application run on the application server, several components may run in the Web farm due to performance reasons, and one or two may run in a browser.

Result Context

Communication between application development and system infrastructure teams is crucial for successful application deployment. Final deployment planning has the following advantages:

• Assign components to the level to meet the requirements of the two teams.
• Facilitate communication between the two teams and draw up contracts agreed to by the two teams in detail. If one of the teams cannot fulfill their commitments, the two teams must gather together and re-establish a new contract.

Note: :Communication between the application development team and the system infrastructure team will not produce the optimal deployment plan unless the company culture regards the application and system infrastructure as equally important. The two teams must be flexible and willing to reach a compromise so that both parties can fulfill their requirements.