Clean up user_requirements_hybrid.xml
- 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
parent
79d32c6607
commit
a0c7a6b159
@ -7,12 +7,12 @@
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>User requirements</title>
|
||||
<para>Hybrid cloud architectures are complex, especially those
|
||||
that use heterogeneous cloud platforms. It is important to
|
||||
make sure that design choices match requirements in such a way that
|
||||
the benefits outweigh the inherent additional complexity and risks.</para>
|
||||
<para>Business considerations when designing a hybrid
|
||||
cloud deployment include:</para>
|
||||
that use heterogeneous cloud platforms. Ensure that design choices
|
||||
match requirements so that the benefits outweigh the inherent additional
|
||||
complexity and risks.</para>
|
||||
<variablelist>
|
||||
<title>Business considerations when designing a hybrid
|
||||
cloud deployment</title>
|
||||
<varlistentry>
|
||||
<term>Cost</term>
|
||||
<listitem>
|
||||
@ -30,22 +30,20 @@
|
||||
<varlistentry>
|
||||
<term>Revenue opportunity</term>
|
||||
<listitem>
|
||||
<para>Revenue opportunities vary
|
||||
greatly based on the intent and use case of the cloud.
|
||||
As a commercial, customer-facing product, you must consider
|
||||
whether building over multiple platforms makes the
|
||||
design more attractive to customers.</para>
|
||||
<para>Revenue opportunities vary based on the intent and use case
|
||||
of the cloud. As a commercial, customer-facing product, you
|
||||
must consider whether building over multiple platforms makes
|
||||
the design more attractive to customers.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Time-to-market</term>
|
||||
<listitem>
|
||||
<para>One of the most common reasons to
|
||||
use cloud platforms is to improve the time-to-market of
|
||||
a new product or application. For example, using multiple
|
||||
cloud platforms is viable because there is an existing
|
||||
investment in several applications. It is faster to tie
|
||||
the investments together rather than migrate the
|
||||
<para>One common reason to use cloud platforms is to improve the
|
||||
time-to-market of a new product or application. For example,
|
||||
using multiple cloud platforms is viable because there is an
|
||||
existing investment in several applications. It is faster to
|
||||
tie the investments together rather than migrate the
|
||||
components and refactoring them to a single platform.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -69,83 +67,44 @@
|
||||
</varlistentry>
|
||||
</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">
|
||||
<title>Workload considerations</title>
|
||||
<para>A workload can be a single application or a suite of applications that
|
||||
work together. It can also be a duplicate set of applications that need to
|
||||
run on multiple cloud environments. In a hybrid cloud
|
||||
deployment, the same workload often needs to function
|
||||
equally well on radically different public and private cloud
|
||||
environments. The architecture needs to address these
|
||||
potential conflicts, complexity, and platform
|
||||
incompatibilities. Some possible use cases for a hybrid cloud architecture
|
||||
include:</para>
|
||||
<para>A workload can be a single application or a suite of applications
|
||||
that work together. It can also be a duplicate set of applications that
|
||||
need to run on multiple cloud environments. In a hybrid cloud
|
||||
deployment, the same workload often needs to function
|
||||
equally well on radically different public and private cloud
|
||||
environments. The architecture needs to address these
|
||||
potential conflicts, complexity, and platform
|
||||
incompatibilities.</para>
|
||||
<variablelist>
|
||||
<title>Use cases for a hybrid cloud architecture</title>
|
||||
<varlistentry>
|
||||
<term>Dynamic resource expansion or <literal>"bursting"</literal></term>
|
||||
<term>Dynamic resource expansion or bursting</term>
|
||||
<listitem>
|
||||
<para>An application that requires additional resources is another
|
||||
common reason you might use a multiple cloud architecture.
|
||||
<para>An application that requires additional resources may suit
|
||||
a multiple cloud architecture.
|
||||
For example, a retailer needs additional resources
|
||||
during the holiday retail season, but does not want to build expensive
|
||||
cloud resources to meet the peak demand. The user might
|
||||
have an OpenStack private cloud but want to burst to
|
||||
AWS or some other public cloud for these peak load
|
||||
during the holiday season, but does not want to add private
|
||||
cloud resources to meet the peak demand. The user can
|
||||
accommodate the increased load by bursting to
|
||||
a public cloud for these peak load
|
||||
periods. These bursts could be for long or short
|
||||
cycles ranging from hourly to yearly.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Disaster recovery-business continuity</term>
|
||||
<term>Disaster recovery and business continuity</term>
|
||||
<listitem>
|
||||
<para>The cheaper storage and instance management makes a good case for
|
||||
using the cloud as a secondary site. Using OpenStack public
|
||||
or private cloud in combination with the public cloud for
|
||||
these purposes is popular.</para>
|
||||
<para>Cheaper storage makes the public
|
||||
cloud suitable for maintaining backup applications.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Federated hypervisor-instance management</term>
|
||||
<term>Federated hypervisor and instance management</term>
|
||||
<listitem>
|
||||
<para>Adding self-service, charge back and transparent delivery of
|
||||
the right resources from a federated pool can be cost
|
||||
<para>Adding self-service, charge back, and transparent delivery of
|
||||
the resources from a federated pool can be cost
|
||||
effective. In a hybrid cloud environment, this is a
|
||||
particularly important consideration. Look for a cloud
|
||||
that provides cross-platform hypervisor support and
|
||||
@ -155,85 +114,59 @@
|
||||
<varlistentry>
|
||||
<term>Application portfolio integration</term>
|
||||
<listitem>
|
||||
<para>An enterprise cloud delivers efficient application portfolio management
|
||||
and deployments by leveraging
|
||||
self-service features and rules for deployments based
|
||||
on types of use. Stitching together multiple existing
|
||||
cloud environments that are already in production or development
|
||||
is a common driver when building hybrid cloud architectures.</para>
|
||||
<para>An enterprise cloud delivers efficient application portfolio
|
||||
management and deployments by leveraging
|
||||
self-service features and rules according to use. Integrating
|
||||
existing cloud environments is a common driver when building
|
||||
hybrid cloud architectures.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Migration scenarios</term>
|
||||
<listitem>
|
||||
<para>A common reason to create a
|
||||
hybrid cloud architecture is to allow the migration of
|
||||
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>
|
||||
<para>Hybrid cloud architecture enables the migration of
|
||||
applications between different clouds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>High availability</term>
|
||||
<listitem>
|
||||
<para>Another important reason for
|
||||
wanting a multiple cloud architecture is to address
|
||||
the needs for high availability. Using a
|
||||
combination of multiple locations and platforms, a
|
||||
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>
|
||||
<para>A combination of locations and platforms enables a
|
||||
level of availability that is not
|
||||
possible with a single platform. This approach increases
|
||||
design complexity.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
<para>In addition to thinking about how the workload works on
|
||||
a single cloud, the design must accommodate the added
|
||||
complexity of needing the workload to run on multiple cloud
|
||||
platforms. We recommend exploring the complexity of transferring
|
||||
<para>As running a workload on multiple cloud platforms increases design
|
||||
complexity, we recommend first exploring options such as transferring
|
||||
workloads across clouds at the application, instance, cloud platform,
|
||||
hypervisor, and network levels.</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="tools-considerations-hybrid">
|
||||
<title>Tools considerations</title>
|
||||
<para>When working with designs spanning multiple clouds, the
|
||||
design must incorporate tools to facilitate working across
|
||||
those multiple clouds. Some of the user requirements drive the
|
||||
need for tools that perform the following functions:</para>
|
||||
<para>Hybrid cloud designs must incorporate tools to facilitate working
|
||||
across multiple clouds.</para>
|
||||
<variablelist>
|
||||
<title>Tool functions</title>
|
||||
<varlistentry>
|
||||
<term>Broker between clouds</term>
|
||||
<listitem>
|
||||
<para>Since the multiple cloud
|
||||
architecture assumes that there are at least two
|
||||
different and possibly incompatible platforms that are
|
||||
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
|
||||
<para>Brokering software evaluates relative costs between different
|
||||
cloud platforms. Cloud Management Platforms (CMP)
|
||||
allow the designer to determine the right location for the
|
||||
workload based on predetermined criteria.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Facilitate orchestration across the clouds</term>
|
||||
<listitem>
|
||||
<para>CMPs are tools are used to tie everything together. Using
|
||||
cloud orchestration tools improves the management
|
||||
of IT application portfolios as they migrate onto
|
||||
<para>CMPs simplify the migration of application workloads between
|
||||
public, private, and hybrid cloud platforms. We recommend
|
||||
using cloud orchestration tools for managing a diverse
|
||||
portfolio of installed systems across multiple cloud
|
||||
platforms. The typical enterprise IT application
|
||||
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>
|
||||
portfolio of systems and applications across multiple cloud
|
||||
platforms.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
@ -241,16 +174,15 @@
|
||||
|
||||
<section xml:id="network-considerations-hybrid">
|
||||
<title>Network considerations</title>
|
||||
<para>The network services functionality is an important factor to
|
||||
assess when choosing a CMP and cloud provider. Considerations
|
||||
are functionality, security, scalability and HA. Important tasks for
|
||||
the architecture include the verification and ongoing testing of
|
||||
critical features for the cloud endpoint.</para>
|
||||
<para>It is important to consider the functionality, security, scalability,
|
||||
availability, and testability of network when choosing a CMP and cloud
|
||||
provider.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Decide on a network functionality framework and
|
||||
design a minimum functionality test. This ensures
|
||||
testing and functionality persists during and after upgrades.</para>
|
||||
<para>Decide on a network framework and
|
||||
design minimum functionality tests. This ensures
|
||||
testing and functionality persists during and after
|
||||
upgrades.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Scalability across multiple cloud providers may
|
||||
@ -263,15 +195,15 @@
|
||||
<listitem>
|
||||
<para>High availability implementations vary in
|
||||
functionality and design. Examples of some common
|
||||
methods are active-hot-standby, active-passive and
|
||||
active-active. Development of high availability and test frameworks
|
||||
is necessary to insure understanding of functionality
|
||||
and limitations.</para>
|
||||
methods are active-hot-standby, active-passive, and
|
||||
active-active. Development of high availability and test
|
||||
frameworks is necessary to insure understanding of
|
||||
functionality and limitations.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Consider the security of data between
|
||||
the client, the endpoint, and any traffic that traverses the
|
||||
multiple clouds.</para>
|
||||
<para>Consider the security of data between the client and the
|
||||
endpoint, and of traffic that traverses the multiple
|
||||
clouds.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
@ -279,68 +211,46 @@
|
||||
<section xml:id="risk-mitigation-management-hybrid">
|
||||
<title>Risk mitigation and management considerations</title>
|
||||
<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
|
||||
risk by spreading workloads over multiple providers. This
|
||||
means, if one was to go out of business, the organization
|
||||
could remain operational. Heightened risks when using a hybrid
|
||||
cloud architecture include:</para>
|
||||
risk by spreading workloads over multiple providers.</para>
|
||||
<variablelist>
|
||||
<title>Hybrid cloud risks</title>
|
||||
<varlistentry>
|
||||
<term>Provider availability or implementation details</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This can range from the company going out of business
|
||||
to the company changing how it delivers its services.
|
||||
The design of a cloud architecture is meant to be
|
||||
flexible and changeable; however, the cloud is
|
||||
perceived to be both rock solid and ever flexible at
|
||||
the same time.</para>
|
||||
Business changes can affect provider availability. Likewise,
|
||||
changes in a provider's service can disrupt a hybrid cloud
|
||||
environment or increase costs.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Differing SLAs</term>
|
||||
<listitem>
|
||||
<para>Users of hybrid cloud environments
|
||||
potentially encounter some losses through differences
|
||||
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>
|
||||
<para>Hybrid cloud designs must accommodate differences in SLAs
|
||||
between providers, and consider their enforceability.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Security levels</term>
|
||||
<listitem>
|
||||
<para>Securing multiple cloud
|
||||
environments is more complex than securing a single
|
||||
cloud environment. We recommend addressing concerns at
|
||||
environments is more complex than securing single
|
||||
cloud environments. We recommend addressing concerns at
|
||||
the application, network, and cloud platform levels.
|
||||
One issue is that different
|
||||
cloud platforms approach security differently, and a
|
||||
hybrid cloud design must address and compensate for
|
||||
differences in security approaches. For example, AWS
|
||||
uses a relatively simple model that relies on user
|
||||
privilege combined with firewalls.</para>
|
||||
Be aware that each cloud platform approaches security
|
||||
differently, and a hybrid cloud design must address and
|
||||
compensate for these differences.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Provider API changes</term>
|
||||
<listitem>
|
||||
<para>APIs are crucial in a hybrid
|
||||
cloud environment. As a consumer of a provider's cloud
|
||||
services, an organization rarely has control
|
||||
over provider changes to APIs. Cloud services that
|
||||
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>
|
||||
<para>Consumers of external clouds rarely have control over
|
||||
provider changes to APIs, and changes can break compatibility.
|
||||
Using only the most common and basic APIs can minimize
|
||||
potential conflicts.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user