技術架構閒聊:防腐層
新年快樂!今年開始,在原本的技術管理以外,規劃了新的系列:技術架構閒聊。身為技術管理者,除了管理以外,也常常需要在技術架構的方面下決策,因此我也想另外開闢這個專欄來和大家一起討論。
設想一個情境:當團隊需要將一個單體的舊系統遷移到新的架構(可能是單體、也可能是微服務)時,雖然商業邏輯沒有改變,但系統的 API 、資料結構與行為可能因為原本的設計不佳,或是其他的因素,需要作調整。這時通常有幾個作法:
新系統向後相容,支援舊的呼叫模式
將所有的功能全部改寫好,資料轉移完成後,找個良辰吉日切換到新系統
將舊系統切成小模組,陸續進行轉移
(1) 的問題是可能會把技術債帶到新系統去(例如語意複雜不簡潔等)。而如果有真實執行過 (2) 的讀者,應該知道它是一個風險很高,失敗率極大,一不小心可能還會上新聞1的事情。無論站在商業面或風險考慮,採取 (3) 才會是比較合理的答案。
但陸續進行轉移,代表的就是會有一個新、舊系統並存,系統間會需要互相存取資料的狀態。這時我們可能會想,在中間如果有一個中間層,幫我們做好新舊系統間翻譯的工作,把兩邊系統的修改工作量降低,到時候轉移完就可以把這個中間層捨棄掉,也就是所謂的「防腐層」:不讓舊系統的技術債影響到新系統。
有得必有失。防腐層會有一些副作用,如:
需要針對防腐層設計監控的指標,如 API Call Failure Rate 等
防腐層會增加一些延遲
若服務有快取機制,要特別注意新舊系統的資料一致性,避免出錯
在全部遷移到新系統前,需要管理並維護防腐層。
我的經驗是,防腐層除了在服務遷移的時候是很好用的以外,在管理技術目標不同的團隊(如內部核心開發團隊與新產品開發團隊,兩者的商業目標並不一致),中間需要互相溝通時,設立防腐層可以降低對內部系統穩定度的影響,讓團隊可以更安心的往目標前進。
接下來,固定每週一會推出一篇文章,如果你對技術管理也有興趣,歡迎按下面的按鈕來訂閱電子報喔!
如果你有興趣跟我聊聊關於技術管理,也歡迎到 calendly 跟我約個時間聊聊!