自從去年在〈有了 Agile,為什麼還要有 DevOps?〉及〈從限制理論看 DevOps〉兩場演講中,分別以 lean thinking 及 theory of constraints (TOC) 兩個角度探討 DevOps 之後,心中一直有個願望:想再從「系統思考」角度探討 DevOps。

畢竟,「系統思考」算是名門正派,「學習型組織」更是我從研究所時代就心嚮往之的目標呀。

翻開書架上那本,從研究所時代就買的《第五項修練》(第一版),讀著讀著,還是不甚有把握直接應用到 DevOps 場域上。畢竟系統思考的重要思維工具 CLD (causal loop diagram),比一般因果推理的思維工具,多了變量及時間滯延觀念,燒腦程度可是更甚於 TOC 的 CRT (current reality tree) 呀。

想法,就這麼擱著了。

直到今年初,接連聽了呂毅老師一場演講(在組織教練中看見系統性模式)及兩天課程(LeSS),被老師用 CLD 貫串全場的氣勢,以及推廣系統思考的熱情所感動,決定回到初衷,勇於接受挑戰。


於是,重拾《第五項修練》,重新咀嚼系統基模,研究如何以淺顯的方式解釋 CLD。我也嘗試搭配 LOOPY 這個有趣的軟體,降低 CLD 學習門檻。最後,從 DevOps 中挑選熱門的話題 microservices 作為箭靶,以增進實用性。萬事俱備,結果就是以下的演講。


DevOps Taiwan Meetup #8 (2017-10-26).
從系統思考看 DevOps:以 microservices 為例

台灣第一次舉辦的 DevOpsDays Taipei,涵蓋許多精彩的文化與技術議題。

大會中,許多講者不約而同提到「系統思考」的概念,這是什麼?許多講者也提到 microservices 的重要性,但為什麼許多人想導入,卻鍛羽而歸?

此演講以系統思考的 causal loop diagram 角度,探討 microservices 常見的導入誤區:意外的敵人 (accidental adversaries) 及捨本逐末 (shifting the burden) ,並根據系統基模角度提出對應的槓桿解。

希望你聽了之後,能夠初步掌握系統思考的切入點,也對於 microservices 導入,多了一分把握。

提醒:建議先複習一下 Andrew Wu 在【DevOps Taiwan Meetup #4 (2017/02/22) / 這一夜讓我們來聊聊 Microservices】的內容:


投影片:


實況錄影:


這場演講,開宗明義就說了:只探討「動態性複雜」,不探討「細節性複雜」。因此,刻意不著重在 microservices 技術細節。正好現場有兩位深富 microservices 實務經驗的高手,就順便 cue 他們幫忙回答技術提問。

感謝 andrew 幫忙回答資料儲存問題

交易處理是 RDBMS 強項,不過 RDBMS 先天就跟 microservices 不大搭,分散式的環境下要有別的處理方式。非交易的資料可透過 Message Queue 等等非同步的方式來達成最終的一致姓。如果範圍切割得夠小,也許你仍然可以在單一服務內繼續用 RDBMS 的交易控制。如果交易被迫得被分散在兩個服務之間,那麼分散式交易的機制就必須確實實作(例如 2 phase commit 之類的技巧)。

感謝 jini 幫忙回答 transaction 問題

但在金融交易時,若該 domain object 一定要在同一個 transaction context 時,那麼該服務就不該被切割。此外,有某些狀況也許可以切割,類似客戶與訂單的關係,這部份就可以用 async 加上 status 來處理,甚至有一個 batch 來 review 最終一致性。



最後,希望這種「系統思考」角度,對大家在導入 DevOps 的過程中,有些許幫助。更進一步,朝向學習型組織邁進。

演講最後推薦的幾本書,別忘了要去看喔!