Building Evolutionary Architectures : Support Constant Change 心得歸納7
後面都是書中整理的建議方式(方向)
組織因素
- 軟體架構影響一般與軟體無關的各種因素,包括團隊、預算編制和許多其他因素
跨職能團隊
- 根據領域組成的團隊往往是跨職能的,目標是消除運維摩擦
- 團隊會有設計、實作、部署服務等工作所需的每一種角色
- 但為了適應新結構,需要調整以下角色
- 1.商業分析師:協調服務與其他服務目標(包含其他服務團隊)
- 2.架構師:設計架構,移除讓漸進變更難以實施的不良耦合
- 3.測試:測試人員必須可以應付跨領域整合測試的挑戰
- 4.運維:將DevOps工作(例如機器配置和部署)自動化是成功的關鍵因素
- 5.資料:資料庫管理員必須處理新的粒度、交易和記錄問題系統
- 消除協調摩擦是跨職能團隊的目標之一
- 雖然為每一個專案的每一個角色安排適任的工程師是很華麗的計畫,但大多數公司受限於資源而無法實現
- 將DevOps自動化來發現新資源,例如使用Puppet來自動地供應新機器,即有足夠的人員管理自動化的基礎設施
圍繞著商業功能的組織
- 圍繞特定領域建立團隊意味著圍繞商業能力建立團隊
- 傳統上架構師工作圍繞著純技術架構,由於費用問題,過去十年許多架構風格重點是將共享資源最大化
- 大多數組織已廣泛地使用開放原始碼軟體,架構師才能脫離上述商業限制,從技術架構轉移到以領域為中心的架構,進而更好地配合常見的變更單元
- i.e.應根據商業能力建構團隊,而不是工作功能
產品先於專案
- 許多公司都會圍繞產品建立模型,而不是圍繞著專案
- 軟體專案的工作流程,當組織發現問題時會成立一個開發團隊,處理那個問題直到"完成"
- 接著將軟體移交給運維部門,專案團隊則繼續處理下一個問題
- 通常bug修復和其他維護工作變得難以管理
- 因為開發人員與運維人員面向是分開的,他們不太關心如品質一類的問題
- 導致運維silo間的"我們"vs"他們",這也是許多組織鼓勵員工在衝突中生存
- 將軟體視為一種產品可以改變公司三個觀點
- 1.產品是長生的,這與專案的生命週期不同
- 2.產品設立擁有者,負責提倡在生態系統中使用它,並管理需求之類
- 3.跨職能的團隊,它有產品需要的角色(商業分析師、開發、QA、DBA、運維等)
- 在心態上從專案轉變成產品的目的與公司長期目標有關
- 產品團隊需要負責確保產品的長期品質
- 開發人員須注意品質指標,並更加關注缺陷,提供團隊長期遠景
- 後面也有提到Amazon的"Two Pizza" Teams
- 亦即團隊規模不能超過兩份大披薩可以餵飽的人數,其動機主要為了溝通
團隊成員之間的聯繫
- 許多公司發現大型開發團隊的表現不太理想,著名團隊動力學專家J. Richard Hackman給出解釋:關鍵不在於人數,而在於他們必須保持多少聯繫(越多越爛)
- 努力讓開發團隊之間維持少量的聯繫
團隊耦合特性 — 文化
- 大多數架構師都不知道團隊結構如何影響架構的耦合特性,但它有很大影響
- 架構師必須關心工程師如何建立系統
- 稱職的架構師能夠承擔領導人的角色,建立技術文化和設計方法
- 例如透過以下問題了解團隊文化:
- 1.團隊每個人都知道什麼是適應度函數,並且能思考新工具或產品對新的適應度函數的演進能力有什麼影響嗎?
- 2.團隊有沒有在評量他們的系統是否滿足他們定義的適應度函數
- 3.工程師理解內聚合耦合嗎?
- 4.成員會部會討論哪些領域及技術概念是互屬的?
- 5.團隊是否根據解決方案的變更能力選擇它們,而不是根據它們想要學習那些技術(金融業都是由沒有技術概念高層決定的,像是某家提供如贈品般的平台系統,高層就會決定使用,並督促技術團隊管理者採納,最近又遇到一樣的事)
- 6.團隊如何回應商業的變更?他們究竟是難以進行小規模的變更,還是在小型的商業變化上花太多時間?(金融業過往經驗常見就是總經理交辦當週上線等)
- 如果團隊不習慣變更,則架構師可以加入一些實踐方法如...
- 工程師於程式庫或框架之外可否輕鬆地編寫測試程式碼?
- 或著新的程式庫和框架是否需要額外的執行環境設置,造成簡慢開發週期?
- 除了選擇新的程式庫或框架外,程式碼複審是評估更改的程式是否良好地支援未來變更的好方法
- 當然開發者也必須防範過度設計,過早為變更加入額外的複雜性或抽象
團隊耦合性 — 實驗的文化
- 成功的實驗,就是定期採取小規模的行動已嘗試新想法(從技術和產品的角度),並將成功的實驗整合到既有系統中
- 組織可以用多種方式鼓勵實驗:
- 1.採取外部的想法(如聘請外部專家或顧問,或派員工參加外部會議等)
- 2.鼓勵明確地改進
- 3.spike與穩定(即讓團隊製作拋棄式的解決方案,但它是為學習而建立的,不是精心設計的解決方案)
- 4.建立創新時間(例如Google就有20%時間可以進行任何專案)
- 5.採取set-based開發(即探索多種方法上,當評估幾個互相競爭的解決方案後,通常可以發現一種比較穩健的解決方案)
- 6.創造工程師與最終用戶之間的聯結(團隊和產品人員可以直接看到決策如何影響最終用戶)
財務長和預算編列
- 演進式架構必須用部段變化的優先順序來反映企業的許多傳統職能如編列預算
- (如我之前看這本書想到的過去考量系統核心轉換的廠商來展示他們預期的系統架構的時候,當系統架構圖一攤開來時,是不是就已經沒救了,因為它們是以當時最熱們的系統或框架為基礎給的藍圖,這也方便編列預算,或是給高層展示,但是可能一兩年後那架構就已經不行了,更何況金融業的核心轉換都是五年以上的事!)
- 動態均衡這種基本特性已經讓人難以預測未來了!
建構企業適應度函數
- 在演進式架構中,企業架構師的職責是進行指導,以及建構企業範圍的適應度函數
- 將不斷變化的模型反映到微服務架構上
- 由於這種架構的每一種服務在運為上都與其他服務解偶,因此共享資源是不需要考慮的因素
- 架構師應該指導耦合點(例如服務模板)和平台選擇
- (但是如上,金融業通常是無技術的高層決定平台選擇,通常是別人買甚麼就跟著買)
你該從哪裡開始? — 低垂的果實
- 如果組織需要取得初期的勝利來證明方法可行,架構師可以用最簡單的問題來展示演進式架構
- 要選擇充分解偶的部分
- "最簡單優先"方法用少量的代價來將風險控制在可承受的範圍
你該從哪裡開始? — 最高價值
- 另一種做法是"最高價值優先" — 找到系統最關鍵部分,然後圍繞著它建構演進行為
你該從哪裡開始? — 測試
- 開發人員通常無法接受專案工作只是在基礎程式中加入測試機制,管理階層也會對這項舉動抱持懷疑態度
- 測試是演進式架構的漸進變更層面的關鍵元素,適應度函數更是積極運用測試
你該從哪裡開始? — 基礎設施
- 在能力提升速度緩慢的公司中,運維團隊通常是缺乏創新的犧牲品
- 例如有些公司將運為工作外包給另一家公司
- 運維工作需要誇公司協調,DevOps的難度會增加好幾個數量級
- 另一個基礎設施功能失調是開法與維運人員間,因職責分野上形成對立
- 最後當組織沒有採取良好的實踐法,在基礎設施中引入大量技術債務
- 只有架構師、開發者、DBA、DevOps、測試、資安、其他貢獻者才能決定演進式架構的最佳路徑!
未來狀態
- 隨著團隊越來越熟悉整體的概念與實踐法,他們會熟練將他們運用在商務中,並使用那些概念來發展新的能力,比如資料驅動開發
未來狀態 — 生成式測試
- 傳統的單元測試用斷言來確定每一個測試案例的結果
- 使用生成式測式時,開發人員會運行大量測試並抓取結果,接著對結果透過統計分析來尋找異常行為
為什麼公司要建構可演進的架構?
- 過去幾年裡,變更的週期越來越快了
- (我就過去經驗上,各種語言、框架、甚至機台OS、各種技術迭代都越來越快,然而資安問題(想想Log4j問題推進了Log4j好幾個版本號)又會將迭代速度加上火箭推進器)
- (金融業經驗就遇到過infra團隊提供新的OS機台給我們團隊進行系統升級的先建後拆,然後當我們花費一年將各環境的系統都在這新的OS機台上升級完畢後,Infra告訴我們,當初提供的OS版本準備要EOS了,請準備進行升級...這也間接驅動我對可遷移性架構的興趣(所以我才會看這類書籍!))
為什麼公司要建構可演進的架構? — 可預測性vs. 可演進性
- 由於軟體開發生態系統的動態均衡,可預測性已經是過去式了
為什麼公司要建構可演進的架構? — 擴展
- 過去有段時間建立架構的最佳做法是使用關聯式資料庫來建構交易系統
- 但是依賴資料庫的協調機制最終都會遇到瓶頸
- Amzaon發現讓所有東西與某一個東西耦合(無論RDB或ESB等)最後都會限制可擴展性
- (挖幹!上面這段真的是金融業的現在進行式阿!!!)
為什麼公司要建構可演進的架構? — 將週期時間當成商業指標
- 週期時間已經變成一種商業差異了
- 很多公司把週期時間當成最重要的商業指標,主因是他們處於競爭激烈的市場
在量子層級隔離架構特性
- 將傳統的非功能需求式為適合合度函式,並建立妥善封裝的架構量子
- 可讓架構師支援每個量子的不同特性,這是微服務架構的優點之一
- 由於每個量子的技術架構都和其他量子解耦,架構師可以為不同的使用案例選擇不同架構
調整vs. 演進
- 許多組織陷入技術債務逐漸增加,且不願進行必要的重組陷阱,這會反過來讓系統和整合點變得越來越脆弱
- 有些公司試著使用連接工具(ex ESB)來掩蓋這種脆弱性,ESB可以緩解一些技術難題,但無法解決更深層的商業程序邏輯內聚
- (我個人經驗,ESB有個嚴重問題是沒有擴展性可言,極高的機台Resource需求,很難做到水平擴展,另外還有個問題是台灣原廠沒有好的架構能力,遽聞相關架構能力較好的可能只有國外的顧問)
為什麼公司不建構演進式架構? — 無法演進大泥球
- 可行性是架構師經常忽略的一種"-ility" — 團隊應不應該承接這種專案?
- 如果他們的架構令人絕望地耦和成一起的大泥球
- 修改它,使它能夠演進的花費大量的工作
- 公司該如何判斷自己是否處於這種情況?
- 將既有架構轉換成可演進架構的第一步是模組化
- 將架構變成沒有那麼糾結之後,架構師更容易看到底層結構,並合理地評估重組所需的工作
其他的架構特性更重要
- 可演進性只是架構師在選擇架構風格時必須取捨的眾多特性之一
- 沒有架構能夠完全支援多個彼此衝突的核心目標
- 例如在同個架構中建立高性能和高擴展性是很困難的
- 有時其他的因素比演進性還要更重要
- 例如領域專用架構的目的是將單一特性最大化
- LMAX即是領域專用架構的例子
- 它是一種訂製的交易解決方案,藉由最低層面上分析,他們發現可擴展性的關鍵就是縮小邏輯
- 讓它可以放入CPU快取,並預先分配所有記憶體,以防止記憶體被釋出
- 他們的架構可以在一個Java執行緒上時現驚人的每秒600萬個交易!
犧牲架構
- 前面章節就有提到,就是個可拋棄的先行版來調查市場或驗證可行性
準備在短時間內結束營業
- 就不用考慮演進了!
說服別人
- 與其試圖說服組織中不表示意見的部門,不如展示這些概念如何改善他們的工作
商業案例
- 許多公司都把軟體是為一種開銷,很像空調系統
- 當軟體架構施予這種公司的高層討論軟體創新時
- 高層都會把他們看成以高昂的價格來推銷自己的水電工
快速前進且不造成損壞
- 演進式架構有一個附帶效果 — 產生更好的工程效率
- 漸進變更的所有做法都可以提高自動化的效率
較小的風險
- 風險會隨著工程師箭法的改善而降低
- 一旦開發人員確信他們的作法可在不破壞東西的情況下更改架構,公司就可以提開釋出的節奏
新能力
- 向商務人員推銷演進式架構概念的最佳方法,就是展示它提供的商業功能,例如假設驅動開發
建構演進式架構
- 將架構特性是為可以評估的東西,而不是突發性的期望,並藉此建構更具彈性的架構
在產品先於專案有提到應圍繞在產品建構團隊
過去我遇過系統規劃部門只做專案系統導入,完全不管後續運維
然後後續運維也是丟給開發團隊
導入過程系統的必要性,適合不適合等各種規劃面都不理會(是的,他們沒有在做系統方面的規劃,卻掛著系統規劃部門這個名稱)
然後大量調配開發者人力協助他們完全不懂的技術系統導入的專案工作(是的,他們沒有一個有IT方面的專長,都是專案管理方面的專長)
這大概是我遇過最扯的部門....
