IaC的本質: 超越程式碼的工程原則
對於基礎設施即代碼(IaC)的關注重點，應該從代碼對基礎設施的表達能力，轉移到它所促進的軟體工程原則上
❏ 引言
最近工作上有個 landing zone 建置案，當中有一個子項目是將 landing zone 以 Infrastructure as Code (IaC) 的方式做佈署。專案初始並沒有詳細定義究竟哪些資源要做 IaC，所以執行時和客戶原先的期待 (所有資源都要 IaC) 出現了一些落差。
這期就讓我們來聊聊 IaC 吧 🤓
.
📍 大綱
❏ Landing zone & Infrastructure as Code (IaC)
❏ 現實中的 IaC
❏ IaC 的本質
❏ 關注 IaC 的 工程原則 > 表達能力
❏ 有所為，有所不為
《非正式寫作》著墨琢磨 技術趨勢、溝通領導、概念理解 與 生活實踐。
每週一四派送，免費訂閱起來👇
🔍 工人智慧猜你也喜歡
❏ Landing zone & Infrastructure as Code (IaC)
首先，先介紹兩個基礎概念：
✔ Landing zone
在雲服務的世界中，Landing Zone可以理解為一個 "安全著陸區" 或 "基礎設施藍圖"。
想像你要在一片新的土地上建立一個小鎮。在開始建設之前，你需要先規劃好整個小鎮的基礎設施，比如道路、供水、供電、安全系統等。這個初始規劃和基礎設施就相當於雲服務中的 Landing Zone。
案例中的客戶有一個負責管理全公司雲端架構的維運團隊，其他單位想要將開發的 app 運行在雲端環境中，需要透過這個團隊來創建和管理其運行環境。由於組織龐大，有各式各樣的單位和各式各樣的 app，為了確保這些個別的運行環境都足夠安全和一致，就需要有 “藍圖” 的概念，將這些規則變成一個個固定的模版 ("基礎設施藍圖")。
.
✔ Infrastructure as Code (IaC)
Infrastructure as Code 意指用程式碼來定義和管理 IT 基礎設施，而不是手動設置。想像一下，如果你要搬家:
傳統方式: 你需要親自搬運每件家具，安排每個房間的擺設。
IaC 方式: 你寫下一份詳細的 "搬家計劃"，列出每件家具應該放在哪裡。然後有一個系統會自動按照你的計劃來執行搬家和擺設 (有夠輕鬆 XD)。
在雲服務管理中，IaC 可以用來自動創建和管理 虛擬機、網絡、存儲等資源。這讓維運團隊能夠更快速、更可靠地部署和管理複雜的系統。
.
由於 微服務架構 和 雲端運算技術 的興起，系統在 ”擴展” 和 ”部署” 的需求大幅提升，靠傳統的手動配置步驟繁瑣、且容易出錯。因此，將基礎設施的配置和管理轉化為代碼，就像開發軟體一樣，IaC 的概念和工具因此流行和發展了起來。
.
❏ 現實中的 IaC
前陣子在 threads 上面調查了一下，組織進行 IaC 導入時經常遇到的阻礙 (詳見 thread)：
學習曲線陡峭：主流的 IaC 框架多屬於宣告式的編程模型 (
Declarative)，撰寫的 IaC 代碼描述的是想要看到的最終狀態，而不是具體達成那個狀態的步驟。
看起來貌似省下了很多繁瑣的步驟 (上帝說那裡有光於是有了光)，但如果對這些雲服務的理解不夠透徹，常常還是會丟三落四。很容易遇到，用了幾次不順手又跑回去用傳統手動敲指令的方式 (Imperative)。
複雜的相依性管理：宣告式編程較命令式編程，具有更高的抽象性，不需要詳細指定每個具體步驟。然而，這種抽象性也帶來了一個缺點：對於需要特定順序或相互依賴的操作，控制力可能會降低。特別是在複雜的雲服務架構中，基礎設施即代碼 (IaC) 可能無法完全掌控各個服務之間的佈署/移除順序 (相依性)。
規模化困難：隨著組織規模的擴大，管理複雜的 IaC 代碼庫和追蹤跨環境的變更將更為困難。與應用程式碼不同，IaC 代碼無法僅透過快速的單元測試來驗證。它需要實際運行並確認對應的資源都已成功建立，才能被視為正確。
此外，即使在同一雲端平台上，也可能因環境的細微差異而導致相同的 IaC 代碼產生不同的結果 (例：在測試環境成功部署，但生產環境卻失敗)。
.
雖然 IaC 的立意是希望透過代碼化以後，資源的創建和管理能夠變得自動化且更有效率。但是，宣告式的編程模型 [6] 和 快速變化的雲端環境，現實並不如教科書那樣美好。
.
❏ IaC 的本質
我認為我們不應該將基礎設施視為標準(應用程式)程式碼，
而是應該遵循不同的原則來管理它。我認為應用程式開發和基礎設施定義的最佳實踐有所不同，這些差異對基礎設施即程式碼產生了負面影響。
在編寫基礎設施即程式碼時，我喜歡優化的度量是「可重複性」和「可讀性」。[1]
"基礎設施即代碼" (Infrastructure as Code) 這個術語可能在某種程度上誤導了我們，使我們忽視了更為本質的問題。更為貼切的表述或許是 "基礎設施即工程" (Infrastructure as Engineering)。
與其被程式碼的概念綁架，硬要在多變的雲環境當中套用那些在應用程式碼開發上的最佳實踐，我覺得應該將更多的注意力投向如何實現特定的工程目標。
在管理複雜基礎設施時，哪些是我們想引入的軟體工程原則：
協作：促進開發和運營團隊對基礎設施的共同理解和所有權。
透明度：版本控制和可審計的變更提供對基礎設施修改的清晰可見性。
可重複性：一致和可重複的基礎設施部署，減少跨環境的錯誤和不一致。
敏捷性：更快速的配置和更容易的基礎設施實驗，加速開發週期。
滿足這些原則，一定得套用 IaC 工具 (像是 Terraform, Pulumi, 等等...) 嗎？
.
❏ 關注 IaC 的 工程原則 > 表達能力
「促進協作、增加透明度、避免重複造輪子 和 更快速的迭代」，這些好的”工程原則”雖然源自軟體工程，但是不一定要侷限於程式碼，一樣能為整體運作帶來顯著的效益。
我們嘗試換個角度看看：
✔ 協作和可讀性：
表達能力：IaC 允許團隊成員共同編寫和維護基礎設施代碼。
工程原則：這不僅是關於如何編寫代碼，更是關於如何讓代碼易於理解和維護，促進團隊協作。
Question: IaC 代碼的管理與使用單位映射是 1:1、1:N 還是 N:N。多對多的開發維運環境，適合導入 IaC 框架嗎?
.
✔ 版本控制：
表達能力：基礎設施的狀態可以像代碼一樣被版本控制。
工程原則：這意味著可以追踪變更、回滾到之前的版本，實現基礎設施的生命週期管理。
Question: IaC 的代碼回滾能夠準確的映射至基礎設施狀態的回滾嗎?
.
✔ 一致性和可重複性：
表達能力：IaC允許精確地定義基礎設施，使其可以自動化地創建和管理。
工程原則：這不僅是關於如何定義基礎設施，更是關於確保每次部署都是一致的，減少人為錯誤和環境差異。
Question: 如何能確保同一份 IaC 代碼在不同時間甚至不同環境下，都能產出一樣的基礎設施狀態?
.
✔ 效率和自動化：
表達能力：自動化基礎設施的部署和管理。
工程原則：這不僅提高了效率，還減少了人為錯誤，促進了CI/CD (持續集成/持續交付) 流程。
Question: IaC 代碼的 CI/CD 應該如何實施?
.
❏ 有所為，有所不為
回到引言所提及，是不是 landing zone 當中，所有的組件都需要進行 IaC 呢？現在我們有了一個指導性框架：
各組件的管理和使用單位的複雜度是如何?
這些組件的 IaC 代碼回滾能夠準確的映射至其基礎設施狀態的回滾嗎?
不同組件的 IaC 代碼在不同時間甚至不同環境下，都能產出一樣的基礎設施狀態?
組件是否有複用的需求，還是只是一次性的 setup?
組件的 IaC 代碼有明確的 CI/CD 流程配合嗎?
等等…
更多的關注工程原則，而不是組件是否能夠被代碼化。可以發現，IaC 只是滿足這些工程原則的其中一種手段而已。
我們所需要的 (促進協作、增加透明度、避免重複造輪子 和 更快速的迭代)，透過 更詳細的文件/操作手冊、更高的雲服務熟悉度 和 更好的分工文化 一樣也能做到。
.
❏ 結語
IaC 的本質並不在於代碼本身，而在於它所體現的工程原則
當我反思基礎設施即代碼 (IaC) 在 Landing zone 背景下的複雜性時，變得清晰的是 IaC 的本質並不在於代碼本身，而在於它所體現的工程原則。
為了抵擋 "基礎設施即代碼" 的名詞誘惑，我提出了 "基礎設施即工程"，它在實際導入的取捨上更具指導意義：專注於真正重要的核心工程原則：協作、透明度、可重複性 和 敏捷性。
"基礎設施即工程" 讓我們超越特定 IaC 工具的限制，轉而專注於通過各種方式實現這些原則 (像是 詳細的文檔、團隊專業知識 和 有效的分工)，不再為了代碼而 IaC。
在實施 IaC 時你遇到過哪些挑戰？你認為"基礎設施即工程"的概念如何能在你的工作中應用？LLM 出來以後，甚至有了 Infrastruct from Code 的概念應運而生 [4]，歡迎在評論區和我一起討論 🤓
~
🔖 參考資料
[1] Infrastructure as Code is NOT CODE - https://www.reddit.com/r/Terraform/comments/12z8p6e/infrastructure_as_code_is_not_code/
[2] Infrastructure as Code: The Good, the Bad and the Future - https://humanitec.com/blog/infrastructure-as-code-the-good-the-bad-and-the-future
[3] The Terrors and Joys of Terraform - https://medium.com/driven-by-code/the-terrors-and-joys-of-terraform-88bbd1aa4359
[4] Infrastructure as Code Is Dead: Long Live Infrastructure from Code - https://thenewstack.io/infrastructure-as-code-is-dead-long-live-infrastructure-from-code/
[5] Infrastructure as Code is Artisanal Automation - https://itnext.io/infrastructure-as-code-is-artisanal-automation-2b6b7545c100
[6] Reflections on Declarative Configuration - https://itnext.io/reflections-on-declarative-configuration-c2fe1c1e50d5