Why Microservices Might Be the Biggest Architectural Mistake of the Last Decade

Warner’s Perspective on Microservices

GitHub former CTO Jason Warner tweeted that the biggest architectural mistake of the past decade is the blanket adoption of microservices. He recommends a progression: monolith → application → service → microservice, and stresses that this is a mindset, not a rule.

Warner defines a service as core infrastructure that supports applications and may be maintained by an infrastructure team, while a microservice is a small, often one‑off component of a few hundred lines, similar to a library or SDK.

Working on a large application as a whole is easier than reasoning about many microservices.

As an organization grows, managing dozens or hundreds of microservices becomes increasingly difficult.

Full micro‑service adoption introduces new concepts to handle “sprawl”.

Each custom service or microservice represents an extreme form of technical debt.

He also notes that at scale the challenges are often organizational rather than technical, such as infrastructure prioritization, ownership boundaries, tooling overhead, and increased production risk.

Practical Advice from Warner

Extend the life of monolithic applications as long as possible.

Build services from infrastructure, not from applications.

If breaking a monolith, break the large application first, not small services.

Treat each new application as a virtual wall for the company.

Prefer libraries over microservices whenever feasible.

GitHub’s Migration from Monolith to Microservices

GitHub started as a Ruby on Rails monolith. In 2021 it began migrating to a hybrid “monolith‑microservice” environment to enable more than half of developers to work productively outside the single codebase.

The migration began with modularizing the monolith, identifying feature boundaries, and grouping related database tables into “schema domains” recorded in YAML files. Partition keys were introduced to split data across servers and clusters.

Extraction followed a strict dependency direction: services could only depend outward from the monolith, never inward, to avoid creating a “distributed monolith”. Core services such as authentication and authorization were extracted first, using Twirp for service‑to‑service communication.

Subsequent migrations targeted low‑coupling features like webhooks and syntax highlighting, guided by change frequency and business value. GitHub also built a self‑service runtime platform to reduce operational overhead for new services.

Companies That Abandoned Microservices

Uber abandoned microservices for “macro‑services”, consolidating many small services into larger, team‑owned units to reduce complexity, monitoring, CI/CD, and SLA challenges.

Botify initially split its Django monolith into microservices but later re‑integrated authentication back into the monolith because the overhead outweighed the benefits for their data‑intensive SEO platform.

Conclusion

Microservices offer benefits but also introduce significant risks and operational costs. Warner’s advice encourages organizations to evaluate their own context and choose the architectural style—monolith, services, or microservices—that best aligns with their scale, team size, and business goals.

Reference links:

https://www.infoq.cn/article/zYGF4FpIVVt5U2omioUu

https://thenewstack.io/what-a-former-github-cto-learned-about-scaling/

https://www.infoq.cn/article/KSzctluch2ijbRbKYBgO

https://twitter.com/jasoncwarner/status/1592227285024636928