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

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

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. Some possible use cases for a hybrid cloud architecture include: 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. 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. 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 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. 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. 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. 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.

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

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. 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. 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. 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. Security considerations include how data is secured between client and endpoint and any traffic that traverses the multiple clouds, from eavesdropping to DoS activities.

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