diff --git a/doc/arch-design/hybrid/section_user_requirements_hybrid.xml b/doc/arch-design/hybrid/section_user_requirements_hybrid.xml index efe4ed22c3..e537b3b07b 100644 --- a/doc/arch-design/hybrid/section_user_requirements_hybrid.xml +++ b/doc/arch-design/hybrid/section_user_requirements_hybrid.xml @@ -6,13 +6,11 @@ xml:id="user-requirements-hybrid"> User requirements - 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. - Business considerations to make when designing a hybrid + 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. + Business considerations when designing a hybrid cloud deployment include: @@ -34,50 +32,43 @@ 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. + As a commercial, customer-facing product, you must consider + whether building over multiple platforms makes the + design more attractive to customers. - Time to market + 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. + 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. Business or technical diversity - Organizations - already leveraging cloud-based services may wish to + 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. + providers. This ensures that no single cloud provider is + the sole host for an application. 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. + 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. +
Legal requirements Many jurisdictions have legislative and regulatory @@ -107,127 +98,134 @@ Examples of such legal frameworks include the data protection framework of the European Union (http://ec.europa.eu/justice/data-protection/) + xlink:href="http://ec.europa.eu/justice/data-protection/">Reform of data protection legislation) and the requirements of the Financial Industry Regulatory Authority (http://www.finra.org/Industry/Regulation/FINRARules/) + xlink:href="http://www.finra.org/Industry/Regulation/FINRARules/">FINRA Rules) in the United States. Consult a local regulatory body for more information.
+
Workload considerations - 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 + 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. - Some possible use cases for a hybrid cloud architecture + incompatibilities. Some possible use cases for a hybrid cloud architecture include: - + + + Dynamic resource expansion or "bursting" - 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 + 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. + cycles ranging from hourly to yearly. + + + Disaster recovery-business continuity - 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. + 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. + + + Federated hypervisor-instance management - Federated hypervisor-instance management: Adding - self-service, charge back and transparent delivery of + 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. + + + Application portfolio integration - Application portfolio integration: An enterprise - cloud delivers better application portfolio management - and more efficient deployment by leveraging + 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. + 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. + + + Migration scenarios - Migration scenarios: A common reason to create a + 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. + 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. + + + High availability - High availability: Another important reason for + 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. - - In addition to thinking about how the workload will work on + + + 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.
+ platforms. We recommend exploring the complexity of transferring + workloads across clouds at the application, instance, cloud platform, + hypervisor, and network levels. + +
Tools considerations 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: - + need for tools that perform the following functions: + + + Broker between clouds - Broker between clouds: Since the multiple cloud - architecture assumes that there will be at least two + 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. + + + Facilitate orchestration across the clouds - Facilitate orchestration across the clouds: CMPs are - tools are used to tie everything together. Cloud - orchestration tools are used to improve the management + 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. -
+ + + +
Network considerations 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. + are functionality, security, scalability and HA. Important tasks for + the architecture include the verification and ongoing testing of + critical features for the cloud endpoint. - 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. + Decide on a network functionality framework and + design a minimum functionality test. This ensures + testing and functionality persists during and after upgrades. 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. @@ -264,28 +264,27 @@ 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. + active-active. Development of high availability and test frameworks + is necessary to insure understanding of functionality + and limitations. - Security considerations include how data is secured - between client and endpoint and any traffic that - traverses the multiple clouds, from eavesdropping to - DoS activities. + Consider the security of data between + the client, the endpoint, and any traffic that traverses the + multiple clouds. -
+ + +
- Risk mitigation and management - considerations + Risk mitigation and management considerations 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. - Risks that will be heightened by using a hybrid cloud - architecture include: + could remain operational. Heightened risks when using a hybrid + cloud architecture include: Provider availability or implementation details @@ -293,9 +292,9 @@ 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. @@ -305,8 +304,8 @@ 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. @@ -316,9 +315,9 @@ 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 @@ 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