05 - Deployment Considerations

Below are the main design time Deployment Considerations.

1.       Decide Deployment Architecture.

2.       Prefer Layered Design.

3.       Evaluate Server Affinity.

4.       Prefer – Local Business Logic Layer (Non-Distributed)

Decide Deployment Architecture:

Two depolyement architecture are possible.

·         Non-Distributed Architecute

·         Dstributed Architecture

Both approaches have different pros and cons in terms of ease of development, Performance & Scalability.

Nondistributed Architecture

With the nondistributed architecture, Presentation, Business, and Data Access Code are logically separated.

But are physically located in a Single Web Server Process on the Web server. 

Nondistributed application architecture: Logical layers on a Single Physical Tier.

Pros

·         Less complex than distributed architecture.

·         Has Performance Advantages gained through local calls.

Cons

·         Difficult to share business logic with other applications.

·         The use of a single tier Reduces Overall Scalability & Maintainability because all of the layers share the same physical hardware/resources. Since all of your layers are sharing resources, one layer can negatively impact all the other layers when it is under heavy utilization.

This can be good or bad — layers may work well together and result in optimized usage.

However, if one layer requires disproportionately more resources, you starve resources from another layer.

Distributed Architecture

With the distributed architecture, Presentation Layer communicates remotely to Business Layer located on a middle-tier application server as shown below.

Distributed architecture: Logical layers on Multiple Physical Tiers

Pros

·         Has separate server resources that are available for separate layers.

·         Provides a more flexible environment to easily Scale Out Or Scale Up each physical tier as performance limitations arise. E.g. Load Balance business logic independently

·         Allows to apply More Stringent Security to the application servers; for example, by adding a firewall between the Web server and the applications servers and by using different authentication and authorization options.

Cons

·         Has additional Serialization & Network Latency overheads due to remote calls.

·         Potentially more complex and more expensive in terms of total cost of ownership.

Prefer Layered Design

Layering provides two important design factors.

-      High Cohesion & Low Coupling

-      Scalability (Scale-Up & Out)

------------------------------------------------------------------------------------------------------------

What is High/Weak Cohesion:

To achieve High-Cohesion, logically related entities, such as classes and its methods, should be grouped together. Similarly, a component should contain logically related classes.

This results in lesss round trips because the classes or components are logically grouped and may end up residing in same tiers. Thus to complete a operation, no local or remote calls are required.

Weak cohesion among components tends to result in more round trips because the classes or components are not logically grouped and may end up residing in different tiers.

This can force us to require a mix of local and remote calls to complete a logical operation.

------------------------------------------------------------------------------------------------------------

Using Layering, to partition your application ensures that your presentation, business, and data access logic are not interspersed.

This logical seperation leads to a High Cohesive Design in which related classes and data are located close to each other, generally within a single boundary. This helps reduce/optimize the use of expensive local/remote calls.

Layering, also ensures that your presentation, business, and data access logic are loosely coupled.

This logical seperation leads to a Loosely Coupled Design.

If you have tight coupling and need to make changes, the changes are likely to ripple across the tightly coupled components. With loosely coupled components, changes are limited because the complexities of individual components are encapsulated from other components/layers. In addition, loose coupling provides greater flexibility to choose optimized strategies for performance and scalability for different components of your system independently.

A Highly Cohesive and Loosely Coupled, Layered design with clean, remotable interfaces is more easily Scaled Out than tightly-coupled layers with "chatty" interactions.

A Layered design will have natural clutch points, making it ideal for scaling out at the layer boundaries. The trick is to find the right layer boundaries. For example, business logic may be more easily relocated to a loadbalanced, middle-tier Application Server Farm.

Evaluate Server Affinity

Server affinity -  Occurs when all requests from a particular client must be handled by the same server.

Root Cause - It is most often introduced by below.

·         Locally Updatable Caches

·         In-Proc Session Mode - All requests from a specific client must be routed to the same server.

·         Thread Affinity prone application-logic: This forces the thread to be run on a specific set of processors. This hinders the ability of the scheduler to schedule threads across the processors, causing a decrease in performance gains produced by parallel processing.

Affinity can have a positive or negative impact on Performance And Scalability.

More server affinity to a resource can bring Performance Benefits. On the other hand, it brings Scaling Out Problems.

Note:

A Web farm can be configured to route all requests from the same user to the same server – a process known as Affinity – in order to maintain state where this is stored in memory on the Web server. However, for maximum performance and reliability, you should use a separate session state store with a Web farm to remove the requirement for affinity.

If you do not need to support scaling out, consider the performance benefits that affinity to a resource may bring.

If your design causes server affinity, scaling out at a later point, forces you to re-engineer or develop complex synchronization solutions, to synchronize data across multiple servers.

Prefer – Local Business Logic Layer (Non-Distributed)

Prefer to not physically separate your Business Logic Layer unless you need to and you have evaluated the tradeoffs. This can achieve optimum performance.

Remote logic / Remote calls across physical boundaries (process and machine), can increase Performance Overhead – Due to increased number of round trips over the network with associated network latency and serialization costs.

If you are able to manage server affinity in your application design, this approach supports Scaling Up & Out. 

See below, demonstrating Scale-Out (Web Farm) scenario in Non-Distributed design.

In Non-distributed Achitecture - Scaling out Web servers in a Web farm

However, you might need to physically separate your business layer from you front-end Web servers, as in the following scenarios:

·         Sharing business logic among multiple client applications.

·         Security policy of your organization might prohibit.

·         Business logic is computationally intensive.

·         When you have an existing set of business logic, and wanted to add a Web front end to it.

Reference: MS Patterns & Practices - Improving .NET Application Performance and Scalability

Hope this helps.

Regards,

Arun Manglick