The current 8 Hybrid Cloud use-cases

Ask three different people what hybrid cloud means to them and you'll probably get three different answers.

In this entry I'll outline the eight major hybrid cloud concepts as most people would know them. Hopefully, this entry provides a solid introduction to hybrid cloud scenarios discussing not only the use-cases but also what I term their granularity. In my next entry I will discuss how these scenarios are being augmented by recent announcements in IBM's integration portfolio and show that the granularity of  hybrid cloud has just changed.

The 8 key current hybrid use-cases

I propose that there are 8 different hybrid use-cases that most people would recognise. 

I have categorised the use-cases into three distinct groups; those that discuss a complete group of servers, ones that discuss complete data-centers and those that discuss an application level split across data-centers.

Server-Level Hybrid Use-Cases

The following use-cases focus on  groups of servers being hosted in a cloud and on-premise.

1) Staged Development 

This use case centres on using the public cloud as a dev and/or test environment. Doing this allows developers to get up and running quickly while, say, on-premise infrastructure is bought, and set-up.

A nuance here is that it may not be wise to use the cloud environment for all of the testing requirements. For instance, performance testing should always be done on an environment which is as close to the production environment as possible and that's unlikely to be true in a hybrid environment unless dedicated machines are used - and even then it's debatable.

2) Cloud Bursting

Cloud bursting is the process by which a customer will allocate resources in the cloud when on-premise solutions run out of capacity at peak times. This shows that rather than investing in more on-premise capabilities for occasional peaks the customer decides that spinning up the new resource in the cloud is more advantageous.

Cloud bursting was one of the golden boys of the original hybrid cloud scenarios. However, it's actually quite hard to 'just spin up some resource'. Getting data to where you need it, when you need it and to share a load across an on-premise and off-premise solution requires time and effort to plan and complex load balancing and management to run.

Because of this the use-cases where cloud bursting makes most sense is when the customer can plan, in advance, what resource they need to move off-premise in order to account for their shortage of on-premise capabilities. This appeals a lot to retail scenarios - Retailers nearly always know when their big peaks and troughs are going to be (depending on where you are in the world think Easter, Christmas Day, Black Friday etc).

High Availability & Disaster Recovery

3) HA

I will define High Availability simply as having minimal downtime upon server failure. This has traditionally been centred around having multiple server instances available in some form of hot/hot, hot/warm or hot/cold mode. The key concepts around HA are for minimal downtime with minimal transaction loss.

Having a hot/hot configuration is, sometimes, a viable option for hybrid HA. However, I would call this 'HA by the back door'. Having a cluster of servers across both on-premise and cloud data centers enables HA while also ensuring capacity.

This doesn't work for some types of server e.g. MQ - where shared disk is the ideal or else marooned messages will occur. Nor does it make a lot of sense in many scenarios where you have most of the infrastructure local and just a few servers reaching into or out of the local center. In these circumstances data transfer is usually the overriding problem.

However, all scenarios are possible, if not wise, 

On that basis, I am going to discount most HA scenarios as not sensible to do (please tell me otherwise and I shall learn !)

4) DR

Disaster Recovery, on the other-hand, is more about ensuring that if a disaster (natural or otherwise) occurs at one specific site then, given enough time, the solution can be resurrected at an alternate site. The newly erected system will have the same capabilities as the original system but perhaps not exactly the same state i.e. there is no expectation that every previous transaction will be accounted for (at least not immediately).

DR is most certainly an option for hybrid cloud. However, it's also, most certainly, not a 'no-brainer'; network configuration, data movement etc. all require time and money to plan and implement in order to ensure a repeatable operation. It's still far more of an option than HA because the DR event is deemed to be rarer and the time it takes to bring the solution back-up in a consistent state is deemed to be acceptable in most scenarios.

5) Disconnected off-premise 

Now, silly as this may sound to some, having some off-premise projects that have no connection back to your on-premise systems (or vice-versa) is, in my book, a perfectly acceptable way to claim that you have a hybrid cloud environment.

This configuration still takes advantage of all the potential money saving that the off-premise offerings may give you. 

Data Center Level Hybrid Use-Cases

These two use-cases revolve around entire data-centers being located in different regions.

6) Regulatory Requirements

In many industries there are regulatory bodies that require data to be held near to its source. These requirements stem from different reasons however they all end up with the same problem statement. In such cases building a local dedicated data-center may not be a viable option so using a ready made cloud could make sense. 

I would caveat this by saying that when I have been involved in such projects the 'cloud' in this case has been a good old-fashioned data-center with dedicated hardware as the clients were banks and they weren't happy about having their data on shared infrastructure. However, that's not to say that it's not a viable option for other industries in the same situation.

7) Global Expansion

The above scenario has a partner..
Expansion into new regions often brings with it the requirement to have local data-centers for various reasons: regulatory (as above) or perhaps network latency or management concerns.

In this case making use of global cloud providers often makes more sense than potentially creating a new, company owned, data-center.

Application-Level Hybrid Use-Cases

8) Connected Application Use-Case

What distinguishes this use-case from disconnected off-premise and the others I have discussed so far is that the data or back-end system ('System Of Record' if you will) is almost certainly on-premise. This service is being called as part of a cloud based process. There are various strategies as to how to connect that data or core back-end system to the cloud. It's usually a trade off between convenience of the cloud versus network latency versus data replication and security.

Note how, in this case, those Systems Of Record may be hosted in a non-cloud environment like a CICS sitting on a mainframe rather than a 'cloud' - the definition of hybrid cloud still works.

This scenario focussed on the instigator of the transaction being hosted in the off-premise cloud and leading back to the on-premise solution. However, it's possible that an on-premise system could be the instigator of the transaction and take advantage of the off-premise clouds capabilities. Having said that - I've rarely seen it done that way. But, this is something I'll highlight in my next blog when I discuss the changing granularity of hybrid cloud.

Summary

I've laid out here the various hybrid cloud scenarios as I see them.  The majority of them are about using the cloud as a wholesale hoster of part of a system. The one scenario that breaks that is the connected application use-case.

In my next entry I'll show that this interaction granularity is being diversified even more by some recent IBM integration portfolio announcements.