The hybrid cloud onion

In an earlier post, I defined a hybrid cloud and discussed possible scenarios including multiple public cloud providers, private clouds and traditional information technology (IT) environments.

While that post hopefully provided a good explanation of hybrid cloud infrastructures, it was not the full story, especially if you plan to implement a hybrid cloud in your environment. Like an onion that has many different layers around its core to protect it and keep it nice, white and juicy, hybrid cloud infrastructure has many different layers that keep it functional. Let’s take a look at these layers.


Don’t underestimate the complexity that is introduced as a result of the different technologies and service providers in a hybrid setup. Establishing a common management infrastructure might be extremely hard and might not always make sense; however, there are components that you might want to integrate and harmonize. Usually these components provide monitoring, alerting and ticketing tools.

Whenever a new piece of infrastructure is added to your hybrid setup, you should consider the extent to which you need to integrate it into your existing management systems, and how to manage it once it is integrated.


Once the infrastructure is managed properly, you can think about how to provision new workloads. The next layer we should consider is orchestration. As with the management of your hybrid cloud infrastructure, your goal here should be to have a single point for provisioning that spans services over different cloud infrastructures.

The ongoing standardization of cloud application programming interfaces (APIs) addresses this need. Amazon Web Services APIs and OpenStack may be considered industry standards in this arena. More and more cloud providers and cloud products support at least one of the two, often both. Tools like IBM Cloud Orchestrator can not only provision single workloads on different hybrid infrastructures, but can also define workload patterns for faster and easier deployment.


Orchestration enables the use of a hybrid infrastructure in an automated way. And once you are able to orchestrate your environment, you need to control how that is done. The main question to answer is which workloads should run where. This is crucial because each hybrid infrastructure has its strengths and weaknesses. Private clouds might be the place for sensitive data, while public clouds might provide the best price point. It is important to establish policies about hybrid cloud usage scenarios.


Hybrid clouds are defined by their infrastructures, which are much like the layers of an onion. To successfully establish a hybrid cloud setup, management, orchestration and governance must not be forgotten!

Share your comments and questions with me on Twitter @eMarcusNet.

What is hybrid cloud?

The National Institute of Standards and Technology defines hybrid cloud as “a composition of two or more clouds (private, community or public) that remain unique entities but are bound together, offering the benefits of multiple deployment models.” Although this definition sounds very reasonable, it does not cover all aspects of hybrid clouds.

Let’s discuss possible deployment models first. There are five defined cloud deployment models, from a private cloud on-premises to a public cloud service with a cloud service provider.

Cloud Deployment Models

Often, hybrid cloud refers to a combination of a public cloud service and a private cloud on-premises; however, hybrid clouds could also consist of two public clouds provided by different providers or even a combination of a cloud and traditional IT. Actually, a setup where existing systems on a traditional IT infrastructure are combined with a public cloud service is currently the most frequent use case of a hybrid cloud.

Any hybrid cloud setup has some challenges that need to be considered during the planning and design phase:

  • The most obvious challenge is network connectivity, especially if remote cloud services like a public cloud or a hosted private cloud are involved. Not only must bandwidth, latency, reliability and associated cost considerations be taken into account, but also the logical network topology must be carefully designed (networks, routing, firewalls).
  • Another huge challenge is the manageability of different cloud services. When different cloud services are used, every service provider will have its own management and provisioning environment. Those environments can be considered completely independent from each other. By having instances in different cloud services, there is no complete picture available showing the number of totally deployed instances and their statuses. An orchestration layer can be a possible solution for this problem. This layer provides a single interface for all cloud-related tasks. The orchestration layer itself communicates with the different cloud services through application programming interfaces (APIs). The big advantage of an orchestration layer is the ability to track and control activities on a central point to maintain the big picture.

Today, plenty of cloud service providers maintain their own proprietary set of APIs. This makes the use of orchestration very complex as the orchestrator requires some kind of a driver component for each proprietary API set. However, the trend of standardized APIs is clearly seen in the industry. OpenStack seems to be the future cloud industry standard.

Hybrid clouds mainly work on an infrastructure and application level. On the infrastructure layer, a hybrid cloud means the combination of virtual machines from different cloud services. On the application or software as a service (SaaS) layer, a hybrid cloud describes an application setup with components in different SaaS offerings or existing applications within the data center of an enterprise. The challenge on an SaaS-based hybrid cloud is mainly the exchange of data between the different services and applications. Like orchestration works on the infrastructure level, data integrators work on the application layer.


A hybrid cloud is a combination of different clouds, be it private, public or a mix. The biggest challenge is the integration of the different cloud services and technologies. Standardized APIs such as OpenStack seem to solve most of those issues.

Challenges for hybrid clouds

Hybrid clouds are starting to become more and more attractive for larger cnterprises. The claim is that hybrid clouds combine the benefits of both private and public clouds, but omit their drawbacks. Although this sounds great, let’s look at the challenges we face when we start to design and build a hybrid cloud:

Infrastructure as a service (IaaS) layer

On the IaaS layer, the main benefit we see in a hybrid cloud environment is that of leveraging the elasticity of public cloud resources, but maintaining a higher level of security for sensitive corporate data and applications by using a private cloud.

To address the security concerns for certain data and applications, a strong governance model together with adequate security policies need to be developed. It must be made crystal clear where applications and data are allowed to be placed and what the rational is behind these policies.

When applications scale out into public clouds to cover peak loads, we need to have a closer look at data placement. Not only for the sake of security, but this time also for the sake of performance. If an application requires a high amount of data, this application might not be suited for such a scenario unless, we have designed that properly beforehand (adequate network bandwidths, data replication, and so on).

Another challenging topic about hybrid clouds on the IaaS layer is their management. Clients who go for a full integrated hybrid cloud need to consider how to include the public cloud service catalog and automated provisioning into their local processes and infrastructure. Not all public cloud service providers offer open APIs or comply with open standards, but that’s a prerequisite for a seamless integration.

Challenges even grow when we consider managed public cloud services. Beside the technical boundaries of wide area network and data center locations, a split management responsibility comes with a large backpack of issues, which must be addressed. Monitoring, ticketing, backup and restore, and user management are just some of them. The service provider usually feels responsible only up to the operating system layer, sometimes also for middleware and databases, but very rarely for customer-specific applications. Those client specific applications must be operated by the clients themselves and therefore integrated into their systems management systems.

Software as a service (SaaS) layer

On the SaaS layer, a hybrid setup is less likely because of elasticity, but usually purely because of functionality. In this scenario, certain business functions are covered by a SaaS solution from an external service provider.

The challenge with this setup is to transport the required data to and from the public SaaS. First, the data that needs to be transferred must be identified, then, a secure interface must be developed to ensure the correct data is reliably fed into the remote software service, and result data is transferred back to the local environment. Because of the variety of data, and local and remote application combinations, not many standard software products are available to implement this linkage. IBM Cast Iron is one of them and provides a data field to data field link between many software products such as SAP and


A hybrid cloud is a complex animal, and preparation and design are key to address its challenges. However, most of these challenges can be solved, either by technology (Tivoli Service Automation Manager, Cast Iron, IBM Hybrid Cloud Integrator) or by governance and organization. Once established, a hybrid cloud is a very powerful asset combining today’s enterprise requirements with flexibility and cost efficiency!