Tech

The Great Microservices Retreat Is Really a Lesson About Borrowed Taste

June 21, 2026 · Paul Graham, Hackers & Painters~5 min read

A decade ago, splitting your app into dozens of microservices was the unmistakable mark of a serious engineering team. In 2026 the same teams are quietly stitching them back together. The CNCF's 2025 survey found 42% of organizations consolidating microservices into larger units; service-mesh adoption — the elaborate plumbing those architectures demanded — fell from 18% to 8% in two years, more than halved. The interesting question isn't whether microservices were good or bad. It's how an entire industry adopted a heavy default without anyone deciding it was right for them, and what that says about where your own technical choices actually come from.

How a default becomes invisible

Nobody sold most of those teams on microservices with a cost-benefit analysis of their specific system. The architecture arrived the way fashions do: the companies you admired ran it, the conference talks assumed it, the job posts listed it, and at some point "we'll break this into services" stopped being a decision and became the air. That is the precise mechanism Paul Graham warns about in Hackers & Painters. He calls it the Blub paradox: you reach for whatever the people around you reach for, and because it's all you can see, it stops looking like a choice at all. The trap isn't picking a bad tool. It's that you never experienced yourself picking.

Why "what everyone uses" quietly costs you

Graham's sharper point is about the price. Following the herd doesn't make you wrong so much as it makes you average, and average is a strange thing to aim for on purpose. Every service boundary you didn't need bought you a network call that can fail, a deployment pipeline to babysit, an observability bill, a 3 a.m. page when a call times out between two services that used to be one function. None of it was malice. It was the slow tax of running infrastructure sized for Google on a system that serves a few thousand users. The teams now consolidating aren't admitting microservices are bad. They're discovering, the expensive way, that they were paying for a problem they never had — and that "this is how it's done" was carrying weight a real argument should have carried.

A heavy default arrives like fashion and gets adopted before anyone decides it fits — Paul Graham's Blub paradox. It carries a hidden tax: failed calls, pipelines, a soaring bill. The CNCF 2025 survey found 42% of teams consolidating to a modular monolith; service-mesh adoption fell 18% → 8% in two years. Framework: Paul Graham, Hackers & Painters. A reflection on technical decision-making.

The modular monolith isn't a U-turn

What the consolidators are landing on isn't 2010's big ball of mud. It's the modular monolith: one deployable unit, but partitioned inside into clean modules with hard boundaries. You keep the thing that was actually valuable about the microservices era — disciplined separation of concerns — and drop the thing that was incidental: shipping each concern as its own networked process. Read through Graham, that's not a retreat at all. It's a team finally choosing the tool that fits the job instead of the tool that fits the résumé. The boundary you draw in your code is a design decision; the boundary you draw across the network is also an operations bill, and conflating the two is how a fashion disguised itself as an architecture.

The mistake repeats with whatever's hot now

It would be comfortable to file this under microservices and move on, except the pattern doesn't care about the year. Today the unexamined default isn't a service mesh; it's wiring an LLM agent into a workflow that a hundred lines of plain code would handle, because agents are what serious teams are doing this quarter. The shape is identical: a heavy, fashionable solution adopted before anyone asked whether the problem was heavy. Graham's warning ages well precisely because it isn't about microservices or monoliths or agents. It's about the difference between choosing a tool and inheriting one, and noticing which one you just did.

What this means for you

So before the next "best practice" becomes your air, run Graham's quiet test on it. Ask what specific problem in your system this default solves, and make yourself answer in concrete terms — not "scalability," but which component, failing how, at what load you have actually seen. If the honest answer is "it's what good teams use," you haven't found a reason; you've found a fashion wearing the costume of one. Sometimes the herd is right and the heavy tool fits. But you only get to know that by deciding for yourself, which is the one move borrowed taste can never make for you. The 42% walking it back didn't lack skill. They had simply never priced the default — and the bill came due all the same.

Copying the tool everyone uses doesn't make you wrong. It makes you average — and the cost of running infrastructure you never needed comes due whether or not anyone ever decided to take it on.

The retreat isn't an admission microservices failed. It's a team finally pricing a default it had been paying for blind.

Source: framework from Paul Graham, Hackers & Painters (the Blub paradox; "use what everyone uses" trades distinctiveness for averageness). Real-world basis: the CNCF 2025 Annual Survey, which found 42% of organizations consolidating microservices into larger deployable units and service-mesh adoption falling from 18% to 8% over two years, amid the 2026 modular-monolith discussion. A reflection on technical decision-making, not architecture advice for any specific system.

技术

这场微服务大撤退，其实是一堂关于「借来的品味」的课

2026 年 6 月 21 日 · 保罗·格雷厄姆《黑客与画家》约 5 分钟

十年前，把应用拆成几十个微服务，是一支正经工程团队最醒目的徽章。到了 2026 年，同一批团队正悄悄把它们又缝回去。CNCF 的 2025 年度调查发现，42% 的组织正在把微服务合并回更大的部署单元；服务网格——这种架构所要求的那套繁复管道——的采用率两年间从 18% 跌到 8%，砍掉了一半多。有意思的问题不是微服务到底好不好。而是：一个完整的行业，怎么会在没人真正判断它适不适合自己的情况下，集体采纳了这么重的默认选项——以及这件事，透露出你自己的技术选择究竟从哪儿来。

一个默认选项是怎么变得看不见的

当年没人拿着「针对你这套系统的成本收益分析」去说服那些团队上微服务。这套架构像时尚一样降临：你仰慕的公司在用，技术大会默认你懂，招聘启事列着它，到某个时点，「我们会把它拆成服务」就不再是一个决定，而成了空气。这正是保罗·格雷厄姆在《黑客与画家》里警告的那套机理。他称之为 Blub 困境：你伸手去拿的，永远是周围人在拿的那个，而正因为你只看得见它，它就彻底不再像一个选择。陷阱不在于挑了个坏工具，而在于你从没体验过「自己在挑」这件事。

为什么「大家都在用」会悄悄让你付钱

格雷厄姆更锋利的一点，是关于代价。随大流不会让你错，只会让你变得平常——而「故意瞄准平常」本身就是件怪事。每一道你本不需要的服务边界，都给你换来了一次可能失败的网络调用、一条要看顾的部署流水线、一份可观测性账单，以及凌晨三点的一次告警——只因为两个本是同一个函数的服务之间，某次调用超时了。这一切都不是谁存心使坏。它是把为 Google 量身的基础设施，硬套在一个只服务几千用户的系统上，所要缴的那笔慢性税。如今在做合并的团队，不是承认微服务不好。他们是用昂贵的方式发现：自己一直在为一个根本不存在的问题付费——而「这就是业界的做法」，扛起了一个本该由真实论证来扛的分量。

一个重型默认选项像时尚一样降临，没人判断它是否合用就被采纳——这是格雷厄姆的 Blub 困境。它带着一笔隐藏的税：失败的调用、流水线、飙升的账单。CNCF 2025 年度调查发现 42% 的团队正合并回模块化单体；服务网格采用率两年间从 18% 跌到 8%。框架：保罗·格雷厄姆《黑客与画家》。本文为对技术决策的思考。

模块化单体不是掉头往回开

这些做合并的团队，落脚的并不是 2010 年那坨「大泥球」。而是模块化单体：一个可部署单元，内部却被划成边界清晰的模块。你留下了微服务时代真正有价值的那部分——有纪律的关注点分离——丢掉的是顺带捎来的那部分：把每个关注点都做成一个独立的网络进程发出去。照格雷厄姆的眼光看，这根本不是撤退。这是一支团队终于在挑「合手头活儿的工具」，而不是「合简历的工具」。你在代码里划的边界，是一个设计决定；你跨着网络划的边界，同时还是一张运维账单——把这两者混为一谈，正是一种时尚把自己伪装成架构的方式。

同一个错，会换成此刻最热的那样东西重演

把这件事归档到「微服务」名下、然后翻篇，会很省心，只是这套套路根本不在乎年份。今天那个没被审视的默认选项，已经不是服务网格了；而是把一个 LLM 智能体接进一段一百行普通代码就能搞定的流程里——只因为这个季度，正经团队都在搞智能体。形状一模一样：一个又重又时髦的方案，在任何人追问「这问题真有那么重吗」之前，就被采纳了。格雷厄姆的警告之所以经得起放久，恰恰因为它讲的不是微服务、不是单体、也不是智能体。它讲的是「自己挑一个工具」和「继承一个工具」之间的分别——以及，看清你刚才做的究竟是哪一种。

这对你意味着什么

所以，趁下一个「最佳实践」还没变成你的空气，先拿格雷厄姆那道安静的测试题考考它。问问：这个默认选项，到底解决了你这套系统里哪个具体问题，并逼自己用具体的话回答——不是「可扩展性」，而是哪个组件、以何种方式失败、在你真正见过的多大负载下。要是诚实的答案是「这是好团队都在用的」，那你找到的不是理由，是一个穿着理由戏服的时尚。有时候大流是对的，重工具也确实合手。但你只有靠自己决定，才能知道这一点——而这一步，借来的品味永远没法替你走。那 42% 把路走回来的团队，缺的不是本事。他们只是从没给这个默认选项标过价——而账单，照样到期了。

抄一个大家都在用的工具，不会让你错。它让你变平常——而运行一套你本不需要的基础设施所要缴的费，无论有没有人真正决定接下它，都照样会到期。

这场撤退不是承认微服务失败了。是一支团队终于给一个它盲付了多年的默认选项，标了价。

来源：框架取自保罗·格雷厄姆《黑客与画家》（Blub 困境；「用大家都在用的」是拿独特性换平常）。现实依据：CNCF 2025 年度调查发现 42% 的组织正把微服务合并回更大的部署单元、服务网格采用率两年间从 18% 跌到 8%，正值 2026 年模块化单体的讨论。本文为对技术决策的思考，非针对任何具体系统的架构建议。

テクノロジー

このマイクロサービスの大撤退は、実は「借り物の趣味」についての授業だ

2026年6月21日 · ポール・グレアム『ハッカーと画家』約 7 分

十年前、アプリを何十ものマイクロサービスに割ることは、まじめな技術チームの紛れもない勲章だった。2026年、その同じチームが、静かにそれらを縫い直している。CNCF の2025年調査によれば、42% の組織がマイクロサービスをより大きな単位へ統合しつつある。そのアーキテクチャが要求した手の込んだ配管——サービスメッシュの採用率は、二年で18%から8%へ、半分以上に落ちた。面白い問いは、マイクロサービスが良かったか悪かったかではない。一つの業界まるごとが、誰も自分に合うと判断しないまま、これほど重い既定値を集団で採り入れたのはなぜか——そしてそれが、君自身の技術的選択がどこから来るのかについて、何を語るかだ。

既定値はどうやって見えなくなるか

あのチームの多くは、「君のこの系に対する費用便益分析」を突きつけられてマイクロサービスを選んだわけではない。そのアーキテクチャは、流行のように降ってきた。憧れた会社が走らせ、カンファレンスの講演は前提とし、求人票は並べ、ある時点で「これをサービスに割る」は決定ではなくなり、空気になった。これこそ、ポール・グレアムが『ハッカーと画家』で警告する仕組みだ。彼はそれを Blub のパラドックスと呼ぶ。君が手を伸ばすのは、いつも周りの人が手を伸ばすそれであり、それしか見えないからこそ、もはや選択にすら見えなくなる。罠は、悪い道具を選ぶことではない。「自分が選んでいる」という経験を、一度もしないことだ。

なぜ「みんなが使っているもの」が静かに君に払わせるのか

グレアムのより鋭い論点は、代価についてだ。群れに従っても、君は間違うのではない。ただ平凡になる——そして「わざわざ平凡を狙う」のは、考えてみれば奇妙なことだ。本来要らなかったサービス境界の一つひとつが、失敗しうるネットワーク呼び出しを、世話の要るデプロイパイプラインを、可観測性の請求書を、そしてかつて一つの関数だった二つのサービスの間で呼び出しがタイムアウトしたという理由だけの、午前三時の呼び出しを、君に引き換えた。どれも悪意ではない。Google 向けに仕立てた基盤を、数千人にしか奉仕しない系へ無理に被せて払う、慢性の税だ。いま統合しているチームは、マイクロサービスが悪いと認めているのではない。高くつくやり方で気づきつつある——ありもしない問題に、ずっと支払っていたと。そして「これが業界のやり方だ」が、本来は真の論証が担うべき重みを担っていた、と。

重い既定値が流行のように降ってきて、合うかを誰も判断しないまま採られる——グレアムの Blub のパラドックスだ。それは隠れた税を負う：失敗する呼び出し、パイプライン、急騰する請求。CNCF 2025年調査では 42% のチームがモジュラーモノリスへ統合中。サービスメッシュ採用率は二年で 18% → 8% へ落ちた。枠組：ポール・グレアム『ハッカーと画家』。本稿は技術的意思決定についての考察。

モジュラーモノリスは、Uターンではない

統合するチームが行き着く先は、2010年の「大きな泥団子」ではない。モジュラーモノリスだ。一つのデプロイ単位、だが内部は境界の明確なモジュールへ分けられている。マイクロサービス時代に本当に価値があった部分——規律ある関心の分離——は残し、付随的だった部分は捨てる。つまり、各々の関心を独立したネットワークプロセスとして送り出すこと。グレアムの目で読めば、これは撤退ですらない。一つのチームが、ようやく「履歴書に合う道具」ではなく「手元の仕事に合う道具」を選んでいるのだ。コードのなかに引く境界は設計の決定だ。ネットワークをまたいで引く境界は、同時に運用の請求書でもある——この二つを混同することこそ、流行がアーキテクチャに化けるやり口だった。

同じ過ちは、いま一番熱いもので繰り返される

これを「マイクロサービス」の項に綴じてページをめくれば気は楽だ。ただ、この型は年など気にしない。今日、吟味されていない既定値はサービスメッシュではない。百行の素朴なコードで片づく流れに、LLM エージェントを配線することだ——なぜなら今四半期、まじめなチームがやっているのがエージェントだから。形はそっくりだ。重く流行りの解が、「その問題は本当に重いのか」と誰かが問う前に採られる。グレアムの警告が古びないのは、まさにそれがマイクロサービスやモノリスやエージェントについての話ではないからだ。それは、道具を「自分で選ぶ」のと「受け継ぐ」のとの違いについての話であり——君がたった今やったのはどちらか、それに気づくことについての話だ。

これは君にとって何を意味するか

だから次の「ベストプラクティス」が君の空気になる前に、グレアムの静かなテストにかけてみよう。問え——この既定値は、君のこの系のどの具体的な問題を解くのか。そして自分に、具体的な言葉で答えさせよ。「スケーラビリティ」ではなく、どの部品が、どう壊れ、君が実際に見たどれだけの負荷で、と。もし正直な答えが「良いチームが使っているから」なら、君が見つけたのは理由ではない。理由の衣装をまとった流行だ。時には群れが正しく、重い道具が手に合うこともある。だがそれを知れるのは、自分で決めることによってのみだ——そしてその一手こそ、借り物の趣味が君の代わりに決して打てないものだ。引き返した42% に、腕がなかったのではない。彼らはただ、既定値に値札をつけたことが一度もなかった——それでも請求は、変わらず満期を迎えた。

みんなが使う道具を真似ても、君は間違わない。ただ平凡になる——そして要りもしなかった基盤を走らせる費用は、誰かがそれを引き受けると決めたかどうかに関わらず、満期を迎える。

この撤退は、マイクロサービスが失敗したという告白ではない。一つのチームが、盲目のまま何年も払ってきた既定値に、ようやく値札をつけたのだ。

出典：枠組はポール・グレアム『ハッカーと画家』より（Blub のパラドックス。「みんなが使っているものを使う」は、独自性を平凡さと引き換える）。現実の根拠：CNCF 2025年調査は、42% の組織がマイクロサービスをより大きなデプロイ単位へ統合し、サービスメッシュの採用率が二年で18%から8%へ落ちたと示した。2026年のモジュラーモノリス議論のさなかである。本稿は技術的意思決定についての考察であり、特定の系への設計助言ではない。