diff --git a/doc/arch-design/introduction/section_methodology.xml b/doc/arch-design/introduction/section_methodology.xml index f49e0651e5..f58e2a4ca4 100644 --- a/doc/arch-design/introduction/section_methodology.xml +++ b/doc/arch-design/introduction/section_methodology.xml @@ -9,57 +9,59 @@ version="5.0" xml:id="methodology"> Methodology - - Creating and testing use cases is the best way to design a cloud - architecture that best suits your needs. - - For example, if your goal is to develop a cloud for your company's e-commerce - website, you need to plan for applications that will support thousands of - sessions per second, variable workloads, and lots of complex and changing data. - By identifying the key meters, such as number of concurrent transactions - per second, size of database, and so on, it is possible to then build a - method for testing the assumptions. - - Functional user scenarios are used to develop test cases to measure overall - project trajectory. If you do not want to use an application to develop user - requirements automatically, you will need to create requirements to build - test harnesses and develop usable meters. Once the meters are established you - can respond to changes quickly without having to set the exact requirements - in advance. This creates ways to configure the system, rather than redesigning - it every time there is a requirements change. - - It is important to limit scope creep. Ensure you address tool limitations - for the requirements, but do not recreate the entire suite of tools. Work - with technical product owners to establish critical features that are needed - for a successful cloud deployment. + The best way to design your cloud architecture is through creating and + testing use cases. Planning for applications that support thousands of + sessions per second, variable workloads, and complex, changing data, + requires you to identify the key meters. Identifying these key meters, + such as number of concurrent transactions per second, and size of + database, makes it possible to build a method for testing your assumptions. + Use a functional user scenario to develop test cases, and to measure + overall project trajectory. + + If you do not want to use an application to develop user + requirements automatically, you need to create requirements to build + test harnesses and develop usable meters. + + Establishing these meters allows you to respond to changes quickly without + having to set exact requirements in advance. + This creates ways to configure the system, rather than redesigning + it every time there is a requirements change. + + It is important to limit scope creep. Ensure you address tool limitations, + but do not recreate 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 - important to realize that "using cloud" is more than just firing up - an instance and dropping an application on it. This "lift and shift" + The cloud does more than host virtual machines and their applications. + This lift and shift approach works in certain situations, but there is a fundamental difference between clouds and traditional bare-metal-based environments, or even traditional virtualized environments. In traditional environments, with traditional enterprise applications, the applications and the servers that run on them are - "pets". They're lovingly crafted and cared for, the servers have - names like Gandalf or Tardis, and if they get sick, someone nurses + pets. + They are lovingly crafted and cared for, the servers have + names like Gandalf or Tardis, and if they get sick someone nurses them back to health. All of this is designed so that the application does not experience an outage. - In cloud environments, on the other hand, servers are more like + In cloud environments, servers are more like cattle. There are thousands of them, they get names like NY-1138-Q, and if they get sick, they get put down and a sysadmin installs another one. Traditional applications that are unprepared for this - kind of environment, naturally will suffer outages, lost data, or - worse. - There are other reasons to design applications with cloud in mind. - Some are defensive, such as the fact that applications cannot be + kind of environment may suffer outages, loss of data, or + complete failure. + There are other reasons to design applications with the cloud in mind. + Some are defensive, such as the fact that because applications cannot be certain of exactly where or on what hardware they will be launched, they need to be flexible, or at least adaptable. Others are proactive. For example, one of the advantages of using the cloud is - scalability, so applications need to be designed in such a way that - they can take advantage of those and other opportunities. + scalability. Applications need to be designed in such a way that + they can take advantage of these and other opportunities.
+
Determining whether an application is cloud-ready There are several factors to take into consideration when looking @@ -69,8 +71,8 @@ Structure - A large, monolithic, single-tiered legacy - application typically isn't a good fit for the + A large, monolithic, single-tiered, legacy + application typically is not 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 @@ -85,9 +87,9 @@ Applications that depend on specific - hardware—such as a particular chip set or an + hardware, such as a particular chip set or an external device such as a fingerprint - reader—might not be a good fit for the + 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 @@ -100,10 +102,10 @@ Connectivity - Self-contained applications or those that depend + 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 + you can work around these issues with custom network setup, but how well this works depends on the chosen cloud environment. @@ -123,6 +125,7 @@
+
Designing for the cloud Here are some guidelines to keep in mind when designing an @@ -130,7 +133,7 @@ Be a pessimist: Assume everything fails and design - backwards. Love your chaos monkey. + backwards. Put your eggs in multiple baskets: Leverage multiple @@ -151,12 +154,12 @@ But not too paranoid: Not every application needs the platinum solution. Architect for different SLA's, service - tiers and security levels. + tiers, and security levels. Manage the data: Data is usually the most inflexible and complex area of a cloud and cloud integration architecture. - Don't short change the effort in analyzing and addressing + Do not short change the effort in analyzing and addressing data needs. @@ -178,7 +181,7 @@ Be dynamic: Enable dynamic configuration changes such as auto scaling, failure recovery and resource discovery to - adapt to changing environments, faults and workload volumes. + adapt to changing environments, faults, and workload volumes. @@ -187,12 +190,12 @@ Keep it loose: Loose coupling, service interfaces, - separation of concerns, abstraction and well defined API's + separation of concerns, abstraction, and well defined API's deliver flexibility. Be cost aware: Autoscaling, data transmission, virtual - software licenses, reserved instances, and so on can rapidly + software licenses, reserved instances, and similar costs can rapidly increase monthly usage charges. Monitor usage closely.