我喜歡在文章裡面放張圖，雖然現在 AI 生圖很方便，但還是喜歡放自然一點的，不論是自己拍的或是網路上看到的(from unsplash) 前言 在 Kong API Gateway 的日常維運中，Control plane 與 Data plane 的同步機制是個蠻值得關注的概念。最近在檢視公司架構圖時，我發現到 Control plane 與 Data plane 之間的 policy sync 方向標示為 Data plane 向 Control plane「拉取」最新設置。 簡單畫，公司實際架構圖沒這麼醜 在看到公司架構圖標示 Data plane 會「拉取」設定時，其實我一開始沒有多想，且防火牆確實只開了 Data plane 到 Control plane 的 8005 port。 但後來仔細思考，覺得這種設計有點奇怪——如果是 Data plane 不斷輪詢 Control plane 是否有設定變更，那輪詢頻率要怎麼抓？萬一設定異動很頻繁，會不會造成不必要的流量和效能浪費？而且從系統設計的角度來看，應該是由管理端（Control plane）主動通知執行端（Data plane）有異動才比較合理。這讓我開始思考，究竟同步機制的實際運作方式是什麼？ 這些疑問促使我去查官方文件，才發現實際上是 Control plane 主動推送設定(如下圖)，和我原本的認知有落差。 Control plane 與 Data plane 先簡單說明一下這兩個東西是什麼。 Kong Gateway 在 hybrid mode 下，有兩個重要的角色，分別為 Controle plane 與 Data plane，其功能分別為： ...

最近聽到幾個沒有聽過的名詞覺得蠻值得記錄一下，也算是跟 DevOps 有關。 綠地專案 vs. 棕地專案: 我們站在什麼樣的基礎上開發？ 這兩個詞彙本來是都市計畫的術語，我查是這樣，但我沒印象我大學時有學過，我記得以前是用「素地」來表示沒有建築物的土地。「素地」與「空地」不同，空地是指已有道路、排水、電力設施，可利用而仍未依法作建築使用，或已作建築使用，其建物價值不及基地申地價的 10%。 好，扯遠了，總之，這兩個詞用來比喻專案開發時所面對的環境。「綠地專案」指的是從頭開始的專案，而「棕地專案」指的是從既有的專案上開發。 對綠地專案而言，一切從頭開始，沒有既有專案的歷史包袱，理論上可以自由地選擇最新的技術、架構與工具，例如新創團隊開啟一個全新的專案，大概是這樣的概念。而相反地，棕地專案則像是在一塊已經開發過、甚至可能受到污染的「棕地」上進行翻新或擴建。開發團隊必須在既有的、可能充滿技術債的程式碼基礎上工作。例如我目前手上的專案全部都是棕地專案，充滿著大量 legacy code，牽一髮動全身的程式碼，讓我改起來膽戰心驚，到最後就很容易抱著能不改就不改的心態(If it works, don’t touch it.)。 總而言之，這表示在評估一個專案時，不能只看要開發的功能，更要理解它所處的狀況。是從零開始的創造？還是在既有框架下的奮鬥？這會影響策略的擬定。 平台工程(Platform engineering) 平台工程(Platform engineering)可將開發人員的部分工作和基礎架構相關手動作業移至 IDP(Internal Developer Platform)，讓團隊能專心開發應用程式及投入創新1。 這聽起來有些抽象，但可以想像如果在一間公司中，AP 人員(開發團隊)需要自己處理伺服器、資料庫、CI/CD 等 infra 上，那就是一種資源的錯置，這會讓開發人員無法真正專注於在開發上2。平台工程團隊的角色，就是將這些繁瑣但必要的工作，整合成一個自助式的平台。開發人員可以透過這個平台，完成環境建置、部署、監控等任務。 在我們的場景，例如伺服器、資料庫這類 infra，是不需要自己建置，我們是透過需求單系統，填寫工單請專責人員建置3，這中間要經過層層關卡（雙方主管）的審核，最後才會成功把需求傳遞到專責人員手上開始作業。而作業過程中依據 SOP 需要留存大量的「軌跡」，這些軌跡最後都有可能會被稽核檢視其是否合規。簡單來說，有平台，但不好用。 至於 CI/CD，我們在導入 Azure DevOps 後算是有完成了這一塊拼圖，建立起一個可用的平台，畢竟我們原本的部署上線方式真的令人太痛苦了，這個有機會以後可以再分享一下。 https://cloud.google.com/solutions/platform-engineering?hl=zh-TW ↩︎ 在敝公司雖然不用自己建置基礎設施，但很多時候都要自己管理，因為我們的角色某種程度上是開發人員兼維運人員。 ↩︎ 在《獨角獸專案》這本書當中看到無極限零件公司裡面也要填寫類似的工單系統時，令我倍感熟悉。 ↩︎

AI 工具雖然快速，但我仍偏好用書本學習一些需要深層理解的知識。軟體架構一直是我想補強的領域。平常工作中會嘗試從架構的角度理解問題，但我希望能讀些更嚴謹、系統化的書籍，從底層建立起紮實的認知框架。 軟體架構是什麼？ 軟體架構可以類比為房屋的結構設計。建築中可能包含承重牆、樑柱與屋頂等結構元件，沒有這些結構，房子就無法成立。至於地板材質、顏色，甚至沙發要擺在哪裡，這些並不會出現在建築的結構圖中，因為它們與設計相關，而非結構。 類似地，軟體系統也有其結構，而我們對這種結構的理解，可以從四個維度來思考1： 架構特性（Architectural Characteristics）：系統著重於效能或是妥善性？ 架構決策（Architectural Decisions）：例如系統的使用者介面是否允許與資料庫直接溝通，或是必續透過資料存取服務（如 API)來溝通？ 邏輯組件（Logical Components）：每個業務功能的原始碼集合（成立訂單、付款） 架構風格（Architectural Styles）：微服務、分層架構等。 因此當有人說「我們的架構是微服務」這句話只定義了一個維度（架構風格），不足以描述整體架構。 架構角度 & 設計角度 上面提到，地板材質、顏色這些設計，對系統而言是設計角度問題。舉例來說，更改網頁的背景顏色，這種較偏向設計，而非架構。 但事實上架構與設計並沒有辦法那麼容易截然二分，他們是位於光譜的兩端。例如，將一個服務拆分為兩個獨立模組，這不僅涉及程式結構的重構與介面設計，也可能影響部署策略與服務間依賴關係。這類決策就處於設計與架構之間的模糊地帶。 待續 參《深入淺出軟體架構》, Raju Gandhi, Mark Richards & Neal Ford。 ↩︎

前言 今天重新打開 Algomonster 時，點開了之前沒特別注意的 Getting Started 章節。其中一句話讓我停下來反覆思考： At AlgoMonster, we love systems. We are big believers in systems over goals. – 在 AlgoMonster，我們熱愛系統。我們堅信系統比目標更重要。 這句話讓我產生好奇：「系統比目標更重要（systems over goals.）」這是什麼意思？點進連結後，發現是漫畫家 Scott Adams 的部落格文章1，內容來自他的一本書《How to Fail at Almost Everything and Still Win Big》2。這裡整理出我讀完後的理解與想法。 目標（Goals） Scott Adams 指出，目標是「限制性的 (limiting)」。如果你只專注於一個特定的目標，雖然達成它的機率可能比沒有目標時高，但你可能會「錯過可能遠比你的目標更好的機會」 (miss out on opportunities that might have been far better than your goal)」。 舉例來說， 減重多少公斤：這類目標很常見，但實際上很難持之以恆（我自己也經歷過）。 每週去健身房三到四次：這也是一個目標，對於不喜歡運動的人來說可能感覺像懲罰，導致最終因為感到痛苦而放棄。 系統 (Systems) 而 Scott Adams 認為，「系統」旨在將你從低勝算的情況轉移到高勝算的情況 (move you from a game with low odds to a game with better odds)。 透過系統，你不太可能因為過於專注於一個機會而錯過另一個 (less likely to miss one opportunity because you were too focused on another)，並且總是在掃描任何機會 (always scanning for any opportunity)。 ...

前言 最近遇到一個需求，我們的 mobile app 需要用 web view 開啟某個網頁。因為該網頁的認證方式最近有調整，app 端也得跟著修改。也因此這次 iOS 也要從原本的 SFSafariViewController 換成 MKWebView 來實作內嵌網頁，結果問題就這樣冒出來了。 過程 事情大概是這樣： 當我在頁面上點擊某個按鈕，會跳轉到另一個網頁，然後這個新頁面會自動彈出一個視窗到最前面。奇怪的是，首頁本身載入沒問題，如果在首頁觸發彈窗也都正常。但只要是跳轉後的頁面，彈窗就會出狀況。 一開始我懷疑是 cookie 沒有正確傳遞，或是 header 有缺漏，所以重點都放在這些地方。用 Safari Web Inspector 看 network，也沒看到什麼明顯的錯誤，只是覺得很怪，怎麼 request、response 的紀錄都不太完整，像是 header 竟然是空的。當下還以為這就是正常現象，只好很麻煩地回到 app 裡面用 NSLog 確認內容。 後來不知道哪根筋突然不對，想說試試看手動按一下重新整理。沒想到這一按，network 頁面所有的請求紀錄都跑出來了，header、response 什麼資訊都有。這時才發現，原來是某個 JS 檔在執行時出錯。仔細追查才知道，是網頁開發者寫的「取得使用者瀏覽器類型」的 function 沒有考慮到 MKWebView 發出的 User-Agent，導致相關 UI 無法正常顯示。 那段程式碼還註解「若非不得已，盡量少用此方法」，是一個拿 14 年前 stackoverflow 上的解答的函式XD User-Agent：WKWebView 預設的 User-Agent 與 Safari 或 SFSafariViewController 不同，若網頁端有依賴 User-Agent 進行判斷，需特別注意。 關於 Safari Web Inspector 的觀察 這次讓我發現，Safari Web Inspector 其實有個不太直覺的地方。你必須先在手機上打開那個網頁，Inspector 的 develop 頁籤才會出現該網頁的選項。也就是說，當你點進去看的時候，網頁內容已經載入完成了，Inspector 只會顯示最後的狀態。過程中的流量、請求紀錄根本沒被捕捉到，除非你手動重新整理一次，才會看到完整的 network 資訊。 ...