Monolithic 到 Microservice 的契機

契機總是突如其來，那你能不能一眼認出來？

說真的，我自己也不敢保證是能夠每次都抓得到，不過在這次我確實抓住推動微服務的機會。
而這個機會藏在大批同事離職後產生的真空期中。

在我完成 避免讓團隊肝壞去的的故事 的幾個月後，接著團隊就迎來了大規模離職潮，那時可說是士氣低迷，未來方向感混沌，看著一個個優秀的同事陸續離去，我動了離職的念頭。只不過當時的個人狀況讓我暫時還走不了，但是我也不想就當坐領乾薪的薪水小偷，於是開始約 1:1 跟各部門工程師聊天，在混亂中試圖想透過交流中找出不同的機會。

其中一次對話是和另外一個 engineer manager K，也是一位多年合作的好夥伴。他提到產品團隊希望重建客服系統，不過如果無法重新打造，恐怕得硬塞在原有系統上，那系統堪稱公司內惡名昭彰的維護夢魘。

我當下第一反應是拜託不要來亂，不過下一秒就有個截然不同的聲音冒出來。
等等，這不就是天上掉下來的好機會嗎？
我當時想的是引入 monorepo 來開發 micro service 的好時機。

提案#

於是我和 K 討論後，提案建議用 Monorepo 架構來開發這個客服系統。
這不只是單純在技術決策提供空間，更是我推動微服務的一大步。

在 框架升級不順的背後 專案尾聲時，我就已經累積了許多前置研究，像是如何進行服務拆分、微前端的共享策略、Monorepo 和 Polyrepo 的優劣比較，而這些理論與文獻固然重要，但沒有實作的背書終究是紙上談兵罷了。

過去公司以 Monolithic 架構為主，只要不能證明新方案有巨大收益，想要起案就是個難事。然而這次的客服系統屬於 support domain，再加上還沒有上線的服務就是還沒有翻船的可能，完全可以在壓力較小情況下測試 Monorepo 架構與微服務拆分策略。

所以從建立新 repo 開始，透過這個服務驗證 CICD 流程是否能順暢，觀察 Monorepo 是否能帶來比傳統 Monolithic 更清晰的開發體驗與擴展性。這不僅是在做架構建設，更是過去的研究落地的過程。

此外當然有一些在開案前就得扛上身的責任，例如這次 Monorepo 架構得平穩落地，不然下次再起恐怕就沒有繼續了。還有客服系統的需求不能在這套新架構下被充分滿足，下次哪個團隊還想要採用呢？

這些不只是技術問題，也牽動著當時的團隊士氣。而我希望這個專案不只是交付一個能用的系統，還要用它來證明架構轉型能實際提升效率，讓公司願意投資。

成果初現#

說來幸運，這個故事確實走得算順利。

身為 Project Owner，我負責確保 Monorepo 架構能夠支持服務開發的需求。當時與 K 一起拆解客服專案，除了提供系統設計的 review，也從中規劃 microservice 架構所需的基礎建設，並與交新成立的 platform teammates 一起實作。

為了讓這個架構更貼近實際產品需求，我在初期花費了一些時間參與 product team 的需求討論，藉此從中蒐集回饋，作為架構調整的依據。當然作為交換，我也協助客服系統專案的推進，確保它能走更好，畢竟客戶的成功就是我架構的成功 (笑

雖然這中間發現團隊可以進步的空間，因此開啟了一場兩年完成 60+ 場的 知識分享，也因此改變了我的團隊跟我自己，但這部分故事，我們留到下一篇再說。

在推動的過程之下，讓我們建立了很棒的團隊，能處理複雜的 CICD、設計 code convention 工具、架構 library 並開發應用。隨著第一個 client service 的第一階段順利交付，Monorepo 的開發流程就此正式確立，成為未來所有服務開發的根基，這樣的成果也讓公司看見投入 Monorepo 架構的實質價值，因此後續的其他服務也跟進與採用。

源頭跟結果#

在這場危機裡，因為原本看似限制的階段性不能離開工作，卻促使我找到原先想推進微服務的突破點。

而從 Monolithic 邁向 Micro service，不單純只是效率與擴展性提高，更代表著我的工程團隊可以面對更多挑戰的階段。在產品與流程層面累積的經驗，也實踐了軟體工程中我認為的原則——具有韌性能夠回應挑戰的基礎。

透過這個練兵機會讓同事們有機會在有趣的挑戰中成長，獲得能帶著走的技術厚度，是我沒說出口的重要交付。

而這一切只是起源於我不想當薪水小偷的初衷。
在這一次專案後，我也正式的掛上 Staff engineer 的職銜。

雖然我的問題開始轉變為，我夠格作為 Staff 嗎？