openstack-manuals/doc/arch-design/hybrid/section_user_requirements_hybrid.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 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>
        <term>Cost</term>
        <listitem>
            <para>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>
      </varlistentry>
      <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>
        </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
                components and refactoring them to a single platform.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
        <term>Business or technical diversity</term>
        <listitem>
            <para>Organizations leveraging cloud-based services can
                embrace business diversity and utilize a hybrid cloud
                design to spread their workloads across multiple cloud
                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>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
        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>
    <variablelist>
      <varlistentry>
      <term>Dynamic resource expansion or <literal>"bursting"</literal></term>
        <listitem>
            <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 to yearly.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
      <term>Disaster recovery-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>
        </listitem>
      </varlistentry>
      <varlistentry>
      <term>Federated hypervisor-instance management</term>
        <listitem>
            <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>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>
        </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>
        </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>
        </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
        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>
    <variablelist>
     <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
                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
                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>
        </listitem>
     </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. Important tasks for
        the architecture include the verification and ongoing testing of
        critical features for the cloud endpoint.</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>
        </listitem>
        <listitem>
            <para>Scalability across multiple cloud providers may
                dictate which underlying network framework you
                choose in different cloud providers. It is important
                to present the network API functions 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. 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>
        </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. Heightened risks when using a hybrid
        cloud architecture include:</para>
    <variablelist>
      <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>
        </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>
        </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
                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>
      </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>
        </listitem>
      </varlistentry>
    </variablelist>
  </section>
</section>