For a decade the default answer to "where should this run?" was "the cloud," and for a lot of workloads that was right. But defaults have a way of outliving their reasons. We regularly meet teams paying cloud prices for steady, predictable workloads that would be dramatically cheaper to own — and others running creaky on-prem hardware for spiky demand that screams for elasticity. The point isn't that one venue wins. It's that the choice should be deliberate.
Here's how we reason about where infrastructure belongs.
The three venues, honestly
Cloud buys you elasticity and speed. You can stand up capacity in minutes, scale it down to nothing, and never touch a screwdriver. You pay for that flexibility on every byte and every hour — which is a bargain for variable demand and an expensive habit for steady-state load.
Colocation is the middle path that teams forget exists. You own the servers; someone else owns the building, power, cooling, and network drops. You get near-cloud reliability and connectivity without cloud per-hour pricing, and without becoming a facilities company. For sustained, capacity-heavy workloads — GPU fleets, storage-dense systems, anything that runs hot around the clock — colo often has the best total cost by a wide margin.
On-premises still wins when data can't leave the building (regulatory, latency, or sheer volume), when you have existing facilities, or when physical control is the requirement. The cost is real: power, cooling, hardware refresh, and people to run it.
The questions that actually decide it
Skip the ideology and answer these:
- What's the duty cycle? High, steady utilization favors owning (on-prem or colo). Spiky or unpredictable favors cloud.
- Where does the data have to be? Compliance, data gravity, and egress costs often decide the venue before anything else does. Moving large datasets in and out of the cloud repeatedly is a silent budget killer.
- What's your time horizon? Capex on owned hardware amortizes over years. If the workload won't exist in six months, don't buy a rack for it.
- What's the cost of downtime? This sets your redundancy requirements, which drive the real bill far more than the compute line item.
- Who operates it? Owned infrastructure needs hands and on-call. If you don't have them and won't hire them, factor in that gap honestly.
The pattern that usually wins: deliberate hybrid
Most mature setups aren't all-one-thing. They put the steady baseline where it's cheapest to own, keep regulated or latency-bound data where it must be, and use cloud for elasticity, global reach, and the experiments that shouldn't wait on a purchase order.
The hard part isn't picking venues — it's making them act like one system. That means consistent networking and identity across venues, data that can move (or deliberately can't) by design, and a single view of cost and reliability instead of three disconnected ones. Done well, you stop overpaying for steady load and stop starving spiky demand. Done badly, you get the costs of all three and the benefits of none.
A migration is a chance to right-size
The worst time to copy your current footprint is during a move. A "lift-and-shift" that faithfully reproduces an over-provisioned datacenter in the cloud just relocates the waste at a higher price. Every migration is an opportunity to measure real utilization, retire what nothing uses, and place each workload where it actually belongs.
Where to start
You don't need a year-long strategy engagement to make progress. Start by measuring true utilization and the all-in cost of what you run today — including the egress, the redundancy, and the human time. The right venue for each workload usually becomes obvious once the real numbers are on the table.
That measurement-and-placement exercise is exactly the kind of scoped assessment that pays for itself in the first round of decisions. If you're not sure whether your footprint fits your workload, that's the conversation to have.