Cloud Source
Showing results for 
Search instead for 
Do you mean 

Why not use our private cloud as a gateway to hybrid delivery

on ‎05-08-2013 02:32 AM

Source: freedigitalphotos.netMore and more articles point to the uptake of cloud in enterprises. And, if I believe the interactions I have with CIOs, it is definitely the case. The big question is whether to go private or public cloud. That, in my mind, is the wrong question. I’ve already mentioned several times that “one size does not fit all” when we talk about the cloud. We are, and will be for the forcible future, in a hybrid world. The use of shadow-IT by business people actually illustrates that perfectly.


Varying needs

Most companies have invested heavily in a series of environments to support their core business. Applications addressing financials, ERP, Supply Chain, back-office systems, etc. have been built with great expense. Are enterprises ready to throw that investment away and start all over again? Some do, some don’t. The ones that do actually take that decision because their applications do no longer address their business needs adequately, not because they find it fancy to go to the cloud. CIOs should always ask them whether it makes business sense to migrate their legacy applications to the cloud.


If we analyze workloads, we will see they vary from ERP and financials, whose data is a key asset of the enterprise, to VDI, e-mail and the enterprise website. Enterprises talk increasingly about big data and the need to analyze social media, whose data is already in the cloud. You see where I’m going. The first applications, if migrated to the cloud, are most probably best hosted in a private cloud, the latter can easily be hosted in a public cloud. And VDI & e-mail? That’s a little trickier. You probably would like the agility and responsiveness of a public cloud, but want to make sure your data is secure and maintained in compliance with local regulations. The public cloud may not give you all the transparency you require to assess that, so you may want to use what is getting known as a managed cloud. A managed cloud gives you an outsourcing type contract (with auditing capabilities) with pay-per-use billing and fast provisioning.


Finding the best compromise

As most IT departments are struggling to respond at the speed the business wants, while having to reduce their budgets, they need to make strategic decisions. Yes, the private cloud ensures all information is adequately secured, but may not guarantee to the business the agility it needs. It also requires capital expenditure which may be an issue. The managed cloud may sound very promising, but is typically somewhat more expensive than the public cloud. And then, for some applications, software-as-a-service appears the best solution.


IT departments end-up juggling two, three or four cloud service providers on top of their own private cloud and legacy environments. This is what we call hybrid delivery. It brings up a really good question, how will IT shield this complexity from the business users?


A unique portal for all services

The first element to put in place is a unique portal through which the business user can access all services available. Many intranets do that. Using web services, they give the business users access to all applications. The most advanced amongst them use single sign-on to avoid the hassle of users having to identify themselves when they access an application.


In our hybrid delivery environment, we can also use web services to integrate the traditional environment while using links to access external cloud services. But couldn’t we go a step further and allow the user to provision services directly from the portal? That would give them the full benefits of cloud.


Service provisioning

If we implement this capability, the user would have four different service types he could provision:

  • Services being run on the private cloud. That are the easiest, and most cloud stacks provide that functionality. Some limit themselves to infrastructure, while others allow the provisioning of applications and services (the latter being ideal for the business user).
  • Services being run within the legacy environment. Here web services will have to be created. These web services integrate with the legacy environment, shielding the user from the intricacies of the legacy.
  • Services being run by an external service provider (IaaS, PaaS and/or SaaS). This is what NIST calls intermediation. The private cloud will need to trigger the provisioning of the service in the target cloud using the cloud’s APIs. If the IT department wants to measure utilization and cross-charge costs, an additional interface needs to be set-up allowing the transfer of the utilization by user. In most public clouds the appropriate APIs exist to perform that functionality.
  • Services consisting of service elements of which some are run by external service providers. This is what NIST calls aggregation. Although the approach is similar to the previous point, there is one big difference. Not only does the private cloud needs to provision the service elements from the external clouds, but it also needs to set-up the appropriate security and isolation between the service elements each running in their own clouds. So, once the elements have been provisioned, some orchestration needs to take place to ensure they all run together.

 What does a Cloud Broker needs?

Looking at this, we need three things, a portal, a service catalog and an orchestration engine. Well, most private cloud environments provide those three elements, as they are required for running services within the private cloud. Cloud stacks focused on only the provisioning of infrastructure may be limited in the orchestration capabilities they provide. So, shouldn’t we use the private cloud as the broker to all our cloud services? Sure, that seems obvious. However though there is a caveat. Is the orchestration engine able to interact with external clouds? How easy is it to set-up a link with an external cloud?


In my descriptions above, I mentioned APIs. These are central to setting-up a cloud broker. Many cloud APIs use ReST, sending a webpage containing XML code to the API using HTTP. It is an easy way to build interfaces, used by many cloud software environments including OpenStack for example. Often authorization tokens are included in the calls. So, the cloud broker will need a place to store the tokens associated with each of the external cloud services.


If you believe you will use your private cloud as a broker, make sure you have the appropriate integration capability available in the orchestrator you decide to implement. Make sure you do following:

  • Enquire how you can integrate with external cloud services
  • Identify where you will be able to store the appropriate credentials and authorization tokens for the external cloud services
  • Establish how you will be able to receive the metering/billing information and if you can easily integrate it with the local data
  • Ensure you will be able to set-up security and isolation across a series of service elements that make up your service

And then there is a last point I have not talked about, and that is the data aspects. Can I ensure the data that is now scattered across multiple clouds is kept synchronized? Can I recoup the data for analysis purpose for example?



Hybrid delivery is increasingly becoming the norm for larger enterprises. I use this term rather than hybrid cloud, as the traditional environment cannot be forgotten. Providing end-users with one integrated environment to access all services makes sense. This implies we will need one platform to integrate all cloud services. The private cloud platform seems the obvious one. That however implies we have made the right choice upfront. Make sure you do that.


Interested in knowing what HP has to offer in this space, visit this page.

0 Kudos
About the Author


on ‎09-03-2013 03:49 AM

this news always well.

Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all