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: 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. 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. 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 components and refactoring them to a single platform. Business or technical diversity 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. Application momentum 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.

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.

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: Dynamic resource expansion or "bursting" 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. Disaster recovery-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. 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. 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. 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. 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. 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.

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: 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 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 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.

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. 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 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. 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. Consider the security of data between the client, the endpoint, and any traffic that traverses the multiple clouds.

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: 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. 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. Security levels 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. 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.