First, there was software as a service, infrastructure and then platform as a service, then public and private cloud, and today hybrid cloud — but is the latter vendor-driven cloud washing or something more?
Lending credence to the latter is the fact EMC last week spent a juicy $1.2bn buying Virtustream to increase its presence in hybrid cloud. In a field vulnerable to conflation and hype, though, what exactly does hybred cloud mean — how do you do “it"?
Hybrid cloud, in my world at any rate, is where you have your own on-premise services and cloud-based services and they integrate with each other in some way.
If you have some on-prem stuff and some cloud stuff and they do different things, then frankly you're not trying. They've got to work together for it to count.
Come to think of it, though, if you have a cloud setup where you use two different providers for an integration operation, I'd be happy to let you think of that as “hybrid” too – you're having to do integration between a cloud provider and somewhere else, after all.
Which components exist where?
The on-premise kit is pretty obvious: you'll have applications sitting on physical servers, with the physical servers connected to some storage. If you've got any sense you'll have an additional layer of virtual servers between the apps and the physical servers, because unless what you do is very niche indeed this is the best way to get the most from your physical kit.
In the cloud you only have up to three of these layers: the obvious one is the applications, but these will either: (a) be presented to you in a SaaS offering (so you see nothing of the servers they sit on); or (b) sit upon virtual server and storage technology over which you have management control.
In a SaaS offering there's not really much scope for hybrid operation – it's where you control the underlying infrastructure that you can do funky hybrid stuff.
At which level do I integrate?
The key question is: what do I want to do with hybrid cloud? The three I tend mostly to come across are:
- On-premise systems with cloud for disaster recovery (“DR”)
- Public-facing services back-ended by on-premise systems
- Cloud-based, heavy duty processing reporting back to on-premise kit
Each of these has its own nuances, so let's look at the options in turn. I’ll assume you have connectivity between the locations (more about that in the next section) and so will concentrate on the other aspects for now.
Using the cloud for DR
If you want to use the cloud for disaster recovery, you need three key things:
- Enough storage in the cloud to house the data used by the applications
- Enough server capacity to run the applications in the event that the primary site has died and you need to invoke the DR systems
- The ability for the users to access the apps in the cloud
You can't avoid paying for the cloud-based storage: you need somewhere to put the data, even though you're not using it. What you can do, of course, is request just enough for the data you have since you can generally increment it very quickly and easily.
The main problem to solve with the storage in this scenario, then, is how to get the traffic into it: you want to optimise transfers as much as you can, because every write that happens on the on-prem storage needs to be sent to the cloud.
Choose your provider carefully, then: some of them support particular storage optimisation technologies (SteelStore, for instance, which was bought by NetApp from RiverBed not so long ago), so if you think you're going to need more than the raw bandwidth between points A and B, choose your provider with your favourite storage optimiser in mind.
Server capacity is a more interesting problem, as it depends on the way your applications replicate. One of the motivations for choosing the cloud as your DR location is that you pay as you go, and you only have to run up the servers and start paying when you invoke the DR site.
This isn't great, for instance, with a database system that replicates from master to slave by simply copying every write query and executing it on the slave – it means you must have a server with sufficient processing power constantly operating in the cloud in order to keep the remote copy up to date.
However, if you have apps that don't need vast amounts of server power at the remote end, you're able to achieve the savings goal you're aiming for.
As far as connectivity goes, this isn't usually a problem since connecting users remotely to the cloud is generally like falling off a log. You do, however, need to be conscious of security, which means you'll want to consider cloud-based directory services – which could be a domain controller in your DR cloud or even an externally hosted service into which both your on-prem and DR sites connect for authentication.