From 81ba954b4a0d229ea88eb4103801bcfcbe41b582 Mon Sep 17 00:00:00 2001 From: Andreas Jaeger Date: Thu, 24 Jul 2014 21:51:25 +0200 Subject: [PATCH] Arch Design: Markup on section_methodology Use variable lists for better display. Use formalpara for some sections. Change-Id: Ia5567c6234fefd13b0f6e6c5d00a46cd574fbb4e --- .../introduction/section_methodology.xml | 138 ++++++++++++------ 1 file changed, 96 insertions(+), 42 deletions(-) diff --git a/doc/arch-design/introduction/section_methodology.xml b/doc/arch-design/introduction/section_methodology.xml index 4ed75e6660..3de45cd9ce 100644 --- a/doc/arch-design/introduction/section_methodology.xml +++ b/doc/arch-design/introduction/section_methodology.xml @@ -1,4 +1,8 @@ + +%openstack; +]>
- Develop functional user scenarios: Develop functional user scenarios - that can be used to develop test cases that can be used to measure - overall project trajectory. If the organization is not ready to commit - to an application or applications that can be used to develop user - requirements, it needs to create requirements to build valid test - harnesses and develop usable metrics. Once the metrics are established, - as requirements change, it is easier to respond to the changes quickly - without having to worry overly much about setting the exact requirements - in advance. Think of this as creating ways to configure the system, - rather than redesigning it every time there is a requirements change. - Limit cloud feature set: Create requirements that address the pain - points, but do not recreate the entire OpenStack tool suite. The - requirement to build OpenStack, only better, is self-defeating. It is - important to limit scope creep by concentrating on developing a platform - that will address tool limitations for the requirements, but not - recreating the entire suite of tools. Work with technical product owners - to establish critical features that are needed for a successful cloud - deployment. + + Develop functional user scenarios + + Develop functional user scenarios that can be used to develop + test cases that can be used to measure overall project + trajectory. If the organization is not ready to commit to an + application or applications that can be used to develop user + requirements, it needs to create requirements to build valid + test harnesses and develop usable metrics. Once the metrics + are established, as requirements change, it is easier to + respond to the changes quickly without having to worry overly + much about setting the exact requirements in advance. Think of + this as creating ways to configure the system, rather than + redesigning it every time there is a requirements + change. + + + + Limit cloud feature set + + Create requirements that address the pain points, but do not + recreate the entire OpenStack tool suite. The requirement to + build OpenStack, only better, is self-defeating. It is + important to limit scope creep by concentrating on developing + a platform that will address tool limitations for the + requirements, but not recreating the entire suite of + tools. Work with technical product owners to establish + critical features that are needed for a successful cloud + deployment. + +
Application Cloud Readiness Although the cloud is designed to make things easier, it is @@ -129,30 +146,67 @@ Determining whether an application is cloud-ready There are several factors to take into consideration when looking at whether an application is a good fit for the cloud. - Structure: A large, monolithic, single-tiered legacy application - typically isn't a good fit for the cloud. Efficiencies are gained - when load can be spread over several instances, so that a failure in - one part of the system can be mitigated without affecting other - parts of the system, or so that scaling can take place where the app - needs it. - Dependencies: Applications that depend on specific hardware -- - such as a particular chip set or an external device such as a - fingerprint reader -- might not be a good fit for the cloud, unless - those dependencies are specifically addressed. Similarly, if an - application depends on an operating system or set of libraries that - cannot be used in the cloud, or cannot be virtualized, that is a - problem. - Connectivity: Self-contained applications or those that depend on - resources that are not reachable by the cloud in question, will not - run. In some situations, work around these issues with custom - network setup, but how well this works depends on the chosen cloud - environment. - Durability and Resilience: Despite the existence of SLAs, the one - reality of the cloud is that Things Break. Servers go down, network - connections are disrupted, other tenants on a server ramp up the - load to make the server unusable. Any number of things can happen, - and an application that isn't built to withstand this kind of - disruption isn't going to work properly. + + + Structure + + + A large, monolithic, single-tiered legacy + application typically isn't a good fit for the + cloud. Efficiencies are gained when load can be + spread over several instances, so that a failure + in one part of the system can be mitigated without + affecting other parts of the system, or so that + scaling can take place where the app needs + it. + + + + + Dependencies + + + Applications that depend on specific + hardware—such as a particular chip set or an + external device such as a fingerprint + reader—might not be a good fit for the + cloud, unless those dependencies are specifically + addressed. Similarly, if an application depends on + an operating system or set of libraries that + cannot be used in the cloud, or cannot be + virtualized, that is a problem. + + + + + Connectivity + + + Self-contained applications or those that depend + on resources that are not reachable by the cloud + in question, will not run. In some situations, + work around these issues with custom network + setup, but how well this works depends on the + chosen cloud environment. + + + + + Durability and resilience + + + Despite the existence of SLAs, the one reality of + the cloud is that Things Break. Servers go down, + network connections are disrupted, other tenants + on a server ramp up the load to make the server + unusable. Any number of things can happen, and an + application that isn't built to withstand this + kind of disruption isn't going to work + properly. + + + +
Designing for the cloud