Last month, a team removed their microservices. The latency dropped from 800ms to 12ms.
No typo there - it simply means your data doesn't have to travel across the network to talk to another service.
The bill nobody warned you about
Microservices architecture was portrayed as a solution to all problems; limitless scalability, separate deployments, and teams that don't interfere with each other.
What they actually provided was a bill charging for leaving the platform.
Whenever Service A communicates with Service B, you are charged for that data transfer. AWS bills $0.09/GB for inter-regional data transfer.
The painful truth is what DHH highlighted, that AWS basically takes 40% off the top. This means they rob you of 40 cents from every dollar you give them, without any remorse. 💸
Amazon literally proved the point
Amazon put it out there.
The case study from the Prime Video Video Quality Analysis team was released in March 2023, but it went viral in May 2023. Their over-the-top serverless architecture using all AWS Step Functions and Lambda ran into a hard scaling wall when they reached 5% of their projected load.
Why, you ask? It's because their architecture was continuously reading and writing video frames to S3, over the network.
Therefore, they accomplished something that seemed impossible. They condensed it into a monolith and allowed the data to be processed in-memory instead of being transferred electronically.
The Outcome:
→ Infrastructure costs dropped over 90%
→ The scaling limit vanished
→ The "primitive" architecture won
If the cloud provider you use starts sharing a document on how to exit its platform, it's probably a good time to rethink your plans.
"But microservices scale!"
They do. Let me tell you about Shopify.
The main monolithic application contains 2.8 million lines of code and has seen over 500,000 commits. It processes 32 million requests per minute and executes 11 million MySQL queries per second on Black Friday.
I can't believe it, that's a monolith. It is not a distributed mesh made up of 47 services that are kept together by hope and YAML.
They maintain cleanliness using a tool called Packwerk which guarantees domain boundaries within the codebase. Who knew you could write clean code without sending every function call over a network.
For most of us, the scale argument was an excuse. The reality is you're not Netflix. Your side project doesn't need service discovery.
The real cost is your sprint
While money is an obvious form of tax, the sanity of your team is the hidden one.
I recently read a post by a developer who complained that their team spent 80% of their sprint capacity on a 14-microservice migration. And it wasn't spent on implementing new features. It was spent on writing YAML.
80% of engineering time is spent babysitting config and debugging why Service C can't talk to Service F.
This is the reality we tend to leave out of the architecture diagram. Introducing a new service boundary means there will be new points of failure, a new deployment pipeline to set up, and new logs to search through when troubleshooting in the middle of the night.
One well-designed service can manage the majority of workloads effectively. Introducing the distributed version only increases potential complexity and challenges.
Why we keep doing it anyway
To be honest, we're doing a lot of resume-driven development here.
Having "Migrated to microservices" on your LinkedIn profile may seem impressive. While "Kept the monolith simple and shipped features" doesn't sound as good, despite the fact that it's more challenging and more intelligent in many cases.
We tend to choose complicated solutions because we think it's the right way to progress, or it's what solid engineering looks like. However, half a year down the line you end up in a situation where you're spending 3.2 million dollars a year, questioning how you got there, just like 37signals did.
Instead of using the cloud, they decided to purchase $600,000 worth of Dell servers. They reduced costs to approximately $360k per year and estimated $10 million in savings over five years. They managed everything using an open-source tool called Kamal. 🚀
The takeaway
The monolith was victorious. Many teams have not confessed this yet, because doing so would also mean admitting that the last two years of migration work was largely for nothing.
Begin with a single service. Define boundaries in your code, not in your network. Consider microservices only if a single computer is truly insufficient for your load (95% of us can do a lot on one machine).
Can you imagine the tiniest, stupidest design that could still get your product out the door before the end of the quarter?
