Bucket for Use Cases (with Focus on Primary 2-Tier Example)

Focus and former title: Considerations for 2-tier Web Application Deployment Use Cases

In order to deploy any application into a cloud, one must be aware of a number of application and cloud details which are often often assumed by conventions and learned by experience. TOSCA should endeavor to explicitly describe these details.
Below is a non-exhaustive list. The objective is to cover the most common issues. The order of the list does not imply relevance.

Considerations for 2-tier Web Application Deployment Use Cases
1) Firewall. Setting the firewall to provide access to the application end points. How are the values computed? Can a firewall appliance to the deployment topology?
2) Load balancing. What is the load balancing semantic required by the application (e.g. stateless session tracking, sticky, ...)? How is it determined the cloud supports what is need?
3) Auto scaling. What is the criteria for scaling. Is it possible to scale the DB tier? Is it clustered?
4) Availability. What are the availability semantics? Is clustering used?
5) Endpoint control. For HTTP apps. Setting the HTTP listen port to something other than 80. Disabling 80 and using 443. Only using SSL. Configuring SSL keys. Are there any other ports which need to be configured such as locking down off admin ports which may be externally accessible.
6) Context paths. Can the context path of the HTTP endpoint be configured? What is the default?
7) DNS. Can deployed nodes be attached to an existing domain? What does the cloud support? How to achieve myapp.orgx.mycompany.com. How is it known the web server tier is public/DMZ facing? I.e. are there any implicit topology semantics?
8) Patching. How is it known if the patch should/can be applied? For OS level patches. (framework, middleware, and app patches too)
9) Software Repositories. What are the ways to specify the location of binaries and patches and any other externally packaged components? Can users refer to their own repositories? Does the cloud provider have one? Is there a default distro repo? Is it always available/reachable? User IT organizations only allow installation of preapproved content. What are the firewall traversal implications for the nods running the code installing the components?
10) Inter-tier connectivity. How does the webserver know how to connect to the database? How are the userID/passwd/port/IP/DBName values acquired/computed. These are not all static, common or public information. What means are used to disseminate this.
11) DB admin access. Tunnel? SSH? Firewall implications. Hot to set password?
12) Webserver admin access. SSH access? Key sharing.
13) Middleware drivers/versions. Is there a specific framework and version required to for the app to connect to the DB.
14) Tier consolidation. Placing the DB on same VM/Tier as the webserver.
15) Connectivity to services outside the immediate cloud. Connecting to an already existing DB in the local cloud, a public cloud or private cloud.
16) Database contents. How is the content of the database provided? What is the format of such an artifact for each DB? How is custom content associated with a deployment?
17) Resource requirements. How to specify the resource requirements of one tier are dependent on size of another tier? Or a function of expected load? Localized specification of resources is not very useful other than stating mins or maxes. How about component specific resources like queue length, pool sizes, etc.?
18) Monitoring. Can monitoring be included or specified in the deployment? Agents deployed? Measurement points created? For packaged open source monitoring and monitoring as a service?
19) Tenancy and isolation. How are tenancy semantics specified (dedicated versus shared placement) or isolation(data on isolated hosts, VLANs, storage)?
20) Results of deployment. Is there an error model? What information is available regarding the execution results of a plan? What is the final representation of the complete deployment?