Microservices are often sold as the “modern” approach. But I’ve worked on both extremes: a monolith that was a joy to work with, and a microservice architecture that made simple changes take weeks.
Why Monoliths Are Underrated
- Simple local development run one service, not twelve
- Easy debugging stack traces stay in one process
- Transactional consistency is straightforward
- Fewer deployment moving parts
Why Microservices Exist
- Independent deployment teams can ship without coordinating every change
- Scaling heavy workloads can scale independently
- Fault isolation one service crashing doesn’t kill everything
- Different tech stacks use the best tool per domain (carefully)
The Costs People Ignore
- Distributed debugging logs, tracing, correlation IDs become mandatory
- Network reliability latency and partial failures are now part of your life
- Data consistency you trade ACID transactions for eventual consistency
- Operational overhead monitoring, service discovery, deployments
A Practical Migration Path
If you are starting a new product: start with a modular monolith. Design clean boundaries in code. Split into services only when a boundary becomes painful.
If you already have microservices and it’s chaos: consider consolidation. Fewer services with clearer ownership can improve velocity.
Architecture is about tradeoffs. The best architecture is the one that lets your team move fast without drowning in operational complexity.