Why 2023 Marks the Decline of Microservices: Lessons from Google, Amazon, and DHH

2023 appears to be the year of the microservices “reverse”. For a long time microservices were considered the de‑facto standard for cloud‑native service architectures, but this year major voices are questioning that assumption.

Google engineers, led by Michael Whittaker, published a paper titled “Towards Modern Development of Cloud Applications” in June, openly criticizing the current microservices model.

The paper argues that microservices blur logical and physical boundaries, mixing code‑level design with deployment concerns. In response, Google proposes a “Microservices 2.0” approach: build applications as logical wholes and let an automated runtime decide where workloads run.

This new architecture claims up to 15× lower latency and 9× lower cost. Google’s Kelsey Hightower emphasized that deployment should be treated as an implementation detail.

Google developers distilled three guiding principles:

Encourage developers to write single‑binary applications composed of logical components.

Defer physical distribution and execution challenges to the runtime.

Deploy applications atomically.

These principles aim to reduce complexity and open new avenues for innovation.

In the same month, Amazon’s Prime Video released a case study showing that abandoning serverless and microservices for a monolithic architecture cut operational costs by 90 % and simplified system complexity.

The Prime Video team needed a highly scalable video‑quality monitoring tool. Their initial solution used many distributed components orchestrated by AWS Step Functions and Lambda, but Step Functions hit account limits and became prohibitively expensive.

Switching to a monolith allowed them to rebuild the entire infrastructure, achieving dramatically lower cost and higher scalability.

Basecamp’s founder DHH (David Heinemeier Hansson) also publicly rejected cloud services and microservices, arguing that even Amazon sees microservices as “over‑hyped”.

Other companies have echoed similar sentiments: Uber found that a proliferation of tiny microservices created monitoring, testing, CI/CD, and SLA challenges; Managed by Q discovered that each new service added infrastructure overhead, eventually merging many services back into larger units.

These experiences highlight a growing “microservice fatigue” among teams of all sizes.

Google’s paper lists common microservice drawbacks:

Performance: Network serialization and remote calls can become bottlenecks.

Observability: Distributed interactions make bug tracing difficult.

Management: Independent release schedules lead to a proliferation of binaries and complex end‑to‑end testing.

API fragility: Changing an API can break dependent services, leading to API bloat.

These issues echo the “over‑design” problem.

Often, teams split a monolith into microservices without first establishing a clear domain model, resulting in tightly coupled services that are essentially a fragmented monolith.

Sam Newman, in *Building Microservices*, warns that architecture must meet certain preconditions; otherwise, it becomes over‑engineered.

Proponents of microservices argue they only make sense at a certain scale, but many internal applications incur higher development costs than runtime costs.

Google’s approach separates programming models from deployment models, allowing developers to focus on code while the runtime optimizes cost‑effective execution.

As the industry re‑examines cloud‑native assumptions, even cloud computing itself faces scrutiny. In 2023, companies like 37signals purchased physical Dell servers, rejecting cloud marketing hype, while FinOps tools such as KubeCost gain traction to control soaring cloud bills.

Edited by: 万能的大雄

Related reading:

Microservice Development 9 Best Practices

Microservices and Top 10 Framework Recommendations

Choosing Gateway Technologies Under Microservice Architecture