在 Hacker News Daily 上看到「MonolithFirst」這篇,是 Martin Fowler 在 2015 年寫的文章,對應在 Hacker News 上的討論「Monolith First (2015) (martinfowler.com)」也頗有趣的,可以一起翻。
tl;dr:他的文章就是在講新專案用 monolith,不要去碰 microservice。
文章開頭提到了就他觀察到的情況:第一點是,幾乎所有成功的 microservice 案例都是從 monolith 起頭,再轉到 microservice 環境;第二點是,幾乎所有一開始用 microservice 的案例,在後來都遇到嚴重的問題:
As I hear stories about teams using a microservices architecture, I've noticed a common pattern.
- Almost all the successful microservice stories have started with a monolith that got too big and was broken up
- Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. .
文章接著有兩個猜測,試著去解釋為什麼。
第一點可能的原因是 Yagni (You Aren't Gonna Need It),在試驗市場時 PoC 或是 MVP 的商業邏輯反而不會那麼複雜,快速用 monolith 開發驗證比起擁抱 microservice 來的重要太多,而且可以快速修改。
第二點分成兩個現象:第一個現象是,即使是對產品的商業領域很有經驗的資深架構師,也很難一開始就切出正確的 BoundedContext;第二個現象是,在 microservice 裡,改架構的難度比起 monolith 高非常多 (i.e. 跨 boundary 的 refactoring)。這兩個現象加在一起就會造成一開始導入 microservice 的專案失敗。
文章接著想要提出一些建議,在一開始使用 monolith 可以注意的方向,這些注意的事項可能可以讓之後轉成 microservice 變得比較輕鬆。
第一種方式是在 monolith 架構下注意 API boundary 與 data 的儲存方式,當想要切換到 microservice 的時候就有機會比較簡單。
第二種是更常見的方式,一開始先是 monolith 架構,然後把 boundary 好切割的拆成 microservice,所以在過度期會是一組不那麼大的 sub-monolith 架構,然後週邊圍繞著很多 microservice。這個做久了就有機會轉成全部都是 microservice。
第三種方式就是砍掉重練。
第四種方式是一開始的時候不用 monolith,而是幾個很大包的 service (所以一開始不太能叫 microservice),當商業模式成熟穩定後,切出更細緻的 boundary 的時候再拆成 microservice。
把這篇文章拿去搜尋 Hacker News 上的討論,可以看到除了 2021 年的這次討論外,在 2017 年的時候就有一批討論也蠻有趣的,可以看到有些不同的風向:「Monolith First (2015) (martinfowler.com)」。
當然也未必要信 Martin Fowler 的看法,軟體工程這塊還是有很多不同的流派...