從 IT 轉型看微服務

從電腦、資訊科技開始普及後，每過一段時間，企業界就會開始出現新的 IT 轉型計畫，以整頓整個資訊系統、商業運行模式，然後試圖找出下一個世代的新方向。每一個具規模的企業，都生怕與新世代的技術和商業模式脫鉤，於是砸重金、拚人力，說什麼也要追上世界的腳步。當然，中間的技術供應鏈也不斷在改變，上一世代的王者或是贏家，在下一個世代可能不一定跟得上，因此身為終端用戶的企業，每當面臨新的 IT 轉型計畫，往往也跟無頭蒼蠅般， 不知所措甚至不小心會做錯了決定。

回到十幾二十年前，你也許可以有機會一次性把一個大系統整個替換掉。但在今天資訊系統高度介入管理的時代，版本更迭無數次的平台，沒有一個系統能在一夕之間被整個換掉，哪怕你的品管和測試做得非常足夠，甚至是超標達成，也哪怕你事先的需求訪談談到祖宗十八代都瞭然於心。

這常常是系統設計者和規劃者的誤區，看見許多表面問題，於是設計了一套全新、看起來完美的解決方案。而剩下沒照顧到的部分，都覺得只要能配合測試就可以邊走邊補足。事實上，現代資訊系統的維度和複雜度，已經超出人類的想像，太多的例外、不可控、溝通執行問題，遠遠超過理論上的執行方法。

所以從系統規劃設計的角度來看，我們總是要慢慢來，一段段改善、替換，最終達成全面換血。而且越是龐大複雜且重要的系統，越要切割得越細，透過降維度的方法，來慢慢替換。所以我們在討論IT轉型，從一個肥大的系統換到另一個肥大的系統，已經不會是選項，系統架構的去耦合、高擴展性甚至是服務不中斷才是考量的重點。

這也是為什麼「微服務架構」在近年來特別熱門，微服務真正在討論的不是容器化，而是在討論的是怎麼讓一個龐大的系統，更容易受到管控、維護和擴充，除了可以更容易實現災難隔離、例外狀況、整體高可用性，也可以更有彈性做各種變化。

更重要的是，微服務架構下，其系統風險管理上，從在開發階段開始，每個部分就已經受到隔離和管控。也由於每個被拆解後的系統都非常小，遵循 SRP 原則，在開發維護上相對容易，也可以保證每個單元有更低的問題發生率。至少，你不會因為一顆螺絲或換一顆螺絲，導致整個塔倒塌。

不過微服務架構卻也不是說要做就能做，對於規劃設計者來說，他必須很了解各種新舊技術議題、有能力做實務執行面的評估，也需要耐心做各種服務拆解梳理和引入正確的 Pattern 及技術，甚至很多時候要有走一步是一步且可以快速反應決策的能力。這些都不是隨便讓工程師去上個 DDD（Domain-driven Design）或是各種微服務設計課程，回來就能掌握的技能。

以目前業界情況來說，由於微服務帶來的衝擊範疇，涉及了系統設計、開發管理甚至是業務規劃，將橫跨基礎設施（Infrastructure）、應用開發（Application Development）到終端使用者（End-user）的負責團隊。由於要相互配合的人太多，以致導入會是一個長期計劃，所以對於多數有意導入微服務的企業而言，到目前為止，最多也只能做到容器化而已。畢竟，微服務架構說白了，就是去中心化的分散式架構，這對傳統的系統整合設計人員、開發人員來說，都是相對陌生的領域。

真正要能普及微服務，必須等到從企業內部到外部廠商，都能充分理解和懂得微服務架構方法，才能真正的落實，而這段路才剛開始而已。

對了，別忘了微服務後，下一段還有邊緣運算（Edge Computing）等著大家。