Skip to main content
Background Image
  1. Database Guru/

Are Microservices a Stupid Idea?

·624 words·3 mins· ·
Ruohang Feng
Author
Ruohang Feng
Pigsty Founder, @Vonng
Table of Contents

Amazon’s Prime Video team published a very compelling case study [2] explaining why they abandoned microservices and serverless architecture in favor of a monolithic architecture. This move saved them an astounding 90% in operational costs while also simplifying system complexity — a massive win.

But beyond praising their wise decision, I think there’s an important insight here that applies to our entire industry:

“Our initial solution was designed as a distributed system using serverless components… In theory, this would allow us to scale each service component independently. However, the way we used certain components caused us to hit hard scaling limits at around 5% of expected load.”

In theory” — this is a brilliant summary of the microservices frenzy that has ravaged the tech industry in recent years. Now the theoretical paper discussions finally have real-world conclusions: in practice, the concept of microservices is like siren songs, tempting you to add unnecessary complexity to systems, and serverless only makes things worse.

The funniest part of this story is that Amazon itself was the original exemplar and spokesman for Service-Oriented Architecture (SOA). Before microservices became popular, this organizational model was quite reasonable: at a crazy scale, using API calls for internal company communication beats coordinating cross-team meetings.

SOA made sense at Amazon’s scale — no single team could know or understand all aspects needed to steer such a massive ship, and having teams collaborate through publicly published APIs was brilliant.

But like many “good ideas,” this pattern becomes extremely harmful when taken out of its original context and applied elsewhere: especially when stuffed into single application architectures — which is exactly how people do microservices.

In many ways, microservices are a zombie architecture, a persistent thought virus: from the dark ages of J2EE (Remote Server Beans, anyone heard of those?), through the WS-Deathstar [3] nonsense, to the current forms of microservices and serverless — it keeps devouring brains and eroding people’s intelligence.

But this third wave has finally peaked. I wrote a paean to “The Majestic Monolith [4]” back in 2016. Kelsey Hightower, the thought leader behind Kubernetes, also expressed this in his 2020 article “Monoliths are the Future [5]”:

“We’re going to break apart the monolith and find the engineering discipline we never had before… Now people went from writing terrible code to building terrible platforms and infrastructure.

People get caught up in the hot money and hype tied to these trendy buzzwords, because microservices brought tons of new overhead, hiring opportunities, and job positions — everything except actually being necessary for solving their problems.”

That’s right — when you have a coherent single team and monolithic application, replacing method calls and module separation with network calls and service splits is an incredibly insane idea in almost all cases.

I’m glad to have beaten back this zombie-like stupid idea for what feels like the third time in memory. But we must stay vigilant, because we’ll have to do this again sooner or later: some half-baked ideas will keep coming back no matter how many times you kill them. All you can do is recognize them when they resurrect and blast them to pieces with article shotguns.

Effective complex systems invariably evolve from simple systems. The converse is also true: complex systems designed from scratch never work effectively.

— John Gall, Systemantics (1975)

This article is by DHH, creator of Ruby on Rails and CTO of 37signals, translated by Vonng.

The original title was “Even Amazon can’t make sense of serverless or microservices [1]”, meaning “Even Amazon thinks microservices and serverless are bullshit.”

References
#

[1] Even Amazon can’t make sense of serverless or microservices: https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580 [2] Compelling case study: https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90 [3] WS-Deathstar: https://www.flickr.com/photos/psd/1428661128/ [4] The Majestic Monolith: https://m.signalvnoise.com/the-majestic-monolith/ [5] Monoliths are the Future: https://changelog.com/posts/monoliths-are-the-future

Related

It's Time to Say Goodbye to GPL
·2103 words·10 mins
This article argues that in 2020, the enemy of computing freedom is cloud software, and advocates for the concept of local-first software.
Understanding Time - Leap Years, Leap Seconds, Time and Time Zones
·3220 words·7 mins
A proper understanding of time is very helpful for correctly handling time-related issues in work and life. For example, time representation and processing in computers, as well as time handling in databases and programming languages.
Understanding Character Encoding Principles
·4732 words·10 mins
Without understanding the basic principles of character encoding, even simple string operations like comparison, sorting, and random access can easily lead you into pitfalls. This article attempts to clarify these issues through a comprehensive explanation.
Concurrency Anomalies Explained
·6114 words·29 mins
Concurrent programs are hard to write correctly and even harder to write well. Many programmers simply throw these problems at the database… But even the most sophisticated databases won’t help if you don’t understand concurrency anomalies and isolation levels.
Blockchain and Distributed Databases
·537 words·3 mins
The technical essence, functionality, and evolution of blockchain is distributed databases. Specifically, it’s a Byzantine Fault Tolerant (resistant to malicious node attacks) distributed (leaderless replication) database.
Consistency: An Overloaded Term
·655 words·4 mins
The term “consistency” is heavily overloaded, representing different concepts in different contexts. For example, the C in ACID and the C in CAP actually refer to different concepts.