Should You Self Host Or Use A Cloud Provider
Every time this comes up it gets framed as a religious war: monolith on a box you own, or functions scattered across someone else's cloud. Pick a side. There's apparently no in between.
There is. Almost everything I run lives in the in between, and I think the binary framing is the reason people make bad infra calls. You don't choose an architecture. You choose based on what you actually know about your workload — and most of the time you don't know enough yet to commit to either extreme.
The Two Caricatures
The argument usually sets up two strawmen.
The monolith. One codebase, one deploy, running on hardware you manage. Tightly integrated, predictable, yours. The story people tell is that it's old-fashioned and doesn't scale.
Serverless. Your app broken into functions that run on demand, with the provider handling everything underneath. The story people tell is that it's the modern default and you'd be foolish to run your own servers in 2025.
Both stories are marketing. The interesting systems I've seen sit nowhere near either pole.
The Middle Is Where Real Systems Live
The boring truth is that most things that work are hybrids. A container or two running steady-state work on infrastructure you control, with cloud services bolted on for the parts that are genuinely variable or that you don't want to operate yourself. Object storage, a managed queue, a CDN in front. You don't have to pick a camp to do this — you just use the right tool per piece.
I run my own Postgres and S3-compatible storage on a cheap box because those costs are predictable and I want the data to be portable. I reach for a managed service the moment a piece is bursty, undifferentiated, or risky enough that I don't want to own the failure. That's not a compromise position. It's the position.
How I Actually Decide
When I'm setting up a new project, I'm really only asking a few questions:
Do I know my traffic shape? This is the one that matters most. If I have no idea whether I'll have ten users or ten thousand next month, I want flexibility, and usage-based cloud pricing buys that. Once the traffic is predictable, a fixed-cost box is almost always cheaper. Serverless is a flexibility tax — worth paying while you're guessing, not after you know.
Is this piece my core competency or a distraction? If running the thing is part of what makes my product good, I run it. If it's undifferentiated plumbing, I'd rather pay someone to keep it alive.
What does it cost me to retreat? Lock-in is the real tax, and it's invisible until you want to leave. I lean toward setups I can pick up and move — containers, vanilla Postgres, S3-compatible storage — so that switching is a weekend, not a rewrite.
Who's on call? If nobody is going to babysit a Linux box, then paying a premium to not get paged is the correct, honest answer. Cost isn't only the invoice.
So What Should You Do
Stop looking for the architecture that wins. There isn't one.
Run the predictable, differentiated, portable parts yourself if you can operate them. Push the bursty, undifferentiated, or operationally scary parts to a provider. Keep everything containerized so the line between the two can move as you learn more about your traffic.
The right answer changes as the project grows, and that's fine — the whole point of staying in the middle is that you're not locked into a decision you made before you had any data. Pragmatism beats purity every time.