It’s Microservices …It’s docker …It’s organization structure
微服務和容器毫無爭議的成為了這個時代的主旋律，大家爭先恐後地讓自己的團隊和企業去嘗試這樣的旋律，但往往發現曲高和寡，難以在整個組織內形成共鳴。在本文中，我們嘗試揭開微服務和容器技術背後對映出的組織結構的變遷，以及組織結構對落地微服務和容器化架構所帶來的反向制約，最後用INVEST原則來看看支撐這樣鬆耦合架構的組織結構應有的特質。希望能夠幫助迷茫中的企業和組織重新思考自己的微服務之路。
Microservices（微服務）和docker（容器）成了近一年來軟體行業的新寵，每次參加相關活動總會感到康威老先生站在背後邪邪地笑著：“我早告訴你們了”。
儘管Martin Fowler在“定義”微服務時十分小心的警告了大家所要付出的代價，但好像微服務的優點太過於吸引人，以至於大部分軟體開發組織和企業都把微服務這種架構方式作為了未來的必選，大家都覺得我就是那個高個子（I’m that tall!）。
（Martin Fowler對伴隨微服務架構的高工程實踐能力的比喻。）
隨著容器技術到達生產應用的臨界點，這種化學效應好像一觸即發，我們彷彿看到了未來一個不一樣的軟體微服務大集市在逐步展開！
在這個集市裡會有淘寶這樣的平臺，為中小服務賣家搭起一個線上商城，買家可以根據自己的需要搜尋及購買琳琅滿目、各式各樣的服務，線上或是二進位制、程式碼質量及自動化覆蓋率等指標成為同類服務評級的重要標準。
殺手級的服務如區塊鏈或者量子加密可能成為皇冠銷量服務。最後掀起一大波程式猿開微服務店的熱潮~ 很期待那是怎樣的賣家秀和買家秀啊！
這種幾乎接近於科幻的描述可能只適合作為微信上的談資，但微服務和容器技術的流行卻並非偶然。康威老先生用自己的定律揭示了一個更深刻的道理：
這不是一次技術架構或者基礎設施的革命，而是為了保持組織靈活性的必由之路。
換句話說，軟體開發組織或企業開始意識到一切的管理和技術實踐都必須為保持儘可能高的組織靈活性服務。一定會有人問為啥要保持“儘可能高”的靈活性呢？鐵打的營盤流水的兵、穩定的規章制度不也締造出了歷史上那麼多成功的組織和企業嗎？
論儘可能高的組織靈活性
所以我在前面加了定語“軟體開發”，當然現在我們有一個更廣泛的提法：科技企業。通常我們認為產品或服務的技術含量比較高，具有核心競爭力，能不斷推出適銷對路的新產品，不斷開拓市場的企業為科技企業。
在我們所處的軟體時代，大量的科技企業都跟軟體沾上了邊。但歷史上我們可以回想大生產時代鍊鋼也曾是高科技，資訊時代發郵件也是高科技。前兩波的“科技企業”給我們的印象可不是靈活的：幾大鋼鐵巨擘讓人聯想到的應該是當年國家呼喚生產力全民建設的巨集偉場景；資訊時代佼佼者如Microsoft和IBM讓人聯想到的應該是動輒千人的大型工業軟體開發隊伍，一個部署都得來一個專家隊伍。那麼為啥現在我們們的科技企業必須靈活，而且必須儘可能高呢？
這裡我們再次使用康威老先生的定律來做推論，康威定律說
“一個產品或系統的設計（架構）受到其生產組織自身交流溝通結構的制約”，
換句話說如果你有一個前端展現團隊、一個後端服務團隊和一個資料庫團隊，那麼我們可以肯定，搞出來的系統會分前後臺和資料庫的設計。這本身是一個悲觀的定律，所以前面的團隊發現新需求來了必須溝通三次，前後臺團隊關心新需求對自身架構的影響，資料庫設計關心對現有資料結構的衝擊，最後總是會在各方的爭執中得到一個別扭的解決方案。
很多團隊早已經習慣了這樣的痛苦，數字化時代的變化頻率將這樣的痛苦逐漸推向了頂峰。舉例感受一下：達到100億產值，首鋼用了71年，聯想用了13年，這個時代的小米用了僅僅3年！而今年的小米已經不是站在浪潮之巔的科技新貴了。
所以康威老先生說：
如果要保持產品的持續競爭力，就要保持組織的靈活性。
曾經有人跟我爭辯說：“我們做的是數字化時代的後臺系統，不直接面對市場，需求很穩定，搞那麼靈活成本反而高。”於是我指著他們有著千萬行程式碼的系統說：“你們至少有30%程式碼是冗餘的，這就是組織缺乏靈活性的另外一個惡果。”
這裡我們先收縮範圍到軟體開發，非常有意思的是在我們們這個行業裡，針對同一份需求，沒有兩個開發人員實現出來的程式碼是一樣的（也許Hello World例外）。甚至，當我發現兩個程式設計師使用的變數命名一樣的時候我會懷疑他們抄襲了。這說明軟體開發從需求提出到寫程式碼實際都是在做設計，不同的人設計出來的東西就會不同，像大家的簽名一樣。
設計甚至延續到了後面的軟體測試和部署，同樣的應用在不同的網路拓撲結構下表現可能是完全不一樣的。那些追求穩定的組織希望儘早結束設計這個高度不確定性的活動，從而能夠通過標準化來提高效率。
即使在敏捷開發主流化的今天，很多團隊仍然是架構師“畫圖”，碼農堆砌程式碼。所以這樣的組織很快發現自己深陷二進位制的泥潭，進退維谷。我經常跟這樣的團隊講：你們缺乏“程式碼的響應力”。而響應力對組織的要求就是靈活，能夠從前到後駕馭設計活動帶來的不確定性。
小結一下：數字化時代的市場變化是迅猛的，康威老先生已經告訴我們，處在這樣時代背景下的科技企業保持組織靈活性是十分重要的。而軟體（廣義講新科技領域）本身由於強設計而帶來的不確定性又加重了對組織靈活性的訴求。
於是在這個時代我們看到了如Google、海爾這樣已然成功的企業開始大刀闊斧地改革自己的組織結構，這種對靈活性的極致追求成就了這些組織持續保持市場領先水平的核心競爭力。毫無疑問，微服務架構的優點也正反向對映出了組織結構的靈活性，而容器技術的運用降低了這種鬆散集市結構的運營成本，就如同淘寶平臺的出現給千千萬賣家和買家搭建了一個基礎的交易平臺。
彈性伸縮的容器化計算資源加上鬆耦合的微服務架構必然會吸引追求組織靈活性的企業去打敗康威定律，保持組織活力。
組織結構的INVEST原則
前面我們們辯證了數字化時代科技企業保持組織靈活性的必要，那麼靈活的組織結構應該滿足什麼原則呢？下面我們就借用敏捷開發中赫赫有名的需求管理原則INVEST來剖析一下怎樣的組織結構才能夠真正落地微服務架構和容器技術帶來的靈活性優勢，或者從另外一個角度看支撐微服務架構的運用。
（兩種組織結構對比示意）
獨立的：Independent
按照微服務架構的團隊應該對外提供一種或多種服務，服務和服務之間應該是鬆耦合的，所以背後的團隊也應該是相對獨立的。遵循康威定律，如果一個大型組織沒有能夠劃分出服務導向的相對獨立團隊，那麼最後對外提供的產品或系統的內部結構也不可能是簡單的服務組裝，而會是我們常說的“義大利麵”，內部結構糾纏不清以至於最後響應市場新需求越來越慢。 便於溝通的：Negotiable
“小“服務團隊的結構必然造成整個組織的集市化、社群化。如果沒有建立良好的團隊間的溝通機制，很難想象這樣的組織裡會有任何的產出。Amazon被認為是一個微服務架構運用的成功典範，其2pizza團隊的原則成為了業內的標杆。
但這樣服務導向小團隊集合的底層是長期磨合形成的良好團隊間溝通機制，甚至當我們問到Amazon各個團隊如何發現其它服務或要求其它團隊協助完成需求時，團隊都說不出具體的流程機制，一切都變得很自然，全然像我們走進自己熟悉的超市一樣，能夠很自然的找到日常所需。
有價值的：Valuable
毫無疑問，每個團隊必然是面向價值交付的。敏捷開發方法的提出其實很早就指出了傳統方式下按照功能部門劃分的瀑布交付模式的原罪，即每個功能部門都不對最終的價值交付負責（Output over Outcome，輸出大於結果）。這樣的組織結構必然造成對市場變化響應的滯後。
值得一提的是面向價值交付的團隊往往也是跨職能的，按照微服務的架構，團隊需要負責服務從需求到部署運營的全生命週期（Outcome over Output，結果大於輸出）。這也是為什麼在基礎的工程交付平臺及實踐上團隊必須是一個“高個子”。
可估計的：Estimable
這樣的服務團隊交付週期應該是很短且可以準確估計的，上線應該是家常便飯，而不是過去短則數月、長則一年的大爆炸模式。持續交付在這樣的組織裡應該是標準實踐，讓軟體系統時刻處於可釋出狀態是團隊的共同責任。從Amazon和Netfliex這樣的現代科技企業身上我們已經看到了這樣組織結構下逐步形成的工程能力優勢，並最終轉換成了業務服務上的巨大成功。
短小：Small
前面提到了Amazon的2pizza團隊，人數10人以內，經典的敏捷管理框架Scrum也建議5~9人的團隊，可見小團隊成為組織靈活性的一個必要條件。中國俗語有“船小好調頭”樸實地揭示了小的靈活性，但為什麼不再小一點呢？比如兩個人結對一個團隊。
顯然大家很容易發現軟體開發本身的複雜性決定了要端到端交付價值兩個人的團隊是搞不定的。從整個組織的健壯性來講，過小的團隊也會增加企業形成單點依賴的風險。雖然沒有正式確認，但我們交流中發現Amazon這樣的微服務組織裡其實也是存在服務冗餘的，這樣的重複保證了組織在切割成小團隊後風險得到適當的規避。
可測試的：Testable
在面對市場情況高度不確定性時，我們應該直面試錯這件事情。傳統職能型的大組織結構往往是不能容錯的，錯誤的代價就是整個企業走偏了方向，或者一個部門在企業裡失去了話語權。
在靈活性高的組織裡我們卻應該是能夠很容易進行這樣的“測試”，企業更能夠利用這樣的結構進行動態的投資組合管理，像Google著名的7：2：1投資比例，最後的一成就是利用組織的靈活性進行創新的測試。測試的結果往往是失敗的，但正是這樣的不斷測試創造了Google歷史上很多著名的“黑天鵝”。
打破康威定律
最近很多以精益（LEAN）為關鍵字的理論框架在我們們這個領域冒了出來，也包括我前期撰文提到的精益企業（Lean Enterprise），於是有朋友揶揄說又開始炒概念了。我卻很嚴肅地澄清正是不希望炒概念，所以才回到了上個世紀就論證和發展起來的理念：精益。
來源於豐田製造的精益總結出了很多的原則和實踐，但有意無意中豐田完成了自身組織持續靈活性打造這項超越同期其它企業的偉業。其結果就是在響應需求多樣化時展現出的更強適應能力。
如果用我們前面的INVEST原則來看待精益組織，你會很快找到對應的原則和實踐，即使在傳統的工業流水線上，豐田也在形成一個個的小團隊（cell，單元生產），也在通過員工的多技能培養來完成小團隊內部的“跨職能”。其持續改進（Kaizen）的核心思想有力保證了團隊面向價值的工作方式和良好的跨團隊溝通文化。
某種意義上講精益在康威定律定義之前就打破了康威定律！
微服務和容器技術無疑是這個時代工程架構方面支撐組織靈活性的重要一步，然而我們不能忘記一個組織是五臟俱全的，如精益企業提到的，組織的財務審計、人力資源、採購合規等功能如何有效的“微服務”化和如何能夠合力構建一個彈性的“容器”支撐平臺仍然需要諸君努力！