Posted on Sep 8

Microservices are dead? why devs are rage-quitting the hype and going back to monoliths

#webdev #programming #microservices #development

Everyone swore by microservices, but now even big players are rolling them back. Here’s why monoliths are quietly making a comeback and when you should actually care.

Remember when every CTO was screaming “microservices or bust” like it was the one meta build that solved everything? Yeah, about that. Turns out splitting your app into 200 tiny services is less “4D chess” and more “herding cats with Kubernetes YAML.”

Over the last year, even the big dogs Twitter/X, Shopify, Amazon have quietly started rolling back their service sprawl. The hype train hit a wall, and a lot of devs (myself included) are asking: was microservices all just cope?

It’s like when you respec your whole skill tree for a shiny new patch, only to realize the nerfs made your old build stronger. Monoliths the OG, “boring but it works” style are creeping back into the spotlight.

TLDR

Microservices took off because Netflix and Amazon made them look god-tier. But for most dev teams, the complexity tax was brutal — more debugging, higher bills, slower shipping. Now, monoliths are trending again because they’re easier, cheaper, and faster for 90% of projects.

This article covers:

Why microservices blew up in the first place
The pain points nobody tells you about
Why monoliths are making a comeback
Real-world companies flipping back
A simple decision guide so you don’t over-engineer yourself into burnout

The hype train why microservices blew up

Back in the early 2010s, monoliths were the default. Rails apps, Django apps, Spring Boot monsters you shipped your features, slapped on some caching, and prayed your single repo didn’t implode during deploy. It worked… until scale hit.

Then Netflix rolled in like the giga-chad of distributed systems. They bragged about hundreds of microservices, each scaling independently, battle-tested with Chaos Monkey nuking their infra daily. Amazon had their “two-pizza teams” story, slicing services into neat, bite-sized deployable units. Every tech blog post made it sound like: if you weren’t doing microservices, you were basically running Windows XP in 2025.

And devs ate it up. Why wouldn’t we? The pitch was seductive:

Scale horizontally, no problem.
Teams ship faster without stepping on each other.
Resilience built-in if one service dies, the system keeps humming.

It was the “get abs quick” ad of software architecture. Who doesn’t want infinite scalability with clean team boundaries?

The tooling piled on too. Docker dropped in 2013, making containers cool. Kubernetes arrived in 2014, and suddenly “microservices” wasn’t just an architecture it was a whole lifestyle brand. Conferences, Medium posts, tutorials… all pushing “break your app apart or you’ll fail.”

The analogy here? It was like watching a pro gamer with a liquid-cooled RTX 4090 setup, then buying the same rig to play Stardew Valley. Just because it made sense at Netflix scale didn’t mean your side project todo app needed 18 services and a CI/CD pipeline that looked like NASA launch control.

But hype cycles don’t care about nuance. Microservices became the gold standard, and devs who weren’t doing them felt left behind like showing up to LAN night with integrated graphics.

The pain where it all falls apart

Here’s the thing nobody tells you when you’re drooling over the Netflix engineering blog: microservices look great on slides, but in practice they’re like juggling chainsaws while blindfolded.

On paper, each service is “independent.” In reality? Every service has dependencies. And those dependencies have dependencies. Before you know it, you’re in dependency inception, debugging why Service A refuses to talk to Service B. Spoiler: it’s usually because some YAML config got borked, or a timeout was set to 1 second instead of 5.

Let’s hit the pain points every dev who’s tried microservices has lived through:

Debugging hell You’re no longer tailing one log file. You’re tailing twenty. Something goes wrong? Congrats, now you’re doing distributed detective work, piecing together traces like a true crime podcast host.
Infra tax With great services comes great responsibility… for monitoring, CI/CD pipelines, deployments, retries, rollbacks, distributed tracing. All of which means you now need a DevOps team just to keep the lights on.
Latency everywhere That function call in your monolith that took 0.1ms? It’s now an HTTP request over the network with retries, serialization overhead, and possible packet loss. Suddenly your fast app feels like it’s running through molasses.
Costs creeping up Every extra container, managed service, and load balancer adds to the bill. Plenty of teams have been shocked to find their AWS invoices balloon just because they copied Netflix’s setup without Netflix’s budget.

I once lost an entire afternoon chasing down why two services in staging weren’t talking. Checked configs, redeployed twice, spun up more logs… turned out someone forgot to update an environment variable. Three hours gone because Service A was ghosting Service B like a bad Tinder date.

And this isn’t just an indie dev problem. Twitter engineers famously admitted their microservices sprawl made basic changes take forever. Imagine needing 20 code reviews across different repos just to tweak one feature. That’s not engineering, that’s unpaid bureaucracy.

The promise of microservices was speed and resilience. The reality for most teams is burnout, bills, and a strong desire to yeet Kubernetes into the sun.

The comeback why monoliths slap again

So after years of worshipping the microservices shrine, why are devs crawling back to monoliths like exes who “just needed some space”?

Because when you’re not Netflix-scale, monoliths just work. They’re not sexy, but they’re stable. Like the trusty ThinkPad that’s ugly as hell but outlives three MacBooks.

Here’s why the monolith meta is trending again:

Simplicity wins One repo, one deploy pipeline, one database. No hunting across 30 dashboards to find a broken request. You run the app, it runs. That’s it.
Cheaper to run Microservices mean you’re paying for load balancers, queues, monitoring, service meshes… basically a small nation’s GDP in cloud infra. Monoliths can often be deployed on one box or a small cluster. Fewer moving parts, fewer surprise AWS bills.
Faster iteration With microservices, every feature requires 10 Slack threads and half your sprint budget in coordination. With a monolith? You ship. Add the route, run the tests, push the deploy. Done.
Team size matters For a 5–20 dev startup, splitting into microservices is like using Git submodules for fun. No one wants that pain. Monoliths let small teams stay nimble instead of drowning in DevOps.

I worked at a shop where we ditched a half-baked microservice setup and rolled back into a Rails monolith. Suddenly, shipping new features went from weeks of coordination to days of coding. It was like uninstalling a bloated mod pack and watching your game FPS jump back to normal.

Analogy time: you don’t need twenty Discord bots to manage your server one bot with a couple solid commands gets the job done. Same logic applies here.

And don’t just take my word for it. Heavy hitters are openly defending monoliths again. Basecamp literally wrote “monolith first”, saying it’s the smarter starting point. And Shopify engineers have explained how their giant Rails monolith still powers billions in e-commerce without imploding.

The “boring” architecture isn’t outdated. It’s just underrated.

Receipts who’s actually doing this IRL

It’s one thing for random devs on Reddit to rant about microservices pain. But when the giants who pioneered this stuff start dialing it back? That’s when you know the hype cycle flipped.

Twitter/X: from chaos to “please just work”

When Elon’s crew gutted half the infra staff, engineers started spilling about Twitter’s tangled web of microservices. Simple features took forever to ship because they touched dozens of tiny services. Re-centralizing parts of the stack wasn’t optional it was survival. One ex-Twitter engineer described their system as “a Jenga tower of services where moving one block toppled five others.”

Amazon: not 100% micro, despite the legend

Amazon loves telling the “two-pizza teams” story (small teams, small services, big speed). And yeah, they use microservices heavily. But what often gets glossed over: huge chunks of Amazon still run as monoliths. The retail site itself? Mostly a monolith with modular bits around the edges. They didn’t rewrite their entire empire into gRPC fairy dust.

Shopify: the Rails monolith that could

Shopify openly defends its choice to stay on a massive Rails monolith. In their engineering blog, they explain how the structure makes it easier for thousands of devs to collaborate without drowning in microservice spaghetti. Their scaling tricks come from good modularization inside the monolith not breaking it into 500 microservices.

Basecamp: monolith evangelists

The Basecamp team has been beating this drum for years: “monolith first” is their mantra. They argue startups waste precious time and brain cells chasing microservice setups they don’t need, when a good monolith can scale plenty far before you hit real pain.

Contrast: micro still has its place

Not every company is running back. Netflix still thrives on microservices, and Uber’s global scale practically demands them. But notice the pattern: only companies with millions of users across the globe can justify the trade-offs. Everyone else? The receipts say monoliths are easier, faster, and cheaper.

So if you feel bad for “just” building a monolith? Don’t. You’re in good company.

Decision guide monolith or micro?

Okay, so here’s the million-dollar question: which one should you actually pick?

Spoiler: for 90% of teams, the answer is monolith. Not because microservices are “bad,” but because they’re a late-game architecture. You don’t buy Dark Souls armor sets when you’re still dying to tutorial mobs.

Here’s a simple way to think about it:

Start with a monolith. It’s faster, cheaper, and easier to reason about.
Only break it apart when the pain becomes unbearable. That usually means scaling teams, scaling traffic, or hitting deployment bottlenecks you can’t untangle.

To make this concrete, here’s a quick decision table:

Think of it like this: microservices are a raid build. They only make sense when you’ve got the party size and boss mechanics that demand it. If you’re solo-queuing your app into prod, keep it simple and go monolith.

Rhetorical gut-check question: Do you really need a service mesh, distributed tracing, and gRPC for your todo list app? Exactly.

So the practical playbook?

Start monolith.
Modularize internally (layers, clean boundaries).
Extract services only when absolutely needed.

That’s not “boring.” That’s called “not burning your sprint budget fighting infra instead of shipping features.”

Outro my hot take + what’s next

Here’s the thing: dev hype cycles always come full circle. We laughed at monoliths, then worshipped microservices, and now we’re realizing the “boring” option was actually carrying us the whole time. It’s the classic dev loop: reinvent pain, meme about it, then rediscover the old solution and call it new.

My hot take? 90% of teams shouldn’t touch microservices unless they’re speedrunning burnout. For most products, a solid monolith with clean boundaries is going to get you further, faster, and with fewer nights spent crying over kubeconfig.

That doesn’t mean microservices are useless they’re just not the starting line. They’re endgame content. If you’re running a billion-user global service and you need insane uptime, fine. Split things up. But if you’re a 10-person team trying to ship an MVP, a microservice setup is like bringing a NASA launch control center to a Minecraft LAN party.

What’s next? We’re already seeing a rise in “modular monoliths” — single codebases with clear boundaries that let you scale without the yak-shaving of full-blown microservices. Frameworks like Rails, Django, and even Spring are leaning into this again. The pendulum’s swinging back, and personally, I’m here for it.

So, let’s hear it: what’s your worst microservices horror story? Or maybe you’re one of the rare cases where it actually saved your bacon. Drop your scars and your wins in the comments. Let’s compare battle damage.