Public cloud versus on-premise and bare metal
Cloud is right for most workloads. It is wrong for a specific, identifiable set — and the tell is steady load or a regulator.
On-premise
Your hardware, your network, fixed cost
Public cloud
Elastic, managed, no capital outlay
We build and operate both, and we have no hardware to sell you, so there is no margin riding on this answer. For the large majority of workloads a public cloud is the right call and we say so on the first call.
But the industry has drifted into treating cloud as the default rather than a decision, and there is a specific set of cases where owned hardware is clearly better. Two signals matter more than the rest: whether your load is steady and predictable, and whether a regulator, a client contract or a sovereignty requirement constrains where the data can sit.
Where they actually differ.
| Dimension | On-premise | Public cloud |
|---|---|---|
| Cost at low or bursty load | Poor. You pay for peak capacity permanently, and most of it sits idle. | Strong. You pay for what you use and scale down when nothing is happening. |
| Cost at steady high load | Frequently much cheaper. Owned compute at high utilisation is hard to beat. | Always-on instances at scale become one of the larger recurring line items. |
| Data egress | Effectively free once the link is paid for. | Metered, and the item that most often surprises data-heavy workloads. |
| Time to first environment | Weeks. Procurement, racking or colocation, and provisioning. | Minutes. A decisive advantage early in a product's life. |
| Elasticity | Bounded by what you bought. Growth means a purchase order. | Near-unbounded, and the main reason cloud became the default. |
| Data residency and sovereignty | Absolute. The data is on hardware you control, in a building you choose. | Good via regions, but the operator is a third party — which some regimes will not accept. |
| Operational burden | Real. Hardware failure, firmware, capacity, power and physical security are yours. | Substantially lower. Managed services remove work you would otherwise staff for. |
| Managed services | You run your own database, queue and object store, or pay someone to. | Extensive, mature, and the strongest practical argument for cloud. |
| Lock-in | Minimal, if you stayed on open components. | Accrues quietly through proprietary managed services on the critical path. |
| Disaster recovery | You design and pay for a second site. Meaningful capital cost. | Multi-region is a configuration change. A genuine and large advantage. |
- A regulator, a client contract or a sovereignty requirement says the data must sit on hardware you control. This decides it outright, whatever the economics.
- Load is steady, predictable and high. Utilisation above roughly 60% on always-on compute is where owned hardware usually wins.
- Data egress or GPU compute dominates your bill — the two line items where cloud pricing is least forgiving.
- You are in a segmented or air-gapped environment where a public cloud is not reachable by design.
- You already have suitable hardware sitting underused, or existing colocation with room in it.
- Load is spiky, seasonal or unknown — which describes almost every product before it has real traffic.
- You are early and speed matters more than unit economics. Weeks of procurement is the wrong trade.
- You want managed databases, queues and object storage rather than staffing to operate them.
- You need to be in several countries without buying hardware in each.
- You have no appetite for hardware, and no one who wants to own capacity planning and firmware.
Our view
For most companies: start in a cloud, keep the application portable, and revisit when either the bill or a regulator forces the question. Portability is the decision that actually matters — containers, open components, no proprietary managed service on the critical path. Get that right and moving later is ordinary engineering. Get it wrong and the choice you made in year one is permanent.
Follow-ups.
Where is the crossover point, roughly?
It depends on utilisation more than absolute size. Above roughly 60% sustained utilisation on always-on compute, owned hardware usually wins on a three-year view. Heavy egress or GPU workloads cross over much earlier. We model it with your actual usage rather than a rule of thumb.
Can we move back from cloud to on-premise later?
Yes, and repatriation is increasingly common. How hard it is depends entirely on how much proprietary managed service ended up on the critical path. Containers and open components make it routine; a deep dependency on one provider's serverless and managed data stack makes it a rebuild.
Do you sell hardware?
No. We size the requirement and give you a specification you can buy from any vendor or colocation provider. That also means we have no reason to over-specify it.
Is a hybrid arrangement realistic?
It is often the sensible end state: regulated data on your own hardware, everything else wherever is cheapest. It works when the application was built to be portable, and it is painful when it was not.
Tell us what you are building.
A short conversation is usually enough to tell whether we are the right firm for the problem. If we are not, we will say so and point you somewhere better.