For much of the past decade, microservices were treated as the default for modern software. Breaking applications into many small, independently deployed services promised faster releases, easier scaling, and more autonomous teams. Large technology companies popularized the model, and many others followed.
Many organizations have since discovered that those benefits come with significant costs. Some are now consolidating services into simpler designs, often a modular monolith. This article explains why the pendulum is swinging back, what simpler architectures offer, and how leaders can decide whether consolidation makes sense.
Why the Microservices Promise Fell Short for Many Teams
Microservices solve real problems for very large organizations with many independent teams. For smaller and mid-sized teams, they often introduce more complexity than they remove. Every service needs its own deployment pipeline, monitoring, security configuration, and on-call support. These costs grow with every new service, often faster than the benefits.
Communication between services also adds failure points. A single user action may depend on several network calls, each of which can be slow or fail, making debugging harder and outages more complex to diagnose. Some teams end up with a distributed monolith: services so tightly coupled that they cannot be deployed independently, combining the drawbacks of both approaches.
Costs can rise as well. In a widely discussed 2023 case, Amazon Prime Video’s video quality analysis team moved a distributed, serverless workflow into a single-process application and reported roughly 90% lower infrastructure costs (Viascom). Supporting tools for service discovery, tracing, and networking also add licensing and staffing costs.
What a Modular Monolith Offers
A modular monolith is a single deployable application organized into clearly separated modules, each responsible for a specific business area. Modules communicate through defined internal interfaces rather than network calls, but they are released together. Boundaries are enforced through code structure and review, so modules stay independent even though they share a deployment.
This approach keeps much of the structure that made microservices attractive while removing much of the operational overhead. Benefits include:
- Simpler operations: one deployment, one monitoring setup, and fewer moving parts to secure
- Easier debugging: requests can be traced within a single process instead of across many services
- Lower infrastructure costs: fewer network hops, containers, and supporting tools
- Faster onboarding: new developers can understand the system without learning a large service map
Large companies use this model too. Shopify, for example, runs one of the largest Ruby on Rails codebases as a modular monolith (Viascom). This shows that a well-structured monolith can scale with a large business.
Deciding Whether to Consolidate
Simpler is not automatically better. Microservices still make sense when parts of a system have very different scaling needs, require different technologies, or are owned by separate teams that must release independently. Some organizations adopt a hybrid approach, keeping a modular core while extracting a few services for specific needs.
Leaders considering consolidation can look for several warning signs. They include:
- Most releases require coordinated changes across several services
- A large share of engineering time goes to infrastructure rather than features
- Incidents frequently involve communication failures between services
- The number of services far exceeds the number of teams maintaining them
Consolidation should be gradual. Merging closely related services first, while keeping clear module boundaries, reduces risk and preserves the option to extract services again if needs change. Measuring deployment time, incident rates, and infrastructure costs before and after each step shows whether consolidation is delivering value.
Choosing Architecture That Fits the Business
The move toward simpler architectures is not a rejection of microservices but a correction of how widely they were applied. Matching architecture to team size, scaling needs, and operational capacity leads to systems that are easier to run and cheaper to maintain. Organizations reassessing their architecture benefit from working with an experienced software development team that can evaluate trade-offs objectively and plan a low-risk transition.