But what if you started life as a small company with your systems entirely in the cloud? It's not an unusual approach, as running up your initial services in the cloud is straightforward and avoids a big capital outlay. As a company grows it's understandable that it might want to take on a private data centre, build an in-house support team and evolve to a two-site setup.
Step one is to consider why you're bothering with an on-premises setup instead of a second cloud instance. The answer will generally be that you want something that's closer to your office, with a potential performance improvement gained from such proximity. And that's fine – what matters is that you've considered the options before deciding which way to go.
The next step is to think about where you'll host your private data centre. As you're already in the cloud, you have the opportunity to pick a data centre that's close (electronically speaking) to the cloud centre you're in. For example, you're probably aware that AWS provides a Direct Connect facility that lets you hook straight into their infrastructure rather than accessing your cloud world over the internet. Check out the locations and you'll see that the connectivity's hosted at 51 well-known locations – Equinix in London, for example, or TierPoint in Seattle. Connectivity between your public and private components with a latency of just a few milliseconds is an attractive concept if you're looking for high availability with seamless failover.
Next, you'll need to think about the platform you're using. Most of the time you'll have used one or more of your cloud provider's standard operating system templates, so it makes sense to run your local stuff on the same operating system flavour if you can. And of course you should use the same CPU architecture where you can too, so you can be assured that your apps will be portable.
So you've sorted the platform. Now you need to decide whether the on-premises setup is to be your primary or secondary installation. If it's to be a secondary setup you should have a relatively straightforward job of adding new system and application-level components in as secondaries to your cloud-based apps.
If you decide to flip things around you'll have a more involved task of be shifting the primary apps over and redeploying the cloud setup as the secondary installation. Either way the happy news is that you've already gone through the non-trivial task of providing your office users with connectivity to the cloud installation, so hooking things up so they're able to get to the private data centre, regardless of whether it's the primary or the secondary, should be easier.
One further consideration with the choice of primary and secondary installations is the cost of data transfer. Shifting data out of a commercial cloud setup has a cost associated with it. Not a vast cost, I'll grant you, but one that you do need to keep an eye on. Using Amazon as an example, moving a terabyte per month over the internet from the cloud setup to your private installation will cost you $90. That's $900 for 10TB, or $7,800 for 100TB; even though the per-gigabyte cost tapers down, it doesn't ever tail off at zero. What does this mean? Easy: if the cloud setup is the primary and it's replicating application data to the private secondary, you're paying a chunk of cash for it to do so.
While we're on the subject of data transfer, you also need to figure out how you're going to do it. In these modern times, it's a relative doddle to set up the major cloud providers' storage instances so you can access them externally via standard protocols such as NFS. Alternatively you can look to the major storage vendors, who will sell you a funky gateway to install in your private data centre and handle the cloud magic for you.
The next consideration is licensing, and there are two aspects here. First is the basic fact that you'll need to buy operating system and/or application licences for your private setup – sounds obvious but you may not ever have had to consider this if you were using a pay-as-you-go model with pre-configured cloud app servers. Second is that if you want to go for a clustered or active/passive application setup, you may need to revisit the versions you use on the cloud servers as well as buying licences for your private setup. Take SQL Server, for example: if you're running Standard Edition you can implement basic two-node high availability, but if you want something more advanced you'll need to upgrade to Enterprise Edition. Same with Oracle: if you want to enable Data Guard between sites that'll need Enterprise Edition too.
Lastly, but by no means least, is your internal support team. They've probably spent a number of years fettling your cloud installation and fixing stuff when it broke, but their skillset will be at worst lacking and at best out of date when it comes to hosting, networking, hardware and hypervisor support.
Be prepared to invest in training so that you can be confident that the new kit you're acquiring for your private data centre is properly supportable and hence properly supported. Yes, your typical infrastructure is easier to put together than it was a few years ago, but that doesn't mean it's trivial. And if you're virtualising your private data centre – which you should – getting the hypervisor layer running and optimised will take time, effort and skill.
Going from a cloud-centric setup to a hybrid infrastructure isn't rocket science, then – which is no great surprise as any problem's tractable if you design, plan and implement the solution properly. But going from cloud to hybrid has some differences from going from private to hybrid.