作者 | 李宇飛
1
導語
我們生活在開發工具的黃金時代，隨著雲原生時代的來臨，以及組織程式碼規模的擴張，不斷出現的新開發模式又引入了新的複雜性，從而使得新的開發工具紛紛湧現。
InfoQ 在今年三月份釋出了一篇譯文《構建開發工具正當時》，這篇文章深刻地剖析了軟體開發的生命週期，並舉例說明了開發工具在每一個生命週期中所發揮的價值。
本文將在《構建》一文的基礎上，以工具開發從業人員的視角，介紹雲開發工具這一領域的時代背景、價值和發展趨勢。
撰寫這篇文章的目的是：希望有更多人瞭解雲工具產品研發這一小眾的技術領域；希望該領域的從業者們，能夠有更好的生存土壤；也希望熱愛這一技術方向的小夥伴們，能夠感受到你並不孤單。
2
時代背景
自從三年前，我加入了一家雲計算公司，從事工具鏈產品研發，成為了一名光榮的“工具人”。從那時開始，我始終關注業界動態，關注著國內外相關領域蓬勃發展。
在今年的三月份，我讀到了一篇文章《構建開發工具正當時》，由 SourceGraph 的 Co-Founder Beyang Liu 撰寫，文中提出了一個非常棒的觀點：
長期以來，軟體一直被認為是技術進步的助推器，而開發工具是技術進步的二階助推器（助推器的助推器）。
開發工具作為二階助推器的價值已經在雲計算行業中得到充分體現：
一方面體現在雲計算所帶來的規模效應上，開發工具對於開發成本的最佳化，以及軟體交付效率的提升，可以透過客戶得到千百倍的放大，為客戶帶來巨大的經濟價值，從而間接為雲提供商貢獻收入。
另一方面則是由於近些年來雲原生技術架構的興起，如鮮花著錦、烈火烹油，在這種新的開發模式中，基礎設施的重要性被提升到了前所未有的高度，開發和運維之間的隔閡被打破，二者可以採用相同的宣告式語言來構建軟體基礎架構，這帶來了新的機遇和挑戰。
而這一領域的開源組織和企業也展現出了蓬勃的生命力：
近年來，以 CNCF 為代表的雲原生社群與組織，構建了一系列的開源工具，來幫助開發者完成軟體構建的生命週期，涵蓋了《構建》一文中提及的“編寫、測試、評審、部署、監控”這五個階段。
Hashicorp E 輪 50 億美元的估值，則代表了獨立工具廠商的興起，以及它們在商業上的成功。隨著多雲時代的來臨，採用多家雲服務提供商已經成為了屢見不鮮的事實。中立的開源軟體供應商，一定程度上促進了工具類產品價值的自由流動，從而也承載了巨大的商業價值。
雲服務提供商，為了向開發者提供更好的服務，則紛紛投身於各種開源軟體的貢獻中，例如在 CNCF 的專案中，能看到許多雲廠商的身影。
構建開發工具的黃金時代，已經悄然來臨！
3
價值
每當我們開發一款新的工具時，都會面臨這樣的靈魂拷問：“你的工具能帶來什麼樣的價值”？
價值模型
工具類產品的
價值模型
，可以從兩個方面來看待：
對採用者的價值
：對於工具的採用者來說，開發者工具作為軟體開發的二階加速器，改進了現有的
開發模式
和
生產關係
，產生了
效能
，支撐了企業的擴張；擴張的企業用
規模效應
產生
邊際效益
，反哺了開發工具的投資，從而產生
飛輪效應
。
對服務提供商的價值
：對於雲服務提供商來說，一方面雲開發工具可以降低使用者的採用成本，從而間接影響使用者的決策，形成廠商間的競爭優勢。另一方面，雲服務商透過為流行的開源工具，編寫大量的廠商整合程式碼，可以獲取天然的使用者池，並且使用者池規模會隨著時間的推移而形成自然的增長。
增長邏輯
雲開發工具類產品的
增長邏輯
，與常規的商業產品有很大的不同，它的理念從根本上更接近於開源社群的“禮物文化”。這個概念來自於知名開源技術作家 Eric Raymond 的《大教堂與集市》一書，是指開源社群的貢獻和贈予是一種非零和的博弈。開發者工具的開放並不會給雲廠商造成經濟上的損失，反而可以獲得聲譽、品牌影響力上的回饋。
雲服務提供商透過將自己的服務，整合到流行的開源工具中，使得工具的採用者能夠使用自己熟悉的工具來管理雲服務。對於雲廠商來說，可以獲取更多的潛在使用者。而對於開源工具的創造者來說，來自服務提供商的幫助，可以使工具擴大影響範圍，拓展能力的邊界，並擁有積極的貢獻者。
就像《大教堂與集市》中提到的，開源世界構建在一種“禮物文化”之上，而非一種零和的商業競爭，雲廠商貢獻自己的力量，而社群回饋以潛在的使用者群體，從而實現一種雙向的贈予。
服務提供商整合自身雲開發工具的增長驅動力，主要由以下三個部分構成：
自然增長
：當流行的工具生態擴張時，廠商的
潛在使用者池
也將隨之產生自然的增長，滿足了服務提供商本身使用者規模擴張的訴求。
內生增長
：由於工具能夠顯著降低使用者的採用成本，廠商內部進入工具生態的產品，具有天然的增長優勢。從而產生為更多
服務品類
提供工具支援的內生訴求。
外部增長
：廠商是否提供使用者所熟知的工具，對於許多使用者來說是一個不容忽視的成本指標，能顯著影響使用者的採用決策。從而使使用者向服務提供商提出了擴張
工具品類
的訴求。
因此，
潛在使用者池
、
服務品類
和
工具品類
的擴張，共同構成了開發者工具增長的基石，為開發者工具的增長賦予了價值和意義。
4
機遇與挑戰
面向雲的開發工具，已經具有很長的歷史，但整體看來，雲開發工具仍是一個新興的領域，依然面臨著許多機遇與挑戰。本節將以雲資源管理為例，帶領大家直觀感受一下，開發者工具是如何從專有領域走向通用領域，最終與軟體開發融為一體。
雲資源管理工具的設計目標是解決兩個問題：一個是對
資源的生命週期的管理
，例如資源的增刪改查、對依賴關係的管理；另一個是對
多雲的支援
。
雲資源管理工具的發展歷史比較長，大體看來可以分為三個階段，每一個階段都面臨著各自的問題和挑戰：
第一階段：使用通用程式語言和工具直接呼叫 API
（SDK、CLI）。在這一階段，使用者採用 SDK 來直接呼叫 API，從而管理資源的生命週期，這常常適用於最小化的概念驗證與原型開發。這種方式的潛在問題是，當面臨多個雲供應商的時候，每一個供應商的 API 和 SDK 千差萬別，從而存在額外的啟動成本，並且成為基礎設施規模發展速度的限制性因素。
面向特定廠商
的基礎設施研發，是這一階段的特點。
第二階段：基礎設施即程式碼
（IaC，Infrastructure as Code）。這一階段的方案，透過將多個雲供應商集中抽象為一種拓撲描述的文字格式，幾乎可以管理任何資源而無需學習新的工具，降低了雲服務商的採用成本。並基於此實現了基礎設施即程式碼（IaC）的理念，使得基礎架構能夠和專案原始碼一同管理和交付。但這種方式帶來了一個新的問題，即基礎架構描述檔案的可複用性和可測試性受到了工具本身描述能力的限制，大家會發現，描述基礎設施所用的 DSL，越來越像一門通用的程式語言，支援模組化、控制流等語句。那麼我們為什麼不直接用通用的程式語言來進行資源管理呢？
面向特定語言 / 架構風格
的基礎設施研發，是這一階段的特點。
第三階段：基礎設施即軟體
（IaS，Infrastructure as Software）。這一階段的工具採用通用程式語言（例如 Python、Go 等）來進行資源管理。與第二階段的方案類似，它們同樣遮蔽了多雲管理方式的差異，與此同時，由於該階段的方案採用通用程式語言，從而消除了學習 DSL 的成本，並藉助主流程式語言的成熟工具鏈，可以很方便地進行抽象複用、靜態分析、測試等等。基礎設施
與特定的廠商和架構風格解耦
和應用軟體融為一體，是這一階段的特點。
在這一技術領域演進的過程中，湧現出許多概念：
宣告式（Declaritive）API
。宣告式 API 區別於命令式（Imperative）API，命令式 API 透過編排對系統狀態的操作步驟，來完成最終系統狀態的變換。宣告式 API 則致力於透過描述系統的期望狀態，透過自動化的調和來使系統達到最終狀態。一個典型的例子如 Kubernetes 的 Operator，使用者建立和更改所需的資源描述檔案，Operator 透過一定的調和邏輯盡力而為地使基礎設施推進至期望的狀態。
不可變基礎設施（Immutable Infrastructure）
。不可變基礎設施是指當基礎設定被建立後就不能進行任何修改操作。比較典型的例子是容器應用的最佳實踐，每當應用需要更新時，建立新的例項以替換。不可變基礎設施使得變更的狀態是清晰和明確的，可以快速升級、回滾和重建一個特定的環境。
基礎設施即程式碼（IaC, Infrastructure as Code）
。IaC 是一個相對較舊的概念，但隨著近年來雲原生和一些流行的 IaC 工具的興起，IaC 成為了雲時代的重要技術。IaC 不僅僅指“將基礎設施以程式碼的形態表達”，更重要的是，將程式碼世界中的一些軟體工程的最佳實踐和原則，應用到基礎設施的管理中。例如模組化、測試技術等。
基礎設施即軟體（IaS, Infrastructure as Software）
。IaS 是 IaC 的一個例項，IaS 是指透過通用程式語言來宣告資源，編寫基礎設施程式碼。IaS 可以使基礎設施與應用本身能夠複用相同的工具鏈，打破 Dev 和 Ops 之間的隔閡，在抽象層次，可測試性方面取得根本性的飛躍。
GitOps
。GitOps 是一種採用 Git 來管理基礎設施（infrastructure）和配置（configuration）的程式設計實踐，通常認為由 Weaveworks 提出，其核心在於使 Git 作為基礎設施和應用的單一事實來源（trusted source），受版本管理。當 Git 中的內容變更時，基礎架構和應用也隨之自動變更和交付。宣告式 API、基礎設施即程式碼是 GitOps 的基礎。
這裡介紹幾款典型的雲資源管理工具：
CFEngine。CFEngine 是最古老的配置管理工具之一，於 1993 年釋出。CFEngine 最初是其作者 Mark Burgess 的一個研究專案，在發展的過程中實踐了非常多的學術理論，並引發了後續配置管理領域的相關研究。
Puppet。Puppet 是一種開源的配置管理軟體，於 2005 年釋出。Puppet 基於一種宣告式的程式語言來描述系統配置。
Chef。Chef 是一種開源的配置管理軟體，於 2009 年釋出。透過使用 Chef 工具，可以集中式的管理伺服器叢集。除此之外，Chef 還提供了一系列周邊工具，例如可以採用 Chef InSpec 編寫面向基礎設施的合規策略。
Ansible。Ansible 是一種開源的配置管理軟體，於 2012 年釋出。Ansible 可以透過編寫 YAML 格式的配置來編排自動化過程。Ansible 是最流行的配置管理工具之一，有著大量可複用的程式碼和非常廣泛的服務提供商支援。
SaltStack。SaltStack 是一種開源的配置管理軟體，於 2011 年釋出。SaltStack 的特點是基於事件驅動的設計，以及由豐富的遠端執行模組構成的中心化管理能力。
Terraform。Terraform 是 Hashicorp 出品的一款多雲資源編排工具，於 2014 年釋出。Terraform 採用一種名為 HCL 的 DSL 來描述基礎設施。Terraform 是最流行的多雲資源管理工具之一，基於圖的結構使它能夠高效地處理資源之間的拓撲依賴關係，目前支援 200+ 軟體和服務。
Pulumi。Pulumi 也是一款流行的資源管理工具，於 2017 年釋出。Pulumi 採用多種通用程式語言來進行資源管理，並透過名為 Crosswalk 的子專案，實現與 Kubernetes 的互操作，目前支援 5 種程式語言。
cdktf、cdk8s。二者分別由 Hashicorp 和 AWS 推出，它們構建在 Terraform 與 Kubernetes 之上，實現了一個轉換邏輯，可以使用多種通用程式語言來生成二者所需的資源定義檔案，從而使基礎設施可以採用通用程式語言來編排。
其中，配置管理工具和 Terraform 是 IaC 概念的典型代表，Pulumi 和 CDK 則專注於實現 IaS，他們共同構成了 GitOps 的最佳實踐。
回看這二十多年，從 IaC 到 IaS，象徵著 Dev 和 Ops 之間的牆在一定程度上被打破。從單一的廠商 / 技術棧，到多供應商、多架構風格的轉變，象徵著開發者工具對於軟體價值自由流動所起到的推進作用。它們共同構成了工具類軟體對於生產模式和生產關係的變革，雲資源管理工具這一領域方向，正是開發者工具行業的一個縮影。
本節較為完整地介紹了雲資源管理工具這一熱點技術方向。還有很多領域和專案未曾提及，例如持續交付，可觀測性、策略即程式碼、沙箱執行時等等。並不意味著它們不重要，而僅僅是篇幅所限，歡迎大家一起交流。
5
總結
本文從一個雲開發者工具產品從業人員的個人視角，介紹了雲開發工具領域的背景、價值和發展趨勢。
開發工具作為軟體的“二階助推器”，在雲原生時代的重要性愈發凸顯，開源社群與廠商紛紛投身於工具的研發當中。工具能夠解除供應商鎖定，提高工程效率，使企業和雲服務提供商在商業競爭中搶佔先機。
在雲原生時代的浪潮中，到處都可以見到開發工具的身影，多雲管理、API 構建、以至於軟體交付、工程效能、安全合規等領域，都將成為這一技術方向的機遇和挑戰。
雲開發工具的時代已經來臨，你準備好了嗎？
你在從事哪些工具的開發，歡迎留言。
附錄：
《構建開發工具正當時》： https：//www。infoq。cn/article/toataglje5qf5ovd2yct
Blog： Beyang Liu： https：//beyang。org/
News： Hashicorp E 輪 50 億美元： https：//techcrunch。com/2020/03/16/hashicorp-soars-above-5b-valuation-in-new-175m-venture-round/
《大教堂與集市》： https：//book。douban。com/subject/25881855/
作者簡介：
李宇飛
，目前從事雲計算工具鏈產品研發，關注雲原生、基礎架構和軟體分析等領域，歡迎同行交流。
