Hybrid cloud: Deciding the right mix for your workloads
The old public, private, or home school sorting bin
Blog Anyone who's read much of what I write for The Reg will know that I'm a believer in hybrid cloud – using the cloud for some elements of your world whilst retaining components on-premises too. But precisely which elements? We'll look at how you might decide what belongs where: on-premises, in the private cloud, or in the public cloud.
On-premises doesn't really mean that
Before we get going it's worth considering what we mean by our terminology. When I talk on-premises I don't, unless you're a big company that can afford suitably protected premises, mean servers and storage in your own office.
To me an on-premises system is one that sits in a dedicated area (or at least private, single-client cabinets) in secure data centre to which your office has suitably fast connectivity and which is run by a professional outfit with the appropriate certifications (SOC, PCI-DSS, ISO27001 – the usual suspects). So for on-premises think “self-owned and private”.
Private cloud versus on-premises
While we're at it, let's also talk about what I mean by private cloud computing. Gartner defines it as: “a form of cloud computing that is used by only one organization, or that ensures that an organization is completely isolated from others”.
The most common way I see this implemented is where you layer your own cloud-like installation in your on-premises (i.e. private data centre) installations. Imagine you have a pair of data centres and you build a ESXi/vCloud world that spans them (other virtualization platforms are available … but they're not as good) – that's the type of private cloud I'm used to.
Our decision process is, then: what to host as stand-alone systems in the data centre; what to run on a virtual infrastructure in the data centre; and what to put in the cloud.
On-premises We'll do this one first because it basically soaks up all the exceptions: my default position is seldom to host something as a stand-alone entity for a number of reasons – the cost of making it resilient, the space it takes, the power it drinks and the relative maintenance effort compared to the alternatives.
The usual candidate is unusual platforms. If your architecture choice involves a pile of SPARC-based enterprise servers, or a big IBM Power8 setup, it's a real no-brainer: you need to go out and buy the kit. While you should, as part of the decision process during the design phase, consider proprietary kit against (say) an Intel-based virtualized platform, you shouldn't be obsessed with trying to shoehorn the setup into Intel/ESXi/Hyper-V just because that's what your virtual platform runs on. Yes, you have to be cautious about doing something out of the ordinary because of the potential support skills gap, but if the cost of dealing with another platform is overshadowed by the benefit you get from it, don't shy away from that decision.
The other one I've discussed recently with friends and colleagues who run infrastructures is the “I have a socking big transactional database server and it needs to be physical” concept. If I'm being honest, though, I remain to be convinced in most cases that this is true.
Yes, you have a box at each site with eight quad-core CPUs, four dual-port Gigabit Ethernet LAN cards, and a pair of Fibre Channel HBAs connecting the storage. But would it really be a big leap of faith to migrate this to a hypervisor-based solution on similar hardware, which perhaps has some advantages (hypervisor-level de-duplicated virtual machine snapshots, with correspondingly simple live backups, for example)? In most cases I've seen this would be enough.
I do have a tendency to run backup servers as stand-alone machines in an on-prem setup, though. Two sites, a big box at each, dual 10Gbit/s LAN connections, dedicated backup traffic VLANs in the physical and virtual switches, high-speed backup media that preferably replicates itself between locations. If your virtual environment craps itself, you're in trouble if your backup server was a VM sitting on it.
One clue as to what I'd put in a private cloud came earlier when I mentioned that your data centre has to have “suitably fast connectivity” to your users. Unless you have very fast connectivity between the office and your chosen public cloud installation, you're likely to want to put things like file servers on the private cloud setups in your data centres.
They don't need ridiculous amounts of processing power but they do need some sensible connectivity for the users not to moan, particularly if you're shoving big presentations, documents and spreadsheets around the place. Yes, you can (and should) look to use WAN optimisers to improve the performance between your private world and the public cloud, but raw speed is useful for high-data-flow situations.
The other category of system I'd put in the private cloud is systems whose security you really care about. If you're doing highly confidential legal work for a client, the chances are that you feel a lot safer with it in your secure data centre than in a cloud installation.
Are you justified in feeling this? Well, yes and no. No, because with modest knowledge and a healthy dose of caution you can configure your public cloud services' networking and firewalling pretty much as securely as a private cloud setup. But yes, because you still have the potential for some numpty to set their management password to passw0rd and make the management interface of the thing insecure.
In a public cloud setup you don't get low-level access to log files at the hypervisor level: this means that if a client comes to you and accuses you of allowing their proprietary data to be accessed illicitly in the cloud, you often can't prove that this hasn't happened. And the client confidentiality world is one where you're guilty until proven innocent.
The public cloud is my first consideration for pretty much everything else. This doesn't mean that I'd necessarily use it for anything else – just that I'd consider it first. I may decide, having weighed it up, that a particular application does in fact live better in the private cloud – but I'd consider public cloud first.
There are some apps that I do find tend to gravitate to the cloud. Email's an obvious one (let someone like Microsoft look after it rather than giving me a pile of loud kit and temperamental software, thanks very much), as is web hosting (a decent ISP's hosting centre probably has better DDoS protection than I can achieve on my much thinner Internet connection).
Pretty much anything that's internet-facing by design (content filtering, web sites, FTP sites, etc.) often lives more happily in the cloud than on-premises, unless there's a need for fast connectivity from the web-facing DMZ to a back-end system inside the firewall (a concept one would try to avoid anyway for the obvious security reasons). I'm also a bit of a fan of using the cloud for data archiving at the moment, too; if the confidentiality aspects discussed in the previous section can be happily mitigated it's a cheap way to store your data archives and with modern storage virtualization appliances it's simple too.
As for other apps: consider each on its merits. Obviously you need to be a bit holistic and look across the portfolio (there's no point putting two apps that need to be tightly coupled in different environments) but be methodical and understand the pros and cons of each location for each app.
In short, then:
- If it really doesn't fit a virtual environment in either the public or private cloud, don't be frightened to implement it in a physical, on-premises form – but don't forget the overhead of supporting and maintaining a heterogeneous setup.
- If it doesn't fall into the above but it has to be electronically close to the users, private cloud is Plan A.
- If it doesn't fall into either of the above then public cloud is Plan A.
- But don't forget that setups differ: think about each app and don't disregard the alternatives if they do turn out to be favourable in one or more specific situations.
Sponsored: From CDO to CEO