315 lines
17 KiB
XML
315 lines
17 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<section xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
version="5.0"
|
|
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
|
|
cloud deployment include:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Cost: A hybrid cloud architecture involves multiple
|
|
vendors and technical architectures. These
|
|
architectures may be more expensive to deploy and
|
|
maintain. Operational costs can be higher because of
|
|
the need for more sophisticated orchestration and
|
|
brokerage tools than in other architectures. In
|
|
contrast, overall operational costs might be lower by
|
|
virtue of using a cloud brokerage tool to deploy the
|
|
workloads to the most cost effective platform.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Revenue opportunity: 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>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Time to Market: 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>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Business or technical diversity: Organizations
|
|
already leveraging cloud-based services may wish to
|
|
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>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Application momentum: 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>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<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
|
|
(http://ec.europa.eu/justice/data-protection/) and the
|
|
requirements of the Financial Industry Regulatory Authority
|
|
(http://www.finra.org/Industry/Regulation/FINRARules/) 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
|
|
run on multiple cloud environments. In a hybrid cloud
|
|
deployment, the same workload will often need 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
|
|
include:</para>
|
|
<itemizedlist>
|
|
<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
|
|
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>
|
|
</listitem>
|
|
<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>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Federated hypervisor-instance management: 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>
|
|
<listitem>
|
|
<para>Application portfolio integration: An enterprise
|
|
cloud delivers better application portfolio management
|
|
and more efficient deployment 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>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Migration scenarios: 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>
|
|
</listitem>
|
|
<listitem>
|
|
<para>High availability: Another important reason for
|
|
wanting a multiple cloud architecture is to address
|
|
the needs for high availability. By 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
|
|
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>
|
|
<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>
|
|
<listitem>
|
|
<para>Broker between clouds: Since the multiple cloud
|
|
architecture assumes that there will be 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).
|
|
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>
|
|
<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
|
|
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
|
|
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>
|
|
</listitem>
|
|
</itemizedlist></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>
|
|
<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>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Scalability across multiple cloud providers may
|
|
dictate which underlying network framework you will
|
|
choose in different cloud providers. It is important
|
|
to have the network API functions presented and to
|
|
verify that functionality persists across all cloud
|
|
endpoints chosen.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<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>
|
|
</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>
|
|
</listitem>
|
|
</itemizedlist></section>
|
|
<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
|
|
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>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Provider availability or implementation details:
|
|
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 same time.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Differing SLAs: 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
|
|
address the actual enforceability of the providers'
|
|
SLAs.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Security levels: 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 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>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Provider API changes: APIs are crucial in a hybrid
|
|
cloud environment. As a consumer of a provider's cloud
|
|
services, an organization will rarely have any 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
|
|
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>
|
|
</itemizedlist></section>
|
|
</section>
|