openstack/openstack-manuals
Code Issues Proposed changes

Edits to the arch guide

Browse Source 
1. Removal of unnecessary content
2. Rephasing of current content for clarity

Change-Id: I02335fb4b0c80d7764b5e79e2317421ff86ec2bb
This commit is contained in:
asettle 2015-08-28 12:12:29 +10:00
parent 080330e951
commit 3d4f729b10
1 changed files with 50 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
doc/arch-design/introduction/section_methodology.xml
View File

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