The Rise and Challenges of Microservices and Google’s Modular Monolith Approach

Microservices: Glory and Dilemmas

For the past decade microservices have become the de‑facto standard for cloud‑native applications, allowing large systems to be split into small, independently deployable services that promise flexibility, scalability, and maintainability.

Companies such as Uber and Netflix adopted microservices and initially saw improvements in reliability and developer velocity, but as they grew the architecture introduced new challenges: increased system complexity, difficulty tracing dependencies, and cascading latency issues.

Managed by Q experienced similar pain points; after two years of splitting a Django monolith into many services they began re‑consolidating services because each new service added infrastructure overhead and development friction.

These cases illustrate that microservices are not a one‑size‑fits‑all solution and can become a hindrance as organizations scale.

Google’s New Exploration: Towards a Modern Paradigm

In June, a team led by Google engineer Michael Whittaker published a paper titled “Towards Modern Development of Cloud Applications,” arguing that microservices conflate logical and physical boundaries.

Google proposes a "Microservices 2.0" approach that encourages developers to write applications as logical components while deferring physical deployment decisions to a runtime that can atomically deploy the whole program.

To enable this, Google introduced the Service Weaver framework, which lets developers write, test, and debug distributed applications locally and then deploy them with a single command.

Using this method, Google reported up to 15× latency reduction and 9× cost reduction.

Modular Monolith: The Unique Appeal of the New Architecture

Google calls this architecture a "modular monolith"—a hybrid that combines the code‑centralization of a monolith with the component‑level isolation of microservices.

Applications are built as a single logical unit but are divided into independent components with well‑defined interfaces, allowing separate development while avoiding inter‑service network overhead.

In an e‑commerce example, order, product, and user management can be separate components; updating one component does not affect others as long as the interface remains stable, and all components share a single codebase.

Service Weaver treats each component as a Go interface. Example code:

// Reverser component.
type Reverser interface {
    Reverse(context.Context, string) (string, error)
}

// Implementation of the Reverser component.
type reverser struct {
    weaver.Implements[Reverser]
}

func (r *reverser) Reverse(_ context.Context, s string) (string, error) {
    runes := []rune(s)
    n := len(runes)
    for i := 0; i < n/2; i++ {
        runes[i], runes[n-i-1] = runes[n-i-1], runes[i]
    }
    return string(runes), nil
}

Components are obtained via weaver.Get :

func main() {
    root := weaver.Init(context.Background())
    reverser, err := weaver.Get[Reverser](root)
    if err != nil { log.Fatal(err) }
    reversed, err := reverser.Reverse(context.Background(), "Hello, Weaver")
    if err != nil { /* handle error */ }
    fmt.Println(reversed)
}

This mirrors dependency‑injection patterns, providing clear decoupling and easier maintenance.

Microservices vs. Modular Monolith: Advantages and Limitations

Performance

Microservices suffer from network latency and serialization overhead, especially as the number of services grows.

The modular monolith eliminates most inter‑service network calls, achieving up to 15× latency reduction in Google’s experiments.

Development & Operations Complexity

Microservices increase the burden of managing multiple service lifecycles, interfaces, and deployments, raising both developer and ops costs.

The modular monolith simplifies development and ops by treating the application as a single deployable unit, reducing coordination overhead and enabling automated runtime resource allocation.

Cost

Running many independent services consumes more compute, memory, and networking resources, driving up expenses.

By consolidating components into a single logical deployment, the new architecture can cut resource waste and lower costs by up to 9×, according to Google’s measurements.

Industry Reaction and Outlook

Google’s work has sparked a re‑evaluation of microservices; other companies, such as Amazon Prime Video, have reverted from serverless/microservice stacks to monoliths, reporting up to 90% operational cost savings.

These cases show that architectural choices must be context‑specific, balancing business needs, team expertise, and ecosystem compatibility.

Adopting the modular monolith requires learning new tooling and may face integration challenges with existing microservice‑centric monitoring and governance solutions, but it offers a promising path toward more efficient, maintainable cloud applications.