The Seductive Lie of 'Everything as a Service'
The siren song of "Everything as a Service" is powerful. It’s the promise of a pristine, minimal setup where our only job is to consume an API endpoint, and a team of experts somewhere else handles the messy bits: the scaling, the security patches, the hardware failures. For many small services or fledgling projects, this can be a godsend, a way to move fast without being crushed by operational debt. But lately, I’ve been thinking that we’ve accepted a subtle, dangerous trade-off without asking the hard questions. The received wisdom—"just use a managed service, it’s easier"—often masks a slow erosion of control and a fragility we no longer know how to diagnose.
Don’t get me wrong; I’m not advocating for building your own database from scratch or managing your own global anycast network. The problem isn't the existence of these services, but the blind faith we place in them. The trouble starts when you string together a dozen different black boxes. Your authentication is Auth0, your search is Algolia, your storage is S3, your queue is SQS, your logging is a third-party SaaS, and so on. Each decision, taken in isolation, seems perfectly rational. But together, they create a distributed monolith of external dependencies. When something goes wrong—and it will—your ability to troubleshoot is limited to checking status pages and waiting.
The Operational Blind Spot
This architecture creates what I call an operational blind spot. In the old days, if your database was slow, you could SSH into the machine, check top, look at the slow query log, and get a tangible sense of the problem. It was messy, but the levers of control were in your hands. Now, when a managed database service slows to a crawl, your primary recourse is to open a support ticket. You are no longer an operator; you are a bystander. This distance doesn't just slow down resolution; it actively prevents you and your team from developing the deep, intuitive understanding of your systems that is the hallmark of true operational maturity.
Furthermore, this model quietly externalizes the cost of resilience. Yes, a large provider likely has better uptime than a single server you manage. But you've swapped one type of risk for another: the risk of a single, catastrophic failure of your own making for the risk of a cascading failure across your entire dependency graph. When a major cloud provider has an outage, it isn't just your service that goes down; it's every service you rely on simultaneously. Your fate is now tied to a single point of failure that is completely outside your influence.
The alternative isn't to abandon services altogether, but to be ruthlessly intentional about our dependencies. Ask yourself: Is this service core to our value? What is our escape plan if it becomes too expensive, goes down, or changes in a way that harms us? Can we replicate its functionality with simpler, more controllable technology if we need to? Sometimes the "boring" solution—running a PostgreSQL instance on a VM you control, writing logs to a local file—isn't just simpler, it's strategically smarter. It keeps the operational knowledge within your team. It ensures that when the digital storm comes, you're at the helm with a working compass, not just hoping the captain of a distant ship got your distress signal.
Notes & further reading
A few pages I came back to while writing this: