從 IT 轉型看微服務
從電腦、資訊科技開始普及後，每過一段時間，企業界就會開始出現新的 IT 轉型計畫，以整頓整個資訊系統、商業運行模式，然後試圖找出下一個世代的新方向。每一個具規模的企業，都生怕與新世代的技術和商業模式脫鉤，於是砸重金、拚人力，說什麼也要追上世界的腳步。當然，中間的技術供應鏈也不斷在改變，上一世代的王者或是贏家，在下一個世代可能不一定跟得上，因此身為終端用戶的企業，每當面臨新的 IT 轉型計畫，往往也跟無頭蒼蠅般， 不知所措甚至不小心會做錯了決定。 回到十幾二十年前，你也許可以有機會一次性把一個大系統整個替換掉。但在今天資訊系統高度介入管理的時代，版本更迭無數次的平台，沒有一個系統能在一夕之間被整個換掉，哪怕你的品管和測試做得非常足夠，甚至是超標達成，也哪怕你事先的需求訪談談到祖宗十八代都瞭然於心。 這常常是系統設計者和規劃者的誤區，看見許多表面問題，於是設計了一套全新、看起來完美的解決方案。而剩下沒照顧到的部分，都覺得只要能配合測試就可以邊走邊補足。事實上，現代資訊系統的維度和複雜度，已經超出人類的想像，太多的例外、不可控、溝通執行問題，遠遠超過理論上的執行方法。 所以從系統規劃設計的角度來看，我們總是要慢慢來，一段段改善、替換，最終達成全面換血。而且越是龐大複雜且重要的系統，越要切割得越細，透過降維度的方法，來慢慢替換。所以我們在討論IT轉型，從一個肥大的系統換到另一個肥大的系統，已經不會是選項，系統架構的去耦合、高擴展性甚至是服務不中斷才是考量的重點。 這也是為什麼「微服務架構」在近年來特別熱門，微服務真正在討論的不是容器化，而是在討論的是怎麼讓一個龐大的系統，更容易受到管控、維護和擴充，除了可以更容易實現災難隔離、例外狀況、整體高可用性，也可以更有彈性做各種變化。 更重要的是，微服務架構下，其系統風險管理上，從在開發階段開始，每個部分就已經受到隔離和管控。也由於每個被拆解後的系統都非常小，遵循 SRP 原則，在開發維護上相對容易，也可以保證每個單元有更低的問題發生率。至少，你不會因為一顆螺絲或換一顆螺絲，導致整個塔倒塌。 不過微服務架構卻也不是說要做就能做，對於規劃設計者來說，他必須很了解各種新舊技術議題、有能力做實務執行面的評估，也需要耐心做各種服務拆解梳理和引入正確的 Pattern 及技術，甚至很多時候要有走一步是一步且可以快速反應...
