Merge "Clean up user_requirements_hybrid.xml"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
f2068b7c8c
@ -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>
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user