openstack/openstack-manuals
Code Issues Proposed changes

Clean up user_requirements_hybrid.xml

Browse Source 
- Edited to improve writing generally
- Removed duplicated legal content which was added to a common section.
  See https://review.openstack.org/#/c/212299/

Change-Id: Ib7e7957dc1c9516902234b56b73ce604a9650467
Implements: blueprint arch-guide
This commit is contained in:
Brian Moss 2015-08-14 10:23:08 +10:00
parent 79d32c6607
commit a0c7a6b159
1 changed files with 89 additions and 179 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -7,12 +7,12 @@
<?dbhtml stop-chunking?> <?dbhtml stop-chunking?>
<title>User requirements</title> <title>User requirements</title>
<para>Hybrid cloud architectures are complex, especially those <para>Hybrid cloud architectures are complex, especially those
that use heterogeneous cloud platforms. It is important to that use heterogeneous cloud platforms. Ensure that design choices
make sure that design choices match requirements in such a way that match requirements so that the benefits outweigh the inherent additional
the benefits outweigh the inherent additional complexity and risks.</para> complexity and risks.</para>
<para>Business considerations when designing a hybrid
cloud deployment include:</para>
<variablelist> <variablelist>
<title>Business considerations when designing a hybrid
cloud deployment</title>
<varlistentry> <varlistentry>
<term>Cost</term> <term>Cost</term>
<listitem> <listitem>
@ -30,22 +30,20 @@
<varlistentry> <varlistentry>
<term>Revenue opportunity</term> <term>Revenue opportunity</term>
<listitem> <listitem>
<para>Revenue opportunities vary <para>Revenue opportunities vary based on the intent and use case
greatly based on the intent and use case of the cloud. of the cloud. As a commercial, customer-facing product, you
As a commercial, customer-facing product, you must consider must consider whether building over multiple platforms makes
whether building over multiple platforms makes the the design more attractive to customers.</para>
design more attractive to customers.</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 common reason to use cloud platforms is to improve the
use cloud platforms is to improve the time-to-market of time-to-market of a new product or application. For example,
a new product or application. For example, using multiple using multiple cloud platforms is viable because there is an
cloud platforms is viable because there is an existing existing investment in several applications. It is faster to
investment in several applications. It is faster to tie tie the investments together rather than migrate the
the investments together rather than migrate the
components and refactoring them to a single platform.</para> components and refactoring them to a single platform.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -69,83 +67,44 @@
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<section xml:id="legal-requirements-hybrid">
<title>Legal requirements</title>
<para>Many jurisdictions have legislative and regulatory
requirements governing the storage and management of data in
cloud environments. Common areas of regulation include:</para>
<itemizedlist>
<listitem>
<para>Data retention policies ensuring storage of
persistent data and records management to meet data
archival requirements.</para>
</listitem>
<listitem>
<para>Data ownership policies governing the possession and
responsibility for data.</para>
</listitem>
<listitem>
<para>Data sovereignty policies governing the storage of
data in foreign countries or otherwise separate
jurisdictions.</para>
</listitem>
<listitem>
<para>Data compliance policies governing certain types of
information needs to reside in certain locations due
to regular issues and, more importantly, cannot reside
in other locations for the same reason.</para>
</listitem>
</itemizedlist>
<para>Examples of such legal frameworks include the data
protection framework of the European Union (<link
xlink:href="http://ec.europa.eu/justice/data-protection/">Reform of data protection legislation</link>)
and the requirements of the Financial Industry Regulatory
Authority (<link
xlink:href="http://www.finra.org/Industry/Regulation/FINRARules/">FINRA Rules</link>)
in the United States. Consult a local regulatory body for more
information.</para>
</section>
<section xml:id="workload-considerations"> <section xml:id="workload-considerations">
<title>Workload considerations</title> <title>Workload considerations</title>
<para>A workload can be a single application or a suite of applications that <para>A workload can be a single application or a suite of applications
work together. It can also be a duplicate set of applications that need to that work together. It can also be a duplicate set of applications that
run on multiple cloud environments. In a hybrid cloud need to run on multiple cloud environments. In a hybrid cloud
deployment, the same workload often needs 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. Some possible use cases for a hybrid cloud architecture incompatibilities.</para>
include:</para>
<variablelist> <variablelist>
<title>Use cases for a hybrid cloud architecture</title>
<varlistentry> <varlistentry>
<term>Dynamic resource expansion or <literal>"bursting"</literal></term> <term>Dynamic resource expansion or bursting</term>
<listitem> <listitem>
<para>An application that requires additional resources is another <para>An application that requires additional resources may suit
common reason you might use a multiple cloud architecture. a multiple cloud architecture.
For example, a retailer needs additional resources For example, a retailer needs additional resources
during the holiday retail season, but does not want to build expensive during the holiday season, but does not want to add private
cloud resources to meet the peak demand. The user might cloud resources to meet the peak demand. The user can
have an OpenStack private cloud but want to burst to accommodate the increased load by bursting to
AWS or some other public cloud for these peak load a 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 to yearly.</para> cycles ranging from hourly to yearly.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Disaster recovery-business continuity</term> <term>Disaster recovery and business continuity</term>
<listitem> <listitem>
<para>The cheaper storage and instance management makes a good case for <para>Cheaper storage makes the public
using the cloud as a secondary site. Using OpenStack public cloud suitable for maintaining backup applications.</para>
or private cloud in combination with the public cloud for
these purposes is popular.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Federated hypervisor-instance management</term> <term>Federated hypervisor and instance management</term>
<listitem> <listitem>
<para>Adding self-service, charge back and transparent delivery of <para>Adding self-service, charge back, and transparent delivery of
the right resources from a federated pool can be cost the 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
@ -155,85 +114,59 @@
<varlistentry> <varlistentry>
<term>Application portfolio integration</term> <term>Application portfolio integration</term>
<listitem> <listitem>
<para>An enterprise cloud delivers efficient application portfolio management <para>An enterprise cloud delivers efficient application portfolio
and deployments by leveraging management and deployments by leveraging
self-service features and rules for deployments based self-service features and rules according to use. Integrating
on types of use. Stitching together multiple existing existing cloud environments is a common driver when building
cloud environments that are already in production or development hybrid cloud architectures.</para>
is a common driver when building hybrid cloud architectures.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Migration scenarios</term> <term>Migration scenarios</term>
<listitem> <listitem>
<para>A common reason to create a <para>Hybrid cloud architecture enables the migration of
hybrid cloud architecture is to allow the migration of applications between different clouds.</para>
applications between different clouds. Permanent migration of the
application to a new platform is one reason, or another might be
because the application requires support on multiple
platforms.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>High availability</term> <term>High availability</term>
<listitem> <listitem>
<para>Another important reason for <para>A combination of locations and platforms enables a
wanting a multiple cloud architecture is to address level of availability that is not
the needs for high availability. Using a possible with a single platform. This approach increases
combination of multiple locations and platforms, a design complexity.</para>
design can achieve a level of availability that is not
possible with a single platform. This approach does
add a significant amount of complexity.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
<para>In addition to thinking about how the workload works on <para>As running a workload on multiple cloud platforms increases design
a single cloud, the design must accommodate the added complexity, we recommend first exploring options such as transferring
complexity of needing the workload to run on multiple cloud
platforms. We recommend exploring the complexity of transferring
workloads across clouds at the application, instance, cloud platform, workloads across clouds at the application, instance, cloud platform,
hypervisor, and network levels.</para> hypervisor, and network levels.</para>
</section> </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>Hybrid cloud designs must incorporate tools to facilitate working
design must incorporate tools to facilitate working across across multiple clouds.</para>
those multiple clouds. Some of the user requirements drive the
need for tools that perform the following functions:</para>
<variablelist> <variablelist>
<title>Tool functions</title>
<varlistentry> <varlistentry>
<term>Broker between clouds</term> <term>Broker between clouds</term>
<listitem> <listitem>
<para>Since the multiple cloud <para>Brokering software evaluates relative costs between different
architecture assumes that there are at least two cloud platforms. Cloud Management Platforms (CMP)
different and possibly incompatible platforms that are allow the designer to determine the right location for the
likely to have different costs, brokering software
evaluates relative costs between different
cloud platforms. The name for these solutions is
Cloud Management Platforms (CMPs).
Examples include Rightscale, Gravitent, Scalr,
CloudForms, and ManageIQ. These tools allow 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>
<varlistentry> <varlistentry>
<term>Facilitate orchestration across the clouds</term> <term>Facilitate orchestration across the clouds</term>
<listitem> <listitem>
<para>CMPs are tools are used to tie everything together. Using <para>CMPs simplify the migration of application workloads between
cloud orchestration tools improves the management
of IT application portfolios as they migrate onto
public, private, and hybrid cloud platforms. We recommend public, private, and hybrid cloud platforms. We recommend
using cloud orchestration tools for managing a diverse using cloud orchestration tools for managing a diverse
portfolio of installed systems across multiple cloud portfolio of systems and applications across multiple cloud
platforms. The typical enterprise IT application platforms.</para>
portfolio is still comprised of a few thousand
applications scattered over legacy hardware,
virtualized infrastructure, and now dozens of
disjointed shadow public Infrastructure-as-a-Service
(IaaS) and Software-as-a-Service (SaaS) providers and
offerings.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
@ -241,16 +174,15 @@
<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>It is important to consider the functionality, security, scalability,
assess when choosing a CMP and cloud provider. Considerations availability, and testability of network when choosing a CMP and cloud
are functionality, security, scalability and HA. Important tasks for provider.</para>
the architecture include the verification and ongoing testing of
critical features for the cloud endpoint.</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>Decide on a network functionality framework and <para>Decide on a network framework and
design a minimum functionality test. This ensures design minimum functionality tests. This ensures
testing and functionality persists during and after upgrades.</para> testing and functionality persists during and after
upgrades.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Scalability across multiple cloud providers may <para>Scalability across multiple cloud providers may
@ -263,15 +195,15 @@
<listitem> <listitem>
<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. Development of high availability and test frameworks active-active. Development of high availability and test
is necessary to insure understanding of functionality frameworks is necessary to insure understanding of
and limitations.</para> functionality and limitations.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Consider the security of data between <para>Consider the security of data between the client and the
the client, the endpoint, and any traffic that traverses the endpoint, and of traffic that traverses the multiple
multiple clouds.</para> clouds.</para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
</section> </section>
@ -279,68 +211,46 @@
<section xml:id="risk-mitigation-management-hybrid"> <section xml:id="risk-mitigation-management-hybrid">
<title>Risk mitigation and management considerations</title> <title>Risk mitigation and management 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 are more complex than a single cloud design and may involve
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.</para>
means, if one was to go out of business, the organization
could remain operational. Heightened risks when using a hybrid
cloud architecture include:</para>
<variablelist> <variablelist>
<title>Hybrid cloud risks</title>
<varlistentry> <varlistentry>
<term>Provider availability or implementation details</term> <term>Provider availability or implementation details</term>
<listitem> <listitem>
<para> <para>
This can range from the company going out of business Business changes can affect provider availability. Likewise,
to the company changing how it delivers its services. changes in a provider's service can disrupt a hybrid cloud
The design of a cloud architecture is meant to be environment or increase costs.</para>
flexible and changeable; however, the cloud is
perceived to be both rock solid and ever flexible at
the same time.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Differing SLAs</term> <term>Differing SLAs</term>
<listitem> <listitem>
<para>Users of hybrid cloud environments <para>Hybrid cloud designs must accommodate differences in SLAs
potentially encounter some losses through differences between providers, and consider their enforceability.</para>
in service level agreements. A hybrid cloud design
needs to accommodate the different SLAs the various clouds
involved in the design offer, and must
address the actual enforceability of the providers'
SLAs.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Security levels</term> <term>Security levels</term>
<listitem> <listitem>
<para>Securing multiple cloud <para>Securing multiple cloud
environments is more complex than securing a single environments is more complex than securing single
cloud environment. We recommend addressing concerns at cloud environments. We recommend addressing concerns at
the application, network, and cloud platform levels. the application, network, and cloud platform levels.
One issue is that different Be aware that each cloud platform approaches security
cloud platforms approach security differently, and a differently, and a hybrid cloud design must address and
hybrid cloud design must address and compensate for compensate for these differences.</para>
differences in security approaches. For example, AWS
uses a relatively simple model that relies on user
privilege combined with firewalls.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Provider API changes</term> <term>Provider API changes</term>
<listitem> <listitem>
<para>APIs are crucial in a hybrid <para>Consumers of external clouds rarely have control over
cloud environment. As a consumer of a provider's cloud provider changes to APIs, and changes can break compatibility.
services, an organization rarely has control Using only the most common and basic APIs can minimize
over provider changes to APIs. Cloud services that potential conflicts.</para>
might have previously had compatible APIs may no
longer work. This is particularly a problem with AWS
and OpenStack AWS-compatible APIs. The planning of OpenStack
included the maintenance of compatibility with changes in AWS
APIs. However, over time, the APIs have
become more divergent in functionality. One way to
address this issue is to focus on using only the most
common and basic APIs to minimize potential
conflicts.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>