Microservice 系列：如何建立開發團隊
CTO、Tech Leader、PO、PM 踏入微服務的參戰手冊
微服務 (Microservice) 應該是現行工程師必備的知識，從一開始學界開始討論，軟體服務提供商（ IBM 、Google…）、內容提供商(Netflix、BBC …) 導入實作後，現今各大中小型開發團隊或多或少都開始討論並著手開發。但踏入開發後，團隊結構、編組是否符合微服務的框架，便是管理者必須思辨的課題。
本文將分享我認為適合微服務的編組，有興趣歡迎向下閱覽～
Microservice 系列 小檔案
目前計劃分別往研究面、技術面到管理面深入探討，將這些年在開發上遇到的難題、想法與讀者逐一分享。由於我本人較深入在 Kubernetes 的整合開發（如 Controller / CRD …），技術面的討論大多聚焦在 k8s 、Containerize 這個導向的微服務架構，若有興趣歡迎追蹤我的專欄！
本文將分別由組織面的變革、培訓面的變革兩種焦點切入探討：
組織面的變革
從業務面回推服務拆分
談到組織面的變革前，首先要談的絕對是微服務的拆分方法。微服務為大型系統解構下，依傍著分散式系統的基礎理念，由多個單元服務組合而成的新型架構。也因此，傳統單體式架構的思維並不管用。
根據目前業界與學界的討論，較為被開發界接受的應屬：由業務需求回推微服務怎麼拆。在這個思考模式下，不但技術團隊可以針對新的服務做最適合的技術選型，還可以加快對於市場需求的反應時間。
舉例來說，假設今日提議要製作「金流系統 Payment」，單體式的思維就是擴充原有 server 的功能，開發團隊思考的是如何在現有 server 的架構中，增加 Payment 的功能。但對於微服務的開發團隊，則是建立一個新的 Payment service，思考適合 Payment service 的技術選型 (DB、Software Language…)，為其量身打造最完美的服務架構。
當 Payment System 上線營運後，根據業務需求需要臨時加增 Apple Pay 、Google Pay 時，微服務的團隊也僅需強化 Payment System 的功能，而非像傳統單體式架構需思考整個系統的整合性。
發現了嗎？轉型到微服務的過程中，不只系統的架構轉型了，連動著工程師的思維、新功能交付的模式都改變了，這連動到 PO、PM 可以更好掌握住市場需求的脈動，讓產品做更快更有效率的反應。
但開發界最常談的就是「Trade off」，有了一好必定有其犧牲。微服務架構所生的架構維護壓力、降低耦合的設計難度，以及分散式系統會有的缺點也全都有。這些成本也勢必需要評估，筆者在未來也會以技術面來和大家探討這些問題。
開發團隊：編組改革
在傳統單體式(Monolithic)的開發下，你的團隊或許會猜分成開發(Developer) 、維運(Operations) 、測試 (QA) 三批人馬，並可能由 CTO 或 Tech Leader 專責管控全部團隊。
運行一些時日後，發現開發團隊與維運團隊間互相不爽，彼此 KPI 互斥、衝突的狀況不在話下。於是導入 DevOps 的精神，開始努力讓開發與維運和平相處，加強自動化的機制、完善化交付流程等。但踏入微服務，這套編組又顯得不太適用！
面對微服務，一個常見且可行的做法，是解構開發、維運、測試三大族群，改以服務(service)為組成單位，讓每個服務都配有開發、維運、測試三種工程師。
舉例來說，在 Payment service 裡，我們配置開發、維運、測試三種工程師成一個 Payment 團隊，這三種工程師以各自的專長領域，最佳化這個服務的品質。也因此，他們撰寫程式碼、設計架構時，自然就是以 Payment service 是否符合業務需求為思考方向，交付新功能時也僅更新自己所轄的服務，而非以整個系統為思考方向。
而當然，當開發團隊轉型成以服務為單位的工程小組後，每個小組都只聚焦在其服務的服務品質，也需要有工程師出來綜觀大局，確保整體架構的穩定與完善。一個可行的做法，是建立一個核心小組 (Core team) ，除了配置常駐的工程師處理整體架構的工作外，各服務小組也須抽出1–2人，參與 Core team 的討論，以確保核心小組的任務指標（讓整體系統穩定）是真正的兼顧到所有組成的微服務。
開發小組的目標：消費者契約導向
前文提及，傳統開發人員專注在如何新增功能並增加變動性，維運人員專注在如何穩定系統而減少變動性，但進到微服務的框架後，開發、維運或測試人員各自的任務指標仍然未變，衝突仍存，找到新型的有效共識便很重要。
消費者契約驅動（Consumer-Driven Contracts）是一個可行的方向。上文提及，業務需求對應到微服務運行的基礎單位，而我們通常都會針對單一業務需求進行契約規格的界定。讓單一服務 (service)下的工程團隊，全部聚焦在完成契約所定義的服務品質，進而讓消費者對於該服務感到滿意，是微服務架構下可行的應用模式。
消費者契約驅動所衍生的便是消費者驅動契約測試(Consumer-Driven Contracts Testing)，相較於端對端測試(End-to-End Testing)、整合測試 ( Integration Testing) ，消費者驅動契約測試有在微服務上應用的優勢，詳情可看下方網站：
培訓面的變革
談及微服務，可以論及諸多好處，但背後的技術成本（人力、能力）也不容忽視，以下便是值得討論的課題：
開發團隊的準備成熟度
以最基本為例，微服務生於分散式系統的一環，分散式所談的 CAP Theorem 、共識性等皆不容忽視，團隊首先就必須有基礎分散式系統的架構觀念。
踏入微服務後，容器 (Container)+Kubernetes 是一個廣被使用的配置，搭配上熱門的 Istio — service mesh strategy，維運人員是否對於新型領域有充足涉獵，並確保服務能達成高 SLA ，便是一個需要思考的課題。
同時，如前文所述，微服務的架構也改變開發者的思維模式。對於傳統開發者而言，當關聯式資料庫不再關聯、Event-driven 成為開發選項等，是否能有效的轉換思維，也是需持續推進的培訓課題。
新技術的掌握能力
微服務目前看來，僅在大型外商公司被廣泛應用。對於大部分的中小型及傳統企業似乎還在轉型、研發並小規模嘗試的狀態。意指，很多的微服務實踐方案仍須仰賴大型公司的技術文、開源專案的開發及社群上的討論。團隊若要加入微服務的技術圈，也勢必衡量工程師是否有與時俱進的開發能力，與完備的知識去支撐這些改變。
當然，定時參與開發者年會、社群，對於微服務的工程團隊有莫大的幫助！
以上便是關於微服務，組織面與培訓面的相關概念與想法，希望幫助到正在參與微服務開發的工程師與團隊。同時，若有任何想法，也歡迎在下方與我多交流交流～
如果你/妳喜歡我的文章，請給我 5 個以上拍手 👏
如果你/妳想看我寫更多這方面的文章，請給我 10 個以上拍手 👏👏越喜歡可以拍更多，我之後就會更常為你寫的！(拍手不只可以拍一次喔）如果覺得這個文章不錯，也歡迎 Follow 或 分享 給你的朋友喔～
