Cheat Sheet: Data repatriation

If the cloud is no longer living up to your hopes, you’re not alone. Steve Cassidy says it’s time to bring your data home

No longer convinced by the cloud? It might be time to bring your data home.

This must be to do with data sovereignty, right?

Sorry, you’ve been taken in by a case of sloppy naming. You may want to keep your mailing list out of the hands of the Department of Homeland Security, but data repatriation is something more fundamental than that. It means bringing that data right back in-house to live on your own servers under your own roof.

And why would we want to do that?

There are several scenarios in which repatriation makes sense. You might be facing baseline price hikes from your cloud provider – or your costs could be creeping up due to increasing usage. Perhaps you prefer to rely on physical machines that you have full visibility into, rather than virtual services that you don’t. Or you may have concluded that, for your particular workloads, it doesn’t make sense to pay for the enormous, on-demand scalability of the cloud.

Isn’t the cloud meant to be cheaper than in-house servers?

A few years back, when working out the cost of local computing resources, it was fashionable to include all peripheral expenses, from the rent on the server room to the pensions of the IT crew. This certainly made the cloud look like good value – but it turns out that ditching physical servers doesn’t necessarily slash your outgoings or staffing costs. Meanwhile, server hardware keeps getting faster, cheaper and more efficient; businesses that take a fresh look may find that the logic now points in the opposite direction.

What about backup and archival? We’re not eager to bring all of that back in-house.

You should, though: archival is a strong reason for going local. Your particular mix of data and software products is likely to be more unique and quirky than any other part of your IT portfolio, and you’ll probably have noticed that “unique and quirky” aren’t things cloud service providers like to deal with. They prefer words such as “efficient” or “identical” – their ideal is to minimise customisation, while handling matters yourself ensures you can design your provision to fit the peculiarities of y our business.

Our developers are always spinning up cloud instances for testing – is it smart to take that away from them?

As far as a developer’s concerned, there’s very little difference between connecting to a cloud host and starting up a new VM within your own server farm. You can use old-school hypervisors such as VMware or pure web-delivery containers – it’s all the same technology. Also bear in mind that no one’s saying you have to go either 100% local or 100% cloud. If you value the ability to fire up a million test instances, there’s no reason you can’t keep paying for that cloud capability, while repatriating the things that work better in-h ouse.

So how do we decide what stays in the cloud and what comes home?

Most repatriation projects originate with the CFO. They’ll be keeping a close eye on your hosting bills and they’ll want to see the most expensive service repatriated first. There may be other angles, but given the economic effects of the pandemic, the CFO is likely to win the argument. And, to reiterate, there’s no need to go all-in: a 80/20 split is a guard against wasting money trying to move the immovable.

Can we really run our own services as reliably as a blue chip?

That’s not an impossibly high bar – some blue chips can be terrible! Naturally, you’ll need to think about reliability and resilience, but as we’ve mentioned, on-premises hardware has come a long way in the past few years. If you set things up right, downtime is far rarer than it was back in the pre-cloud days.

“Perhaps you prefer to rely on physical machines that you have full visibility into, rather than virtual services that you don’t”