-
架構師觀點 - API First 的開發策略
這篇的內容，是我在 DevOpsDays Taipei 2022 的 Keynote 演講的主題: DevOps 潮流下的 API First 開發策略。這場次的內容，正好是我近期正在努力的方向，演講的時間有限，沒能 100% 表達我想講的內容，於是我還是用我最習慣的方式: 文章，重新來闡述一次這個主題吧。
API First, 講的是在你的開發流程內，API 應該被擺在第一順位思考的開發策略。一開始就瞄準 API 為主軸的開發方式，你會發現整個流程跟思考方式都不一樣了，這就是我這篇想要傳達的主軸。我在第一部分先花了點篇幅，說明 API 為什麼應該要 “First” 的理由。API 是很講究事前的規劃與設計啊，有時候會讓人有跟 DevOps 闡述 “先交付價值，尋求回饋持續改善” 的快速循環有所衝突的錯覺。這並非是你要做出二擇一的選擇，而是在持續改善的循環中，有沒有掌握好長期的目標的差別；而 API 的設計往往就是容易被忽略的一環。
因此我多準備了一段: 就是 “架構師在敏捷團隊中該扮演的角色”，這是我在演講當下沒時間聊到的段落，我在文章內也把他補上了! 同樣的內容，除了 DevOpsDays Taipei 2022 Keynote (2022/09/16) 之外，我事後也跟保哥進行了一場同主題的線上直播 (2022/10/07)，相關連結我擺在文章最後面。你可以選擇你想要的方式來了解，不過我個人是最推薦看我部落格文章啦 :D
-
水電工日誌 #8. 家用網路設備整合, UniFi + NAS 升級之路
自從 2019/10 因為原本網路設備掛掉, 開始敗入 UniFi 的體系, 果然如同傳聞的一般, 不知不覺就整套換下去, UniFi 的設備就這樣一直繁殖下去了。事隔兩年半, 我家網路主要設備總算都更新完畢, 於是重新補上這篇, 把我對家裡網路的想法交代一下。
這篇我想寫的，不是只介紹硬體的更新而已。硬體更新沒啥特別要交代的啊，這種東西裝好了大概就無感了 (會有感都是網路出問題)。我想說明的是我怎麼藉由 UniFi 的 SDN 把我想要的網路環境搭建起來。從 2007 我開始在家裡擺機櫃開始，機櫃裡的設備其實都在處理這些事情:
- 網路設施 (routing, switch)
- 網路服務 (dns, web server, storage, backup)
- 監控設備 (dvr)
- 電話總機
回顧一下當年的設備, 果然看得出時代的眼淚, 在過去幾年都被我逐步的換掉了。這一連串設備的整併更新，其實我早就想做了，只是一直都沒有看到滿意的 solution 就沒有很積極的替換，直到我開始購入 UniFi WiFi AP 開始 …
-
[架構師的修練] - 從 DateTime 的 Mock 技巧談 PoC 的應用
圖片來源: 動畫瘋, SPYxFAMILY #4這篇不打算寫那麼長，短篇就好，先聊聊一些比較直覺的實做技巧，同時也當作 PoC 這主題的起點。我想聊聊一件事: 就是在單元測試 / PoC (Proof Of Concept) 的過程中，怎麼處理
DateTime.Now難以控制預期結果的問題?DateTime.Now會傳回系統目前的時間，不過這很難預測 (你不知道何時程式才會啟動啊)，這也讓依賴DateTime.Now開發的程式碼難以精準的測試。要解決的方法也不難，只要用這些關鍵字 (C#, DateTime, Mock) 到 Google 查一下，應該就可以查到一堆。不過，如果只是要在單元測試過程中掌控DateTime.Now的行為，其實這樣就夠了。我在思考系統設計過程中，很常用 PoC 的技巧，也常常會面對時間的問題啊… 隨便舉個例子:系統在接受客戶的訂單時，會立即傳送確認訊息，同時會排定在每個月 15 日的 02:00, 更新月結報… blah blah …
如果我要寫這樣的 code, 難道每次測試或是 demo 都得要等一天嗎? 或是我就真的得調整系統時間嗎? 如果這些場合還有面臨 UI 等等元素的介入 (不只是單元測試)，我該怎麼做?
因為有這些延伸的需求 (反正
DateTime的處理也不複雜)，我就決定捲起袖子自己弄了… -
微服務架構 - 從狀態圖來驅動 API 的實作範例
微服務 API 的設計與實作，來到第二篇。
圖片來源: https://www.freecodecamp.org/news/rest-api-best-practices-rest-endpoint-design-examples/
會有這篇，其實是有感現在講架構的文章太多了, 但是每個人看了同樣的文章, 最後實作出來的落差都很大啊。很多架構類的文章都是標竿大型系統的設計，不過還沒有對應經驗的人，看了這類文章是沒辦法從小規模的系統經驗，直接跨過那道鴻溝啊，所以往往有些看的多的人，在專案上拿捏不好設計的力道，不知不覺就做了過度的設計 (過度可能是超出期待太多，或是超出能力範圍太多都算)。因此我在講完架構的設計概念後，我都會希望能搭配實作的驗證，PoC 也好, MVP 也好，總之能夠真正用能運作的方式，把要解決的情境用你想的架構實際推演一次。架構實作一定是複雜的，有很多工程問題要解決，因此能否在這階段盡可能的排除非必要的實作，又能達到驗證的目的，就是抽象化能力的考驗了。Do the right thing 比 do the things right 同樣重要，但是不先看清楚 right thing 的話會讓你後面的 do the thing right 功虧一簣，因此有了這篇文章，來驗證上一篇我介紹的方法: 用狀態機來驅動 API 設計。
所以，第二篇的主軸，我決定把內容重心擺在理想的設計，該如何搭配成熟的技術實作出來? 架構師最難的課題就是做好技術選型。你必須在整體的系統內找到背後統一的脈絡，做到每個子系統之間的協作是具有一致性的，而不是單純的從各個領域挑出最酷的技術來用就好了。例如最常見是安全機制，要在跨服務協作的前提下，讓大家的安全機制都標準化才能互通。同樣的道理，除了安全機制，其他在 Logging 處理，Configuration 的處理，認證授權的管控等等都是一樣。這些設計必須貫通整個系統，從前台 (面對 enduser)、後台 (面對客戶的管理者 staff)、中台 (面對外部開發商與營運商本身 developer / operator) 、甚至面對內部的核心系統其他 (微) 服務等等情況都是。
這些都是微服務架構設計的難題啊，我在第一篇提到如何用狀態機來收斂你的設計 (不論你用甚麼方法分析，DDD 也好，UML 也好..)，將設計與實作都能擺在狀態機上面用一樣的方式驗證。這篇，我想延續狀態機的想法，當你有了很好很收斂的設計之後，我想完整的用 .NET 的生態系走過這整個從設計到實作的過程，期待能兼顧商業需求、架構與工程的需求都能兼顧。這篇會牽涉到很多實作的細節，涵蓋實作一個完整功能的微服務必要的架構跟設計。
-
微服務架構 - 從狀態圖來驅動 API 的設計
這次我直接破題了。我想寫一篇從 State Machine 的分析為主軸，來驅動整個服務的 API 設計的文章。
圖片來源: https://www.giga.de/artikel/was-ist-eine-api-schnell-erklaert/
“我們服務的 API 設計很糟糕，怎樣才能設計出好的 API? 有沒有一些 SOP 或是準則可以給我參考?”
其實這個問題我已經被問到爛了，答案當然是 “沒有” 啊 XDDD, 如果有的話，這個問題根本就不會是個難題，也不會有這 FAQ 了。首先，API 的好壞，”設計” 占了九成以上啊! 設計問題是沒有正確答案的，既然是設計，就是帶有個人風格的，你會發現有些大師的設計就是既精準又靈活，看的到背後的巧思，每個環節都搭配的恰到好處，找不出一絲多餘的設計。指南 (Guideline) 通常是告訴你該做什麼，不該做什麼。它可以讓你設計出及格的 API，但是沒辦法讓你設計出理想的 API。要達到這個境界 (我也還不夠格) 需要依靠的是對 domain 更精準的掌握…。
先定義一下，何謂 “好” 的 API? 我很看重 API 設計上的一致性。API 必須顧及很多層面，例如你要端出那些功能? 這些功能是否都用一樣的視角來設計? (主詞會不會一直變動?) 背後處理的邏輯是否一致? (某個 API 不准你取得的資訊，另一個 API 卻又可以?) 你能否在呼叫前就很明確的知道能不能這樣用? (還是任何大小事都要查文件才能搞懂?)
其實這些細節都很煩人啊! 這些都是很多不同面向的考量，我們在實作時同個面向的問題往往都能很一致的處理，不同面向的一致性往往就因為背後的實作階段不同，就很容易被忽略。因此我蠻重視在設計階段就先想辦法對齊這些不同面向的問題。我的作法是，通通都在狀態圖上面把這些 API 設計的要素標示出來，在同一張圖上面思考，就很容易在設計階段解決一致性問題。
