IaC 與 Terraform 三十年興衰史

故事的起點，要從一間物理系辦公室裡失控的伺服器說起。

1993 年，Mark Burgess 在挪威奧斯陸大學做博士後研究。當時系上的系統管理員正被幾十台工作站的 shell 與 Perl 腳本折磨得焦頭爛額：每台機器的設定都有些微落差，維護腳本越改越長，最後沒有人敢輕易碰觸。

Burgess 寫出了一套名為 CFEngine 的工具，並在當年的 HEPiX 會議發表。CFEngine 提出了一項根本性的概念轉向：捨棄逐步執行的指令式腳本，改為宣告「系統的期望狀態」（Desired State），由引擎負責週期性比對現況並自動修正偏差。

這套「收斂」（Convergence）理論，奠定了現代組態管理與基礎設施即程式碼（Infrastructure as Code，IaC）的思想基礎。但在伺服器仍屬實體資產的 1990 年代，這類自動化實踐多半停留在學術與頂尖科研機構，多數企業機房依然依賴維運手冊與人工操作。

雲端浪潮與 HashiCorp 的豪賭

進入 2000 年代後，網路服務規模快速膨脹，組態管理工具迎來了第一波商業化浪潮。Luke Kanies 於 2005 年 3 月將顧問公司轉型，全職投入 Puppet 開發；Adam Jacob 等人則在 2008 年成立 Opscode，並於 2009 年 1 月正式發表 Chef。

兩者都承襲了 CFEngine 的宣告式理念，透過安裝在每台機器上的代理程式（Agent），持續將套件版本、設定檔、使用者權限與服務狀態收斂至程式碼所定義的期望狀態——換言之，管的是「機器裡面長什麼樣」。

2009 年 6 月，Flickr 的 John Allspaw 與 Paul Hammond 在 Velocity 大會發表著名的「10+ Deploys Per Day」演講，確立了開發與維運協同合作的文化共識；同年 10 月，第一屆 DevOpsDays 在比利時根特登場，「DevOps」一詞自此深入產業。

2012 年，Michael DeHaan 發布 Ansible，走了一條不同的路：不需要在目標機器上安裝代理程式，透過 SSH 直接推送組態，大幅降低了導入門檻。

 Evolution of Infrastructure Paradigm (1993–2014)

 [1993 CFEngine] (Convergence)
   |
   v
 [2005 Puppet / 2009 Chef] (Config Management)
   |
   +--> [2012 Ansible] (Agentless)
   |
   v
 [2011 CloudFormation] (API Provisioning)
   |
   v
 [2014 Terraform] (Decoupled Core)

DevOps 運動確立了伺服器組態必須納入版本控制與審查的原則。然而隨著 AWS 雲端運算普及，機器可以在數秒內透過 API 憑空生成，工程團隊面臨的挑戰隨之升級：除了管理伺服器內部的組態，更需要自動化解決「這些機器從何而來」的資源佈建難題。

2011 年 2 月 25 日，AWS 推出 CloudFormation，正式將宣告式佈建帶入主流雲端。當時還是大學生的 Mitchell Hashimoto 撰文分析，稱讚其架構思維，但指出其侷限在於深度綁定 AWS，而既有的跨雲套件又僅是粗糙的 API 封裝。

Hashimoto 在該篇文章結尾寫下預言：

「CloudFormation 留下了一個空間給開源的替代方案，我希望它會出現。」

在等待數年無人投入後，他決定親自動手實現這個藍圖。

2012 年 11 月，Hashimoto 創立 HashiCorp，Armon Dadgar 隨後以共同創辦人身分加入。延續早期代表作 Vagrant 的開發經驗，團隊確立以 Go 語言開發單一執行檔的工具策略；在陸續推出 Packer 與 Consul 後，於 2014 年 7 月 28 日正式釋出 Terraform v0.1.0。

生態護城河：雙層架構的威力

剛發布的 Terraform v0.1.0 相當陽春，僅支援 AWS 與 DigitalOcean 兩個平台。在專案問世的最初 18 個月內，下載量幾乎停滯，團隊內部甚至一度評估是否該中止開發。

HashiCorp 選擇持續投入，關鍵在於團隊做出了一個精準的架構決策：核心引擎與提供者（Provider）徹底解耦。

 Terraform Decoupled Architecture

 +------------------------------------------------------+
 |                Terraform Core (HCL)                  |
 |  - Graph Engine (DAG)    - State File (.tfstate)     |
 +------------------------------------------------------+
         (go-plugin over gRPC, one per provider)
          |                  |                  |
          v                  v                  v
 +----------------+ +----------------+ +----------------+
 | AWS            | | Google         | | Custom SaaS    |
 | Provider       | | Provider       | | Provider       |
 +----------------+ +----------------+ +----------------+

在這套架構中，Terraform Core 專注於解析 HCL 設定檔、建立資源相依的有向無環圖（DAG）計算執行順序，並維護映射真實基礎設施的狀態檔（.tfstate）。Core 本身不包含任何雲端 API 邏輯，所有資源的 CRUD 操作皆透過 go-plugin 以 gRPC 通訊協定交由獨立的 Provider 二進位檔執行。

這項設計將對接雲端 API 的龐大工程轉移至邊界：任何第三方廠商或開發者，只要依循介面實作外掛，就能讓自家服務納入宣告式管理。

這意味著 HashiCorp 不需要靠自身團隊逐一覆蓋每個雲端平台——生態系會自己長出來。CloudFormation 綁死 AWS、Puppet 和 Chef 專注於機器內部組態，而 Terraform 的解耦架構讓它成為唯一一個有機會橫跨所有雲端供應商的佈建工具。這不只是技術上的優雅，而是一場以架構換取生態規模的策略豪賭。

轉捩點在 2016 年底浮現。隨著貢獻者突破 750 人、Provider 數量擴充至數十個，Terraform 下載量開始逐月翻倍。2017 年 9 月，HashiCorp 推出 Terraform Module Registry，將社群與官方範本匯整為模組化生態系。

外掛生態構築了極強的網路效應：對新興雲端平台與 SaaS 服務而言，「提供官方 Terraform Provider」成為打入企業市場的必備條件。各大廠商競相投入資源維護外掛，將 Terraform 堆疊成事實上的產業標準。

各大公有雲廠商的策略也隨之轉向：AWS 於 2019 年推出以通用語言為主的 AWS CDK，微軟推出 Azure Bicep，而 Google Cloud 則逐步淘汰自家的 Deployment Manager，改以 Terraform 作為基礎設施管理的核心後端。

2021 年 6 月，Terraform 釋出 1.0 正式版並承諾維持相容性；同年 12 月 9 日，HashiCorp 在那斯達克掛牌上市（代號 HCP），掛牌首日市值逼近 $150 億美元。

授權風暴與 OpenTofu 分叉

上市使 HashiCorp 承受了每一季交出營收成長的巨大壓力，也將其推向開源商業模式的經典矛盾。開源軟體累積了極高的工程師信任，但商業回報卻容易被周邊平台快速瓜分。

這類商業衝突在開源領域並不罕見，原作者承擔研發成本與雲端業者收割營收的矛盾屢次上演：

對 HashiCorp 而言，主要的商業威脅來自圍繞 Terraform CLI 建構的協作平台廠商（常被稱為 TACOS 平台，即 Terraform Automation and Collaboration Software），包括 Spacelift、env0、Scalr、Gruntwork 與 Harness 等。

這些新創透過提供遠端執行、狀態鎖定、PR 預覽與權限管控，直接與 HashiCorp 自家的主力付費產品 Terraform Cloud / Enterprise 競逐企業訂閱。

2023 年 8 月 10 日，Armon Dadgar 發文宣布，包含 Terraform 在內的所有產品後續版本，將由寬鬆的 Mozilla Public License (MPL 2.0) 轉為 Business Source License (BSL 1.1)，明文禁止將軟體用於提供與 HashiCorp 具直接競爭關係的商業產品。

這項決策隨即在社群與生態圈激起劇烈震盪。8 月 15 日，受影響的廠商與社群成員聯名發表「OpenTF 宣言」，要求 HashiCorp 撤回改授權決定，否則將啟動分叉。

這場紛爭展現了兩種立場的鮮明碰撞：

• 社群與生態廠商立場：Terraform 成為標準仰賴數千位外部貢獻者與整個產業共同建置的 Provider 生態。HashiCorp 在收穫生態價值後單方面改變授權條款，背棄了長期的開源承諾。
• HashiCorp 商業立場：執行長 Dave McJannet 受訪時強調，新授權對絕大多數終端企業依然自由開放，限制的對象是「在我們開拓的市場上直接獲利的競爭廠商」，並質疑外部商業對手是在借用基金會中立形象維護自身的商業利益。

雙方歧見無法調和。2023 年 9 月 20 日，Linux Foundation 正式接納該分叉並更名為 OpenTofu，獲得超過 140 個組織支持並承諾投入全職開發人力。

架構設計在歷史轉折中展現了雙刃特質：當初推動 Terraform 快速普及的「核心與 Provider 分離」架構，在此刻成為分叉專案的天然跳板。由於龐大的 Provider 與 SDK 多維持原有授權，OpenTofu 團隊僅需接手核心引擎並建置相容的 Registry 鏡像，便完整繼承了累積十年的外掛生態。

2024 年 1 月 10 日，OpenTofu 1.6.0 正式推出 GA 版本；同年 4 月，雙方歷經存證信函與程式碼來源爭議；2025 年 4 月，OpenTofu 正式進入雲原生計算基金會（CNCF）沙盒。

在風暴核心之中，創辦人 Mitchell Hashimoto 已退居第一線，並於 2023 年 12 月 14 日正式離開 HashiCorp，轉向投入更偏向公共利益與非營利託管的獨立開源專案。

巨頭收購與路線收斂

改採 BSL 授權未能完全扭轉市場對 HashiCorp 成長預期的重估。2024 年 4 月 24 日，IBM 宣布以每股 $35 現金、企業價值約 $64 億美元收購 HashiCorp，交易於 2025 年 2 月 27 日正式完成。

這項收購在 IT 自動化歷史上形成了有趣的呼應：

 The Consolidation into IBM

 [2015] Red Hat acquires Ansible
 [2019] IBM acquires Red Hat ($34B)
 [2025] IBM completes HashiCorp acquisition ($6.4B)
   |
   v
 Two generations of automation
 (Ansible & Terraform) unite under IBM.

2015 年 Red Hat 收購了組態管理代表工具 Ansible，隨後 Red Hat 於 2019 年併入 IBM；十年之後，雲端佈建時代的代表工具 Terraform 也走入同一體系。兩代引領維運典範轉移的工具，最終都在 IBM 的企業軟體版圖中匯聚。

收購完成後，Terraform 產品線展開策略收斂。2025 年 12 月 10 日，官方宣布封存 CDK for Terraform（CDKTF），停止維護以通用程式語言撰寫 Terraform 的路線，將研發資源聚焦於 HCL 核心；2026 年 3 月，HCP Terraform 終止舊版免費方案，全面改採嚴格的受管資源計量機制。

分叉三週年：兩條路線的分化

2026 年 9 月 20 日，距離 Linux Foundation 正式接納 OpenTofu 恰好滿三年。三年足以回答一個當初多數人存疑的問題：社群分叉真的能撐下去嗎？

從數字來看，答案是肯定的。OpenTofu 在 2025 年 4 月進入 CNCF 沙盒後持續成長，截至 2026 年中已累計超過 1,000 萬次下載，Registry 收錄逾 3,900 個 Provider 與 23,600 個模組。Fidelity Investments 等企業已公開分享在生產環境採用 OpenTofu 的經驗。

更值得關注的是技術路線的實質分化。OpenTofu 自 1.7 版起陸續推出 Terraform CLI 至今沒有的功能：原生狀態檔加密（State Encryption）、Provider 層級的 for_each，以及 1.10 版引入的 OCI Registry 支援；1.11 版引入的 ephemeral resource 則是例外，HashiCorp 在 2024 年 11 月的 Terraform 1.10 便已推出同名功能。

其中狀態檔加密尤具指標意義——Terraform 的狀態檔至今仍以明文儲存資料庫密碼與 API 金鑰；社群的加密訴求早在 2015 年就登上 GitHub，HashiCorp 卻在 2024 年將2016 年的正式提案以「不予實作」關閉，至今仍未解決。

市場格局則呈現「既有市場歸 Terraform，新專案歸 OpenTofu」的分裂態勢。整體 IaC 市場中，Terraform 仍以三到六成的佔有率居於主導地位。

但在部分協作平台上，OpenTofu 已承載超過六成的執行量，新建工作區的佔比也約達七成二。多數既有團隊尚未遷移，但新專案正加速流向開源陣營。

IBM 接手後的 Terraform 走向另一條路：封存 CDKTF、收緊免費方案、將企業版納入 IBM 半年一次的發行節奏，並在 2026 年 5 月推出以視覺化基礎設施圖譜為核心的 Infragraph 公開預覽版，試圖在可觀測性層面建立新的付費價值。

三年前的架構預言在此得到印證：核心與 Provider 解耦的設計，既是 Terraform 建立十年標準的關鍵，也是分叉專案得以迅速獨立的根本原因。當初為生態規模而生的架構，最終也讓生態擁有了選擇離開的自由。

尾聲：IaC 是維運自動化的終點嗎？

在 Terraform 授權爭議與歸屬塵埃落定之際，基礎設施領域也浮現出更深層的架構省思：以靜態文字檔案宣告狀態的 IaC 典範，是否已接近其能力的邊界？

靜態檔案的天花板

昔日 Chef 共同創辦人 Adam Jacob 提出了最具代表性的質疑。他在 2019 年創立 System Initiative，並在產品發表時直言：

「我們一直在走的這條路，也就是用建構應用程式的同一套方法和工具來建構基礎設施，是一條技術上的死路。」

Jacob 的論點直指 IaC 的運作核心：在 Terraform 的模式中，工程師將基礎設施的期望狀態寫成靜態的 .tf 檔案，存入 Git 儲存庫作為唯一真相來源（Source of Truth），再透過 plan 比對差異、apply 執行變更。

問題在於，真實的雲端資源不會乖乖等著你下指令。有人透過管理主控台手動修改了安全群組規則、Auto Scaling 自動增減了機器數量、雲端供應商悄悄升級了底層元件——這些變動都發生在 Terraform 的視野之外。

當 .tf 檔案所宣告的狀態、.tfstate 所記錄的快照，與雲端的實際狀態三者開始不一致，就產生了所謂的狀態漂移（State Drift）。

漂移在 Day 1（初始佈建）時尚可控制，但進入 Day 2——也就是監控、擴縮、升級、事件回應等持續維運階段——落差只會越滾越大。工程師得反覆執行 terraform plan 偵測漂移、決定要修改程式碼還是強制覆蓋現狀，這套來回循環逐漸成為維運的同步瓶頸。

Jacob 主張，根本的出路不是寫更好的靜態檔案，而是換掉整套互動模型：以即時雙向連線的「數位分身」（Digital Twin）取代傳統的 Plan/Apply 流程，讓工具持續反映真實狀態，而非僅在人類按下按鈕時才檢查一次。

回顧從 1993 年奧斯陸大學的 CFEngine，到 Terraform 的崛起、分裂與被收購，基礎設施工程的核心課題始終沒有改變：如何建立可靠的抽象機制，馴服底層系統的動態複雜度。

Terraform 靠著精巧的外掛解耦架構，建立了長達十年的產業標準；但也正是這套將控制權分散在 Provider 生態中的設計，註定了任何單一公司都難以永久壟斷其成果。

無論未來基礎設施管理是走向即時動態模型、程式碼宣告，還是由 AI 驅動的自主流程，這段三十年的演進史都清楚表明：決定一項底層工具生命力的關鍵，從來不只是語法或功能，而是其架構能否長期維繫開發者、生態夥伴與商業利益之間的信任平衡。