diff --git a/doc/arch-design/hybrid/section_user_requirements_hybrid.xml b/doc/arch-design/hybrid/section_user_requirements_hybrid.xml index e537b3b07b..97b5085921 100644 --- a/doc/arch-design/hybrid/section_user_requirements_hybrid.xml +++ b/doc/arch-design/hybrid/section_user_requirements_hybrid.xml @@ -7,12 +7,12 @@ User requirements 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: + that use heterogeneous cloud platforms. Ensure that design choices + match requirements so that the benefits outweigh the inherent additional + complexity and risks. + Business considerations when designing a hybrid + cloud deployment Cost @@ -30,22 +30,20 @@ Revenue opportunity - 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. + Revenue opportunities vary 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. Time-to-market - 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 + One common reason 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. @@ -69,83 +67,44 @@ -
- Legal requirements - Many jurisdictions have legislative and regulatory - requirements governing the storage and management of data in - cloud environments. Common areas of regulation include: - - - Data retention policies ensuring storage of - persistent data and records management to meet data - archival requirements. - - - Data ownership policies governing the possession and - responsibility for data. - - - Data sovereignty policies governing the storage of - data in foreign countries or otherwise separate - jurisdictions. - - - 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. - - - Examples of such legal frameworks include the data - protection framework of the European Union (Reform of data protection legislation) - and the requirements of the Financial Industry Regulatory - Authority (FINRA Rules) - in the United States. Consult a local regulatory body for more - information. -
-
Workload considerations - 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: + 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. + Use cases for a hybrid cloud architecture - Dynamic resource expansion or "bursting" + Dynamic resource expansion or bursting - An application that requires additional resources is another - common reason you might use a multiple cloud architecture. + An application that requires additional resources may suit + 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 + during the holiday season, but does not want to add private + cloud resources to meet the peak demand. The user can + accommodate the increased load by bursting to + a public cloud for these peak load periods. These bursts could be for long or short cycles ranging from hourly to yearly. - Disaster recovery-business continuity + Disaster recovery and business continuity - 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. + Cheaper storage makes the public + cloud suitable for maintaining backup applications. - Federated hypervisor-instance management + Federated hypervisor and instance management - Adding self-service, charge back and transparent delivery of - the right resources from a federated pool can be cost + Adding self-service, charge back, and transparent delivery of + the 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 @@ -155,85 +114,59 @@ Application portfolio integration - 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. + An enterprise cloud delivers efficient application portfolio + management and deployments by leveraging + self-service features and rules according to use. Integrating + existing cloud environments is a common driver when building + hybrid cloud architectures. Migration scenarios - 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. + Hybrid cloud architecture enables the migration of + applications between different clouds. High availability - 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. + A combination of locations and platforms enables a + level of availability that is not + possible with a single platform. This approach increases + design complexity. - 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 + As running a workload on multiple cloud platforms increases design + complexity, we recommend first exploring options such as 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 perform the following functions: + Hybrid cloud designs must incorporate tools to facilitate working + across multiple clouds. + Tool functions Broker between clouds - 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 + Brokering software evaluates relative costs between different + cloud platforms. Cloud Management Platforms (CMP) + allow the designer to determine the right location for the workload based on predetermined criteria. Facilitate orchestration across the clouds - CMPs are tools are used to tie everything together. Using - cloud orchestration tools improves the management - of IT application portfolios as they migrate onto + CMPs simplify the migration of application workloads between 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. + portfolio of systems and applications across multiple cloud + platforms. @@ -241,16 +174,15 @@
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. Important tasks for - the architecture include the verification and ongoing testing of - critical features for the cloud endpoint. + It is important to consider the functionality, security, scalability, + availability, and testability of network when choosing a CMP and cloud + provider. - Decide on a network functionality framework and - design a minimum functionality test. This ensures - testing and functionality persists during and after upgrades. + Decide on a network framework and + design minimum functionality tests. This ensures + testing and functionality persists during and after + upgrades. Scalability across multiple cloud providers may @@ -263,15 +195,15 @@ 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. + 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. - Consider the security of data between - the client, the endpoint, and any traffic that traverses the - multiple clouds. + Consider the security of data between the client and the + endpoint, and of traffic that traverses the multiple + clouds.
@@ -279,68 +211,46 @@
Risk mitigation and management considerations 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 - 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: + risk by spreading workloads over multiple providers. + Hybrid cloud risks Provider availability or implementation details - 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. + Business changes can affect provider availability. Likewise, + changes in a provider's service can disrupt a hybrid cloud + environment or increase costs. 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 the various clouds - involved in the design offer, and must - address the actual enforceability of the providers' - SLAs. + Hybrid cloud designs must accommodate differences in SLAs + between providers, and consider their enforceability. Security levels Securing multiple cloud - environments is more complex than securing a single - cloud environment. We recommend addressing concerns at + environments is more complex than securing single + cloud environments. 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. + Be aware that each cloud platform approaches security + differently, and a hybrid cloud design must address and + compensate for these differences. Provider API changes - 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. + Consumers of external clouds rarely have control over + provider changes to APIs, and changes can break compatibility. + Using only the most common and basic APIs can minimize + potential conflicts.