You Want Microservices, but Do You Need Them?

Amazon’s big app saved big money—devs ask if tiny pieces were just tech FOMO

TLDR: Amazon’s Prime Video cut costs by 90% by bundling its app back into one big piece, sparking a backlash against the “tiny pieces” trend. Commenters mocked microservice mania, pitching WebAssembly modules, “macro-services,” and database hygiene while the mood shifted to one blunt question: do you actually need microservices?

Amazon, the company that sells cloud tools for slicing apps into tiny parts, quietly admitted a plot twist: Prime Video went back to one big app and slashed costs by 90%. Then the blog post vanished—but the internet archived it, and the comments lit up. The mood? Shocked delight with a side of “we told you so.”

Microservices—splitting software into many mini-apps—once felt like the cool kid solution. But the crowd here is done worshipping the tiny. Eternityforest says forget microservices, give us self-contained WebAssembly modules (little plug-in parts that run fast and safely). Cyberax goes bigger with “macro-services,” craving simple, built-in login/auth tools and one-click local spin-up with Docker instead of wrestling with Kubernetes (the complex manager for many mini-apps). Honkycat doesn’t want the chaos to return, though: keep the database hygiene—no more giant shared tables turning into spaghetti.

Then the spice hits: Dzonga calls microservices a product of the ZIRP era (the cheap money years), roasting banks that bragged about “three microservices per engineer.” Old-school three-tier apps (web, logic, database) are getting an unlikely glow-up. Callamdelaney’s deadpan “Usually no” became the thread’s catchphrase.

There’s nuance: at Netflix scale, tiny parts make sense. But for most teams, commenters say microservices added network drama, version hell, and resume-polishing buzzwords. The vibe has flipped from “split everything” to “do you actually need it?” and it’s intensely entertaining.

Key Points

  • The article reports Amazon Prime Video cut costs by about 90% in May 2023 by moving from microservices to a monolithic architecture.
  • Microservices offer independent deployability, autonomous teams, polyglot stacks, and targeted scaling, but introduce significant operational complexity.
  • Running many services requires versioning, schema evolution, distributed transactions, tracing, centralized logging, and mature CI/CD.
  • Microservices are best suited for distinct business capabilities with different scaling and deployment needs (e.g., payments vs recommendations).
  • Successful microservices adoption depends on alignment with team structure (Conway’s Law) and prerequisites like service ownership, robust monitoring, and sufficient scale.

Hottest takes

"I don't want microservices... I want self contained WebAssembly modules!" — eternityforest
"microservices were an effect of the ZIRP era... 3 microservices for each engineer" — dzonga
"What I want is a lightweight infrastructure for macro-services" — cyberax
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.