openstack/openstack-manuals
Code Issues Proposed changes

Removal of passive voice from chap 7, arch guide

Browse Source 
Removal of passive voice from section_user_requirements

Change-Id: Ie28bcfc7955d90c39ae14463328690840c022d2f
Closes-bug: #1429696
This commit is contained in:
Alexandra Settle 2015-04-13 15:49:29 +10:00 committed by asettle
parent 186bcaf23c
commit 4ec2cd2818
1 changed files with 131 additions and 132 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

263
doc/arch-design/hybrid/section_user_requirements_hybrid.xml
View File

@ -6,13 +6,11 @@
xml:id="user-requirements-hybrid"> xml:id="user-requirements-hybrid">
<?dbhtml stop-chunking?> <?dbhtml stop-chunking?>
<title>User requirements</title> <title>User requirements</title>
<para>Hybrid cloud architectures introduce additional <para>Hybrid cloud architectures are complex, especially those
complexities, particularly those that use heterogeneous cloud that use heterogeneous cloud platforms. It is important to
platforms. As a result, it is important to make sure that make sure that design choices match requirements in such a way that
design choices match requirements in such a way that the the benefits outweigh the inherent additional complexity and risks.</para>
benefits outweigh the inherent additional complexity and <para>Business considerations when designing a hybrid
risks.</para>
<para>Business considerations to make when designing a hybrid
cloud deployment include:</para> cloud deployment include:</para>
<variablelist> <variablelist>
<varlistentry> <varlistentry>
@ -34,50 +32,43 @@
<listitem> <listitem>
<para>Revenue opportunities vary <para>Revenue opportunities vary
greatly based on the intent and use case of the cloud. greatly based on the intent and use case of the cloud.
If it is being built as a commercial customer-facing As a commercial, customer-facing product, you must consider
product, consider the drivers for building it over whether building over multiple platforms makes the
multiple platforms and whether the use of multiple design more attractive to customers.</para>
platforms make the design more attractive to target
customers, thus enhancing the revenue
opportunity.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Time to market</term> <term>Time-to-market</term>
<listitem> <listitem>
<para>One of the most common reasons to <para>One of the most common reasons to
use cloud platforms is to speed the time to market of use cloud platforms is to improve the time-to-market of
a new product or application. A business requirement a new product or application. For example, using multiple
to use multiple cloud platforms may be because there cloud platforms is viable because there is an existing
is an existing investment in several applications and investment in several applications. It is faster to tie
it is faster to tie them together rather than the investments together rather than migrate the
migrating components and refactoring to a single components and refactoring them to a single platform.</para>
platform.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Business or technical diversity</term> <term>Business or technical diversity</term>
<listitem> <listitem>
<para>Organizations <para>Organizations leveraging cloud-based services can
already leveraging cloud-based services may wish to
embrace business diversity and utilize a hybrid cloud embrace business diversity and utilize a hybrid cloud
design to spread their workloads across multiple cloud design to spread their workloads across multiple cloud
providers so that no application is hosted in a single providers. This ensures that no single cloud provider is
cloud provider.</para> the sole host for an application.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Application momentum</term> <term>Application momentum</term>
<listitem> <listitem>
<para>A business with existing <para>Businesses with existing applications may find that it is
applications that are already in production on more cost effective to integrate applications on multiple
multiple cloud environments may find that it is more cloud platforms than migrating them to a single platform.</para>
cost effective to integrate the applications on
multiple cloud platforms rather than migrate them to a
single platform.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<section xml:id="legal-requirements-hybrid"> <section xml:id="legal-requirements-hybrid">
<title>Legal requirements</title> <title>Legal requirements</title>
<para>Many jurisdictions have legislative and regulatory <para>Many jurisdictions have legislative and regulatory
@ -107,127 +98,134 @@
</itemizedlist> </itemizedlist>
<para>Examples of such legal frameworks include the data <para>Examples of such legal frameworks include the data
protection framework of the European Union (<link protection framework of the European Union (<link
xlink:href="http://ec.europa.eu/justice/data-protection/">http://ec.europa.eu/justice/data-protection/</link>) xlink:href="http://ec.europa.eu/justice/data-protection/">Reform of data protection legislation</link>)
and the requirements of the Financial Industry Regulatory and the requirements of the Financial Industry Regulatory
Authority (<link Authority (<link
xlink:href="http://www.finra.org/Industry/Regulation/FINRARules/">http://www.finra.org/Industry/Regulation/FINRARules/</link>) xlink:href="http://www.finra.org/Industry/Regulation/FINRARules/">FINRA Rules</link>)
in the United States. Consult a local regulatory body for more in the United States. Consult a local regulatory body for more
information.</para> information.</para>
</section> </section>
<section xml:id="workload-considerations"> <section xml:id="workload-considerations">
<title>Workload considerations</title> <title>Workload considerations</title>
<para>Defining what the word "workload" means in the context of a <para>A workload can be a single application or a suite of applications that
hybrid cloud environment is important. Workload can be defined work together. It can also be a duplicate set of applications that need to
as the intended way the systems will be utilized, which is
often referred to as a "use case". A workload can be a single
application or a suite of applications that work in concert.
It can also be a duplicate set of applications that need to
run on multiple cloud environments. In a hybrid cloud run on multiple cloud environments. In a hybrid cloud
deployment, the same workload will often need to function deployment, the same workload often needs to function
equally well on radically different public and private cloud equally well on radically different public and private cloud
environments. The architecture needs to address these environments. The architecture needs to address these
potential conflicts, complexity, and platform potential conflicts, complexity, and platform
incompatibilities.</para> incompatibilities. Some possible use cases for a hybrid cloud architecture
<para>Some possible use cases for a hybrid cloud architecture
include:</para> include:</para>
<itemizedlist> <variablelist>
<varlistentry>
<term>Dynamic resource expansion or <literal>"bursting"</literal></term>
<listitem> <listitem>
<para>Dynamic resource expansion or "bursting": Another <para>An application that requires additional resources is another
common reason to use a multiple cloud architecture is common reason you might use a multiple cloud architecture.
a "bursty" application that needs additional resources For example, a retailer needs additional resources
at times. An example of this case could be a retailer during the holiday retail season, but does not want to build expensive
that needs additional resources during the holiday cloud resources to meet the peak demand. The user might
selling season, but does not want to build expensive
cloud resources to meet the peak demand. They might
have an OpenStack private cloud but want to burst to have an OpenStack private cloud but want to burst to
AWS or some other public cloud for these peak load AWS or some other public cloud for these peak load
periods. These bursts could be for long or short periods. These bursts could be for long or short
cycles ranging from hourly, monthly or yearly.</para> cycles ranging from hourly to yearly.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>Disaster recovery-business continuity</term>
<listitem> <listitem>
<para>Disaster recovery-business continuity: The cheaper <para>The cheaper storage and instance management makes a good case for
storage and instance management makes a good case for using the cloud as a secondary site. Using OpenStack public
using the cloud as a secondary site. The public cloud or private cloud in combination with the public cloud for
is already heavily used for these purposes in these purposes is popular.</para>
combination with an OpenStack public or private
cloud.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>Federated hypervisor-instance management</term>
<listitem> <listitem>
<para>Federated hypervisor-instance management: Adding <para>Adding self-service, charge back and transparent delivery of
self-service, charge back and transparent delivery of
the right resources from a federated pool can be cost the right resources from a federated pool can be cost
effective. In a hybrid cloud environment, this is a effective. In a hybrid cloud environment, this is a
particularly important consideration. Look for a cloud particularly important consideration. Look for a cloud
that provides cross-platform hypervisor support and that provides cross-platform hypervisor support and
robust instance management tools.</para> robust instance management tools.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>Application portfolio integration</term>
<listitem> <listitem>
<para>Application portfolio integration: An enterprise <para>An enterprise cloud delivers efficient application portfolio management
cloud delivers better application portfolio management and deployments by leveraging
and more efficient deployment by leveraging
self-service features and rules for deployments based self-service features and rules for deployments based
on types of use. A common driver for building hybrid on types of use. Stitching together multiple existing
cloud architecture is to stitch together multiple cloud environments that are already in production or development
existing cloud environments that are already in is a common driver when building hybrid cloud architectures.</para>
production or development.<!-- In the interest of time to
market, the requirements may be to maintain the
multiple clouds and just integrate the pieces
together, not rationalize to one cloud environment, but
instead to --></para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>Migration scenarios</term>
<listitem> <listitem>
<para>Migration scenarios: A common reason to create a <para>A common reason to create a
hybrid cloud architecture is to allow the migration of hybrid cloud architecture is to allow the migration of
applications between different clouds. This may be applications between different clouds. Permanent migration of the
because the application will be migrated permanently application to a new platform is one reason, or another might be
to a new platform, or it might be because the because the application requires support on multiple
application needs to be supported on multiple platforms.</para>
platforms going forward.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>High availability</term>
<listitem> <listitem>
<para>High availability: Another important reason for <para>Another important reason for
wanting a multiple cloud architecture is to address wanting a multiple cloud architecture is to address
the needs for high availability. By using a the needs for high availability. Using a
combination of multiple locations and platforms, a combination of multiple locations and platforms, a
design can achieve a level of availability that is not design can achieve a level of availability that is not
possible with a single platform. This approach does possible with a single platform. This approach does
add a significant amount of complexity.</para> add a significant amount of complexity.</para>
</listitem> </listitem>
</itemizedlist> </varlistentry>
<para>In addition to thinking about how the workload will work on </variablelist>
<para>In addition to thinking about how the workload works on
a single cloud, the design must accommodate the added a single cloud, the design must accommodate the added
complexity of needing the workload to run on multiple cloud complexity of needing the workload to run on multiple cloud
platforms. The complexity of transferring workloads across platforms. We recommend exploring the complexity of transferring
clouds needs to be explored at the application, instance, workloads across clouds at the application, instance, cloud platform,
cloud platform, hypervisor, and network levels.</para></section> hypervisor, and network levels.</para>
</section>
<section xml:id="tools-considerations-hybrid"> <section xml:id="tools-considerations-hybrid">
<title>Tools considerations</title> <title>Tools considerations</title>
<para>When working with designs spanning multiple clouds, the <para>When working with designs spanning multiple clouds, the
design must incorporate tools to facilitate working across design must incorporate tools to facilitate working across
those multiple clouds. Some of the user requirements drive the those multiple clouds. Some of the user requirements drive the
need for tools that will do the following functions:</para> need for tools that perform the following functions:</para>
<itemizedlist> <variablelist>
<varlistentry>
<term>Broker between clouds</term>
<listitem> <listitem>
<para>Broker between clouds: Since the multiple cloud <para>Since the multiple cloud
architecture assumes that there will be at least two architecture assumes that there are at least two
different and possibly incompatible platforms that are different and possibly incompatible platforms that are
likely to have different costs, brokering software is likely to have different costs, brokering software
designed to evaluate relative costs between different evaluates relative costs between different
cloud platforms. These solutions are sometimes cloud platforms. The name for these solutions is
referred to as Cloud Management Platforms (CMPs). Cloud Management Platforms (CMPs).
Examples include Rightscale, Gravitent, Scalr, Examples include Rightscale, Gravitent, Scalr,
CloudForms, and ManageIQ. These tools allow the CloudForms, and ManageIQ. These tools allow the
designer to determine the right location for the designer to determine the right location for the
workload based on predetermined criteria.</para> workload based on predetermined criteria.</para>
</listitem> </listitem>
</varlistentry>
<varlistentry>
<term>Facilitate orchestration across the clouds</term>
<listitem> <listitem>
<para>Facilitate orchestration across the clouds: CMPs are <para>CMPs are tools are used to tie everything together. Using
tools are used to tie everything together. Cloud cloud orchestration tools improves the management
orchestration tools are used to improve the management
of IT application portfolios as they migrate onto of IT application portfolios as they migrate onto
public, private, and hybrid cloud platforms. These public, private, and hybrid cloud platforms. We recommend
tools are an important consideration. Cloud using cloud orchestration tools for managing a diverse
orchestration tools are used for managing a diverse
portfolio of installed systems across multiple cloud portfolio of installed systems across multiple cloud
platforms. The typical enterprise IT application platforms. The typical enterprise IT application
portfolio is still comprised of a few thousand portfolio is still comprised of a few thousand
@ -237,26 +235,28 @@
(IaaS) and Software-as-a-Service (SaaS) providers and (IaaS) and Software-as-a-Service (SaaS) providers and
offerings.</para> offerings.</para>
</listitem> </listitem>
</itemizedlist></section> </varlistentry>
</variablelist>
</section>
<section xml:id="network-considerations-hybrid"> <section xml:id="network-considerations-hybrid">
<title>Network considerations</title> <title>Network considerations</title>
<para>The network services functionality is an important factor to <para>The network services functionality is an important factor to
assess when choosing a CMP and cloud provider. Considerations assess when choosing a CMP and cloud provider. Considerations
are functionality, security, scalability and HA. Verification are functionality, security, scalability and HA. Important tasks for
and ongoing testing of the critical features of the cloud the architecture include the verification and ongoing testing of
endpoint used by the architecture are important tasks.</para> critical features for the cloud endpoint.</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>Once the network functionality framework has been <para>Decide on a network functionality framework and
decided, a minimum functionality test should be design a minimum functionality test. This ensures
designed. This will ensure testing and functionality testing and functionality persists during and after upgrades.</para>
persists during and after upgrades.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Scalability across multiple cloud providers may <para>Scalability across multiple cloud providers may
dictate which underlying network framework you will dictate which underlying network framework you
choose in different cloud providers. It is important choose in different cloud providers. It is important
to have the network API functions presented and to to present the network API functions and to
verify that functionality persists across all cloud verify that functionality persists across all cloud
endpoints chosen.</para> endpoints chosen.</para>
</listitem> </listitem>
@ -264,28 +264,27 @@
<para>High availability implementations vary in <para>High availability implementations vary in
functionality and design. Examples of some common functionality and design. Examples of some common
methods are active-hot-standby, active-passive and methods are active-hot-standby, active-passive and
active-active. High availability and a test framework active-active. Development of high availability and test frameworks
needs to be developed to insure that the functionality is necessary to insure understanding of functionality
and limitations are well understood.</para> and limitations.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Security considerations include how data is secured <para>Consider the security of data between
between client and endpoint and any traffic that the client, the endpoint, and any traffic that traverses the
traverses the multiple clouds, from eavesdropping to multiple clouds.</para>
DoS activities.</para>
</listitem> </listitem>
</itemizedlist></section> </itemizedlist>
</section>
<section xml:id="risk-mitigation-management-hybrid"> <section xml:id="risk-mitigation-management-hybrid">
<title>Risk mitigation and management <title>Risk mitigation and management considerations</title>
considerations</title>
<para>Hybrid cloud architectures introduce additional risk because <para>Hybrid cloud architectures introduce additional risk because
they add additional complexity and potentially conflicting or they add additional complexity and potentially conflicting or
incompatible components or tools. However, they also reduce incompatible components or tools. However, they also reduce
risk by spreading workloads over multiple providers. This risk by spreading workloads over multiple providers. This
means, if one was to go out of business, the organization means, if one was to go out of business, the organization
could remain operational.</para> could remain operational. Heightened risks when using a hybrid
<para>Risks that will be heightened by using a hybrid cloud cloud architecture include:</para>
architecture include:</para>
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term>Provider availability or implementation details</term> <term>Provider availability or implementation details</term>
@ -293,9 +292,9 @@
<para> <para>
This can range from the company going out of business This can range from the company going out of business
to the company changing how it delivers its services. to the company changing how it delivers its services.
Cloud architectures are inherently designed to be The design of a cloud architecture is meant to be
flexible and changeable; paradoxically, the cloud is flexible and changeable; however, the cloud is
both perceived to be rock solid and ever flexible at perceived to be both rock solid and ever flexible at
the same time.</para> the same time.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -305,8 +304,8 @@
<para>Users of hybrid cloud environments <para>Users of hybrid cloud environments
potentially encounter some losses through differences potentially encounter some losses through differences
in service level agreements. A hybrid cloud design in service level agreements. A hybrid cloud design
needs to accommodate the different SLAs provided by needs to accommodate the different SLAs the various clouds
the various clouds involved in the design, and must involved in the design offer, and must
address the actual enforceability of the providers' address the actual enforceability of the providers'
SLAs.</para> SLAs.</para>
</listitem> </listitem>
@ -316,9 +315,9 @@
<listitem> <listitem>
<para>Securing multiple cloud <para>Securing multiple cloud
environments is more complex than securing a single environments is more complex than securing a single
cloud environment. Concerns need to be addressed at, cloud environment. We recommend addressing concerns at
but not limited to, the application, network, and the application, network, and cloud platform levels.
cloud platform levels. One issue is that different One issue is that different
cloud platforms approach security differently, and a cloud platforms approach security differently, and a
hybrid cloud design must address and compensate for hybrid cloud design must address and compensate for
differences in security approaches. For example, AWS differences in security approaches. For example, AWS
@ -331,13 +330,13 @@
<listitem> <listitem>
<para>APIs are crucial in a hybrid <para>APIs are crucial in a hybrid
cloud environment. As a consumer of a provider's cloud cloud environment. As a consumer of a provider's cloud
services, an organization will rarely have any control services, an organization rarely has control
over provider changes to APIs. Cloud services that over provider changes to APIs. Cloud services that
might have previously had compatible APIs may no might have previously had compatible APIs may no
longer work. This is particularly a problem with AWS longer work. This is particularly a problem with AWS
and OpenStack AWS-compatible APIs. OpenStack was and OpenStack AWS-compatible APIs. The planning of OpenStack
originally planned to maintain compatibility with included the maintenance of compatibility with changes in AWS
changes in AWS APIs. However, over time, the APIs have APIs. However, over time, the APIs have
become more divergent in functionality. One way to become more divergent in functionality. One way to
address this issue is to focus on using only the most address this issue is to focus on using only the most
common and basic APIs to minimize potential common and basic APIs to minimize potential