When the rack stays

The question is not whether, but what

Ten years ago “are we going to the cloud” was still a conversation. It no longer is: mail, documents, collaboration and most business applications run better and cheaper in a cloud service than on a server in your cupboard. That part is settled.

What remains is the rest, and that is exactly where the standard advice stops. A production environment, an application from a vendor with no cloud version, a system that has to talk to equipment in the same building. That is what this article is about.

Four reasons the rack stays

We genuinely meet these four, and all four can be justified.

• The application will not move. A vendor with no cloud version, or a version missing features you use. That is not your backlog but theirs, and you cannot work around it. We then build an environment you can keep managing until the vendor catches up.
• The connection cannot carry it. Large files, design work, video editing, or a site where the available connection is simply not good enough. Then the calculation is quick: process locally and move only the result.
• There is a requirement about where data sits. Sometimes from regulation, more often from a client contract. If you have to be able to point at the building something sits in, that is a hard requirement rather than a preference.
• The load is heavy and constant. Cloud charges by use, which favours you when your use fluctuates. For a system doing the same thing twenty-four hours a day, that calculation often tips the other way.

Three reasons that are not reasons

And these are the three we hear at least as often, and which are not.

• “Our data is safer in house.” Usually not. A large cloud platform has a security team bigger than your whole organisation. What is true: with your own hardware you decide who can reach it, and that is a different argument from safety. Call it what it is.
• “We have just invested in it.” Understandable, but that is a reason to wait rather than to stay. We then plan the move for the moment the equipment has to be replaced anyway. That is timing, not postponement.
• “It works.” True until it does not. The question is whether you know when support ends and what happens then. If nobody knows, “it works” is an assumption rather than a state.

What comes with own hardware

If a rack stays, the brand is not the interesting part. We supply and manage HPE among others for servers and storage, and on the virtualisation side we work with VMware, Nutanix and Proxmox. Whatever your brand, this belongs with it:

• Monitoring that reports itself. One disk failing in a set of four is not an outage. A second disk failing because nobody noticed the first one is.
• Parts and lead times agreed. Not “we will order one”, but recorded in advance how quickly something can be replaced, and whether that fits inside your recovery time.
• An end date you know. Hardware has a support life. We note it on the day of installation, not in the year it expires.
• A recovery plan that does not need the building. See below; this is where it goes wrong most often.

The recovery plan is the real difference

Cloud or own hardware changes little about how you work on an ordinary day. It changes everything about what happens on the day something goes wrong.

With a cloud service the question is: how quickly is the provider back, and what does the contract say about that. With your own hardware the question is: where do you keep running if this building is unavailable. A backup sitting in the same rack as the server protects against a failed disk and against nothing else.

So we agree per system how long it may be down and how much work may be lost, and we test recovery into an environment rebuilt from nothing. That is a different test from “does the file come back”, and it produces surprises more often.

How we record and demonstrate that sits under data and business continuity.

How we make the choice

We have no preference fixed in advance, and that is not modesty: it is the only way to give advice that still holds in three years. In practice it goes like this.

• We look first at which systems exist and what they need, not at where they currently run.
• Per system we set the four reasons beside it. If none applies, the cloud is the starting point.
• Where hardware stays, we plan replacement for the moment the existing equipment reaches its end anyway. Replacing working hardware because a plan says so is expensive and rarely returns anything.
• The outcome is almost never all or nothing. Most organisations end up with part in the cloud and part in the rack, and that is a fine outcome as long as you can explain why for each part.

Migration and day-to-day management sit under cloud services and managed IT.