I’ve loved on-prem. I’ve distrusted cloud. I’ve defended both in pub debates. The answer isn’t emotional — it’s about workload, economics, and operational maturity.
Why I’m writing this
When I started in IT, everything was on-prem.
I still had a Motorola Razer.
(I still loved that phone.)
I was working at a power company, supporting the systems I’d been assigned, and at weekends flying around Europe playing gigs. I was away on holiday when one of my favourite bosses — someone I learned a lot from — reassigned some systems.
I came into work and JD said, in a teasing manner:
“Unlucky Winty, you got call recording and telephony.”
At the time, I felt a bit sidelined.
Turns out, I’d lucked out.
What On-Prem Really Meant Back Then
The company had built a fully bespoke system for recording screens and matching phone calls.
This wasn’t abstract infrastructure.
This was:
- Physical wire tapping in comms rooms across call centres
- Racks of call recording servers
- Storage arrays blinking away
- Patch panels, strip lighting, cold air
If someone in Aspect messed about with equipment, I’d often be the they would just plug in the taps in any old order.
And I loved it.
Rocking up in a Napalm Death T-shirt, pulling the call recording server out of the rack, tracing wire taps, test calling lines — it felt real. You could see it. Touch it. Hear it.
Those rooms were huge. Clean. Almost theatrical.
That’s when it clicked for me.
All the applications and batch jobs I worked on before that?
They may as well have been in the cloud.
Until you’ve stood next to the hardware, it’s all abstract anyway.
The Shift: DBA Life and Architecture Debates
Later, as a SQL Server DBA in local government, I had a much closer relationship with infrastructure teams.
My first day as a DBA?
Commissioning SQL Always On.
Nothing like high availability pressure to accelerate learning.
After-work pub debates with:
- The Infrastructure Manager
- A seasoned Dev Manager
Arguments about:
- Systems we couldn’t deploy to the cloud
- The risk of paying for both on-prem and cloud
- Data transfer volumes at a telecoms company making cloud “too expensive”
Those conversations triggered something in me.
Was cloud actually more expensive?
Or were we comparing visible costs with hidden ones?
What “Cloud Anxiety” Really Is
Cloud computing meter anxiety is real.
In Databricks, you can literally create a view showing what someone’s processing job cost.
You can watch it tick.
That visibility scares people.
I often say this:
If you ran that same query on:
- An on-prem server (including hardware, storage, power, cooling, staff)
- Or your laptop (including the cost of you being out of the game all day)
Is it really more expensive?
Or are you just uncomfortable because you can see the number incrementing?
On-prem hides costs in capital expenditure, support teams, and time.
Cloud exposes them.
Visibility feels like expense.
Sometimes it’s just transparency.
The Structured Comparison
1) Cost Model
On-Prem
- Large upfront capital spend
- Predictable running costs
- Hardware refresh cycles
- Over-provisioning “just in case”
Cloud
- Pay-as-you-go
- Elastic scaling
- Easy experimentation
- Risk of cost creep without governance
Stable workloads? On-prem can win.
Spiky analytics workloads? Cloud is your go too.
2) Control vs Convenience
On-Prem
- Full control
- Physical awareness
- Deep hardware-level tuning
- You own every failure
Cloud
- Managed services
- Faster provisioning
- Platform constraints
- Shared responsibility model
On-prem feels like craftsmanship.
Cloud feels like orchestration.
3) Scaling and Delivery Speed
On-prem scaling means procurement cycles.
Cloud scaling means clicking a button or pushing Terraform.
That changes how fast ideas move.
4) Disaster Recovery
On-prem DR requires serious investment.
Cloud DR is easier to implement — but still needs proper architecture.
Resilience isn’t automatic in either world.
The Real Answer: Use Cases, Not Perference
Early in my career, I loved on-prem because I could see it.
Later, I distrusted cloud because I could see the meter.
Now?
It’s about use case.
- Edge systems and ultra-low latency? On-prem.
- Heavy analytics and experimentation? Cloud.
- Regulated environments? Hybrid.
- Stable legacy workloads? Maybe leave them alone.
Architecture isn’t about love or distrust.
It’s all about context.
My Take
On-prem Is awsome! for telephone level processing. Stable transactions, Low latency of telephony exchange, ring fenced.
Cloud building on the fly, low budge, elactic processing, regionality.
Neither is inherently better.
Good/Bad architecture can exist in both.
Practical Takeaways
- Don’t fear visible cost — understand total cost.
- Separate emotional attachment from technical reasoning.
- Design DR properly, wherever you run.
- Ask what you want to operate vs what you want managed.
- Choose based on workload, not trend.
Wrap-Up
I started in server rooms tracing wire taps.
I’ve debated cloud economics in pubs.
I’ve seen both sides win arguments — and both sides get it wrong.
The reality is, that it isn’t on-prem vs cloud.
It’s:
Where does this workload belong — and why?
Gareth Winterman