Removal of passive voice from chap 7, arch guide
Removal of passive voice from section_user_requirements Change-Id: Ie28bcfc7955d90c39ae14463328690840c022d2f Closes-bug: #1429696
This commit is contained in:
Alexandra Settle
asettle
parent
186bcaf23c
commit
4ec2cd2818
@ -6,13 +6,11 @@
|
||||
xml:id="user-requirements-hybrid">
|
||||
<?dbhtml stop-chunking?>
|
||||
<title>User requirements</title>
|
||||
<para>Hybrid cloud architectures introduce additional
|
||||
complexities, particularly those that use heterogeneous cloud
|
||||
platforms. As a result, 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 to make when designing a hybrid
|
||||
<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>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
@ -34,50 +32,43 @@
|
||||
<listitem>
|
||||
<para>Revenue opportunities vary
|
||||
greatly based on the intent and use case of the cloud.
|
||||
If it is being built as a commercial customer-facing
|
||||
product, consider the drivers for building it over
|
||||
multiple platforms and whether the use of multiple
|
||||
platforms make the design more attractive to target
|
||||
customers, thus enhancing the revenue
|
||||
opportunity.</para>
|
||||
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>
|
||||
<term>Time-to-market</term>
|
||||
<listitem>
|
||||
<para>One of the most common reasons to
|
||||
use cloud platforms is to speed the time to market of
|
||||
a new product or application. A business requirement
|
||||
to use multiple cloud platforms may be because there
|
||||
is an existing investment in several applications and
|
||||
it is faster to tie them together rather than
|
||||
migrating components and refactoring to a single
|
||||
platform.</para>
|
||||
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>
|
||||
<varlistentry>
|
||||
<term>Business or technical diversity</term>
|
||||
<listitem>
|
||||
<para>Organizations
|
||||
already leveraging cloud-based services may wish to
|
||||
<para>Organizations leveraging cloud-based services can
|
||||
embrace business diversity and utilize a hybrid cloud
|
||||
design to spread their workloads across multiple cloud
|
||||
providers so that no application is hosted in a single
|
||||
cloud provider.</para>
|
||||
providers. This ensures that no single cloud provider is
|
||||
the sole host for an application.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Application momentum</term>
|
||||
<listitem>
|
||||
<para>A business with existing
|
||||
applications that are already in production on
|
||||
multiple cloud environments may find that it is more
|
||||
cost effective to integrate the applications on
|
||||
multiple cloud platforms rather than migrate them to a
|
||||
single platform.</para>
|
||||
<para>Businesses with existing applications may find that it is
|
||||
more cost effective to integrate applications on multiple
|
||||
cloud platforms than migrating them to a single platform.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<section xml:id="legal-requirements-hybrid">
|
||||
<title>Legal requirements</title>
|
||||
<para>Many jurisdictions have legislative and regulatory
|
||||
@ -107,127 +98,134 @@
|
||||
</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/">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
|
||||
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
|
||||
information.</para>
|
||||
</section>
|
||||
|
||||
<section xml:id="workload-considerations">
|
||||
<title>Workload considerations</title>
|
||||
<para>Defining what the word "workload" means in the context of a
|
||||
hybrid cloud environment is important. Workload can be defined
|
||||
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
|
||||
<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 will often need to function
|
||||
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>
|
||||
<para>Some possible use cases for a hybrid cloud architecture
|
||||
incompatibilities. Some possible use cases for a hybrid cloud architecture
|
||||
include:</para>
|
||||
<itemizedlist>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Dynamic resource expansion or <literal>"bursting"</literal></term>
|
||||
<listitem>
|
||||
<para>Dynamic resource expansion or "bursting": Another
|
||||
common reason to use a multiple cloud architecture is
|
||||
a "bursty" application that needs additional resources
|
||||
at times. An example of this case could be a retailer
|
||||
that needs additional resources during the holiday
|
||||
selling season, but does not want to build expensive
|
||||
cloud resources to meet the peak demand. They might
|
||||
<para>An application that requires additional resources is another
|
||||
common reason you might use 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
|
||||
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>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Disaster recovery-business continuity</term>
|
||||
<listitem>
|
||||
<para>Disaster recovery-business continuity: The cheaper
|
||||
storage and instance management makes a good case for
|
||||
using the cloud as a secondary site. The public cloud
|
||||
is already heavily used for these purposes in
|
||||
combination with an OpenStack public or private
|
||||
cloud.</para>
|
||||
<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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Federated hypervisor-instance management</term>
|
||||
<listitem>
|
||||
<para>Federated hypervisor-instance management: 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
|
||||
effective. In a hybrid cloud environment, this is a
|
||||
particularly important consideration. Look for a cloud
|
||||
that provides cross-platform hypervisor support and
|
||||
robust instance management tools.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Application portfolio integration</term>
|
||||
<listitem>
|
||||
<para>Application portfolio integration: An enterprise
|
||||
cloud delivers better application portfolio management
|
||||
and more efficient deployment by leveraging
|
||||
<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. A common driver for building hybrid
|
||||
cloud architecture is to stitch together multiple
|
||||
existing cloud environments that are already in
|
||||
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>
|
||||
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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Migration scenarios</term>
|
||||
<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
|
||||
applications between different clouds. This may be
|
||||
because the application will be migrated permanently
|
||||
to a new platform, or it might be because the
|
||||
application needs to be supported on multiple
|
||||
platforms going forward.</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>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>High availability</term>
|
||||
<listitem>
|
||||
<para>High availability: Another important reason for
|
||||
<para>Another important reason for
|
||||
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
|
||||
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>
|
||||
</itemizedlist>
|
||||
<para>In addition to thinking about how the workload will work on
|
||||
</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. The complexity of transferring workloads across
|
||||
clouds needs to be explored at the application, instance,
|
||||
cloud platform, hypervisor, and network levels.</para></section>
|
||||
platforms. We recommend exploring the complexity of 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 will do the following functions:</para>
|
||||
<itemizedlist>
|
||||
need for tools that perform the following functions:</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Broker between clouds</term>
|
||||
<listitem>
|
||||
<para>Broker between clouds: Since the multiple cloud
|
||||
architecture assumes that there will be at least two
|
||||
<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 is
|
||||
designed to evaluate relative costs between different
|
||||
cloud platforms. These solutions are sometimes
|
||||
referred to as Cloud Management Platforms (CMPs).
|
||||
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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Facilitate orchestration across the clouds</term>
|
||||
<listitem>
|
||||
<para>Facilitate orchestration across the clouds: CMPs are
|
||||
tools are used to tie everything together. Cloud
|
||||
orchestration tools are used to improve the management
|
||||
<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
|
||||
public, private, and hybrid cloud platforms. These
|
||||
tools are an important consideration. Cloud
|
||||
orchestration tools are used for managing a diverse
|
||||
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
|
||||
@ -237,26 +235,28 @@
|
||||
(IaaS) and Software-as-a-Service (SaaS) providers and
|
||||
offerings.</para>
|
||||
</listitem>
|
||||
</itemizedlist></section>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</section>
|
||||
|
||||
<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. Verification
|
||||
and ongoing testing of the critical features of the cloud
|
||||
endpoint used by the architecture are important tasks.</para>
|
||||
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>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Once the network functionality framework has been
|
||||
decided, a minimum functionality test should be
|
||||
designed. This will ensure testing and functionality
|
||||
persists during and after upgrades.</para>
|
||||
<para>Decide on a network functionality framework and
|
||||
design a minimum functionality test. This ensures
|
||||
testing and functionality persists during and after upgrades.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<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
|
||||
to have the network API functions presented and to
|
||||
to present the network API functions and to
|
||||
verify that functionality persists across all cloud
|
||||
endpoints chosen.</para>
|
||||
</listitem>
|
||||
@ -264,28 +264,27 @@
|
||||
<para>High availability implementations vary in
|
||||
functionality and design. Examples of some common
|
||||
methods are active-hot-standby, active-passive and
|
||||
active-active. High availability and a test framework
|
||||
needs to be developed to insure that the functionality
|
||||
and limitations are well understood.</para>
|
||||
active-active. Development of high availability and test frameworks
|
||||
is necessary to insure understanding of functionality
|
||||
and limitations.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Security considerations include how data is secured
|
||||
between client and endpoint and any traffic that
|
||||
traverses the multiple clouds, from eavesdropping to
|
||||
DoS activities.</para>
|
||||
<para>Consider the security of data between
|
||||
the client, the endpoint, and any traffic that traverses the
|
||||
multiple clouds.</para>
|
||||
</listitem>
|
||||
</itemizedlist></section>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<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
|
||||
they add additional complexity and potentially conflicting or
|
||||
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.</para>
|
||||
<para>Risks that will be heightened by using a hybrid cloud
|
||||
architecture include:</para>
|
||||
could remain operational. Heightened risks when using a hybrid
|
||||
cloud architecture include:</para>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>Provider availability or implementation details</term>
|
||||
@ -293,9 +292,9 @@
|
||||
<para>
|
||||
This can range from the company going out of business
|
||||
to the company changing how it delivers its services.
|
||||
Cloud architectures are inherently designed to be
|
||||
flexible and changeable; paradoxically, the cloud is
|
||||
both perceived to be rock solid and ever flexible at
|
||||
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>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -305,8 +304,8 @@
|
||||
<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 provided by
|
||||
the various clouds involved in the design, and must
|
||||
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>
|
||||
@ -316,9 +315,9 @@
|
||||
<listitem>
|
||||
<para>Securing multiple cloud
|
||||
environments is more complex than securing a single
|
||||
cloud environment. Concerns need to be addressed at,
|
||||
but not limited to, the application, network, and
|
||||
cloud platform levels. One issue is that different
|
||||
cloud environment. 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
|
||||
@ -331,13 +330,13 @@
|
||||
<listitem>
|
||||
<para>APIs are crucial in a hybrid
|
||||
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
|
||||
might have previously had compatible APIs may no
|
||||
longer work. This is particularly a problem with AWS
|
||||
and OpenStack AWS-compatible APIs. OpenStack was
|
||||
originally planned to maintain compatibility with
|
||||
changes in AWS APIs. However, over time, the APIs have
|
||||
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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user