Mood's In Control
The choice of deployment environment is typically out of the hands of an individual developer. The environment an application is ultimately deployed in determined by factors such as corporate standards and large grained project requirements.
Application architecture designs exist as models, documents, and scenarios. However, applications must be deployed into a physical environment where infrastructure limitations may negate some of the architectural decisions. Therefore, you must consider the proposed deployment scenario and the infrastructure as part of your application design process.
When choosing or defining deployment environment, the following should be examined:
Choosing a Deployment Strategy
Choosing a deployment strategy requires design tradeoffs; for example, because of protocol or port restrictions, or specific deployment topologies in your target environment. Identify your deployment constraints early in the design phase to avoid surprises later. To help you avoid surprises, involve members of your network and infrastructure teams to help with this process.
When choosing a deployment strategy:
• Understand the target physical environment for deployment.
• Understand the architectural and design constraints based on the deployment environment.
• Understand the security and performance impacts of your deployment environment.
Consider Design Implications and Tradeoffs up Front
You need to consider aspects of scalability that may vary by application layer, tier, or type of data. Know your tradeoffs up front and know where you have flexibility and where you do not. Scaling up and then out with Web or application servers might not be the best approach. For example, although you can have an 8-processor server in this role, economics would probably drive you to a set of smaller servers instead of a few big ones. On the other hand, scaling up and then out might be the right approach for your database servers, depending on the role of the data and how the data is used. Apart from technical and performance considerations, you also need to take into account operational and management implications and related total cost of ownership (TCO) costs.
Stateless Components
If you have stateless components (for example, a Web front end with no in-process state and no stateful business components), this aspect of your design supports both scaling up and scaling out. Typically, you optimize the price and performance within the boundaries of the other constraints you may have. For example, 2-processor Web or application servers may be optimal when you evaluate price and performance compared with 4-processor servers; that is, four 2-processor servers may be better than two 4-processor servers. You also need to consider other constraints, such as the maximum number of servers you can have behind a particular load-balancing infrastructure. In general, there are no design tradeoffs if you adhere to a stateless design. You optimize price, performance, and manageability.
Network Infrastructure Security Considerations
Make sure that you understand the network structure provided by your target environment, and understand the baseline security requirements of the network in terms of filtering rules, port restrictions, supported protocols, and so on.
Manageability Considerations
The choices you make when deploying an application affect the capabilities for managing and monitoring the application. You should take into account the following recommendations:
• Deploy components of the application that are used by multiple consumers in a single central location to avoid duplication.
• Ensure that data is stored in a location where backup and restore facilities can access it.
• Components that rely on existing software or hardware (such as a proprietary network that can only be established from a particular computer) must be physically located on the same computer.
• Some libraries and adaptors cannot be deployed freely without incurring extra cost, or may be charged on a per-CPU basis; therefore, you should centralize these features.
Since I was tasked by the IC-dean to evaluate the enrollment system of the university, as an amateur analyst, I still need guidance on examining the right and productive way in choosing or defining the deployment environment of a specific system. But with the aid of the information I have read and gathered from the internet which I have mentioned above, it made possible for me to identify and describe the characteristics that an analyst should examine in defining the deployment environment and learned that setting up your deployment environment involves many decisions that affect everything from the number of physical servers to the type of pattern you choose. Each decision will affect how you set up your deployment environment.
Reference:
http://apparchguide.codeplex.com/wikipage?title=Chapter%205%20-%20Deployment%20Patterns&referringTitle=Home
Application architecture designs exist as models, documents, and scenarios. However, applications must be deployed into a physical environment where infrastructure limitations may negate some of the architectural decisions. Therefore, you must consider the proposed deployment scenario and the infrastructure as part of your application design process.
When choosing or defining deployment environment, the following should be examined:
Choosing a Deployment StrategyChoosing a deployment strategy requires design tradeoffs; for example, because of protocol or port restrictions, or specific deployment topologies in your target environment. Identify your deployment constraints early in the design phase to avoid surprises later. To help you avoid surprises, involve members of your network and infrastructure teams to help with this process.
When choosing a deployment strategy:
• Understand the target physical environment for deployment.
• Understand the architectural and design constraints based on the deployment environment.
• Understand the security and performance impacts of your deployment environment.
Consider Design Implications and Tradeoffs up FrontYou need to consider aspects of scalability that may vary by application layer, tier, or type of data. Know your tradeoffs up front and know where you have flexibility and where you do not. Scaling up and then out with Web or application servers might not be the best approach. For example, although you can have an 8-processor server in this role, economics would probably drive you to a set of smaller servers instead of a few big ones. On the other hand, scaling up and then out might be the right approach for your database servers, depending on the role of the data and how the data is used. Apart from technical and performance considerations, you also need to take into account operational and management implications and related total cost of ownership (TCO) costs.
Stateless ComponentsIf you have stateless components (for example, a Web front end with no in-process state and no stateful business components), this aspect of your design supports both scaling up and scaling out. Typically, you optimize the price and performance within the boundaries of the other constraints you may have. For example, 2-processor Web or application servers may be optimal when you evaluate price and performance compared with 4-processor servers; that is, four 2-processor servers may be better than two 4-processor servers. You also need to consider other constraints, such as the maximum number of servers you can have behind a particular load-balancing infrastructure. In general, there are no design tradeoffs if you adhere to a stateless design. You optimize price, performance, and manageability.
Network Infrastructure Security ConsiderationsMake sure that you understand the network structure provided by your target environment, and understand the baseline security requirements of the network in terms of filtering rules, port restrictions, supported protocols, and so on.
Manageability ConsiderationsThe choices you make when deploying an application affect the capabilities for managing and monitoring the application. You should take into account the following recommendations:
• Deploy components of the application that are used by multiple consumers in a single central location to avoid duplication.
• Ensure that data is stored in a location where backup and restore facilities can access it.
• Components that rely on existing software or hardware (such as a proprietary network that can only be established from a particular computer) must be physically located on the same computer.
• Some libraries and adaptors cannot be deployed freely without incurring extra cost, or may be charged on a per-CPU basis; therefore, you should centralize these features.
Since I was tasked by the IC-dean to evaluate the enrollment system of the university, as an amateur analyst, I still need guidance on examining the right and productive way in choosing or defining the deployment environment of a specific system. But with the aid of the information I have read and gathered from the internet which I have mentioned above, it made possible for me to identify and describe the characteristics that an analyst should examine in defining the deployment environment and learned that setting up your deployment environment involves many decisions that affect everything from the number of physical servers to the type of pattern you choose. Each decision will affect how you set up your deployment environment.
Reference:
http://apparchguide.codeplex.com/wikipage?title=Chapter%205%20-%20Deployment%20Patterns&referringTitle=Home
