Own hardware or cloud? Our rules of thumb for small workloads

After more than a decade of running small workloads in both worlds, on machines we own and on rented capacity, we have accumulated a set of rules of thumb that we now apply almost mechanically. This post condenses them. It is deliberately a decision-logic post: no provider names, no price comparisons, no platform selling, just the questions whose answers place a workload on one side or the other.

Question one: who must be able to leave

The first discriminator is not technical. If a workload's value depends on its data being under our or our customers' direct control, with an exit path that survives the disappearance of the vendor relationship, own hardware starts with a large advantage. Data control is the reason, for example, that archives, operational databases with long retention obligations, and anything whose leak would be irreversible tend to stay on machines sitting in rooms we can physically visit.

The reverse question matters equally: would this workload be harmed by having such an exit path? Short-lived build jobs, preview environments, and spiky public web traffic gain nothing from physical control and lose speed from it. The ability to conjure capacity for a day and forget it by Friday is exactly what rented environments are good at.

Question two: is the load constant or shaped

The second discriminator is the shape of the load. Constant, predictable load is the friend of own hardware: a machine that runs at a steady forty percent all year is the case where owned capacity pays for its keep, because its cost curve is flat and its capacity can be sized honestly once. Shaped load, bursts, seasonal peaks, or something growing without a stable baseline, is the friend of the cloud: paying only while the load exists beats permanently owning capacity for a shape that may never materialize.

Our quick heuristic after years of being wrong in both directions: draw the load curve first, and only then decide. Deciding the venue first and reverse-engineering the justification later is how we once ended up owning a machine that idled at ninety percent headroom for two years.

Question three: what does the workload physically need

The third discriminator is hardware: does the workload have physical appetites? GPU needs, unusual disk characteristics, or latency-critical local communication are places where owning the machine removes an entire negotiation. When a workload wants a specific accelerator or a particular storage profile, the options narrow, and "buy the box" becomes competitive rather quickly. When the workload is a plain stateless service with standard resource appetites, the physical argument dissolves and the decision falls back to the first two questions.

What we keep on own hardware

The pattern that emerged from our own fleet: system-critical infrastructure with steady load, data with long retention and strict control needs, anything with accelerator requirements, and the quiet workhorses of our own operation: monitoring, backups, the identity and configuration services the rest depends on. There is a compounding reason for keeping these home: the machines that other machines depend on should not sit behind someone else's change process. There is a quieter reason in the same direction. Ownership is what lets us schedule the failure drills: a Thursday evening taken to pull the monitoring host and learn what the estate thinks of it. In rented venues that kind of scheduled destruction is possible but tends to feel like asking permission first, and exercises that wait for permission get postponed until they turn into incidents.

What stays rented

On the other side: build pipelines, test and preview environments, seasonal public services, and anything whose lifetime is measured in weeks. Also every experiment that might simply not work out. The cloud's honest advantage is not power but disposability, and disposability is worth paying for precisely when the requirement is uncertain. A practical note on sizing the rented side belongs here: the honest number comes from a month of measured load, not from the requirement document. Our best rented decisions all started from a small reservation and a review after the first real week of traffic.

The two rules that survived the decade

Everything else is nuance, but two rules have survived every revision of this list. First, the workload's exit path is part of the decision: whatever we choose, we write down how it leaves that venue, because the venue that is easiest to enter is rarely the easiest to leave. Second, operations discipline transfers in both directions: the restore drill habit, the Ansible-built consistency, even the container hygiene, all matter identically on a machine in a rack and on a rented instance, and we have never regretted assuming so.

If you are weighing this decision for a workload of your own: the support pages describe how we operate both sides for customers, and the contact page is the direct way to talk through a concrete case.