對我來說,說「我從2018年就開始從事基礎設施視覺化」並非吹噓——這是事實。那一年,我加入了一家位於波特蘭的優秀新創公司Stackery ,該公司採用基礎設施即程式碼(IaC)技術,產生如下所示的架構圖:

它的秘訣在於雙向操作:拖放資源,即可獲得可部署的 IaC(基礎設施即程式碼)。雖然這家新創公司自 2021 年起就已不存在,但你仍然可以體驗它的線上編輯器;)
我為什麼會提起這段往事呢?嗯,Stackery 後來被 AWS 收購了(我現在可以這麼說,因為我已經不在 AWS 工作了),並成為了AWS Infrastructure Composer (前身為 Application Composer),它將基礎設施視為程式碼,並產生如下所示的架構圖:

而且它還支援雙向操作:拖放資源,即可獲得 CloudFormation 模板,然後進行部署。更重要的是,它提供了一種強大的方式,可以直觀地理解構成無伺服器服務的分散式系統以及它們之間的互動方式。
如今我在 Stripe 工作,它不是雲端服務供應商,所以人們可能會認為在我的新工作中沒有視覺化 IaC 的用例。
這種情況一直持續到上個月, Stripe Projects發布後,Stripe CLI 突然變成了建造任何東西的工具!
借助 Projects,任何人都可以使用 Stripe CLI 從快速擴展的供應商目錄中配置服務,涵蓋託管、身份驗證、人工智慧、資料庫等等——幾乎可以滿足業餘愛好或實際應用所需的一切。不過,更常見的情況是,使用者使用 CLI 設定代理,並發出「建立執行 X 操作的應用程式」的指令,代理可以辨識出此用例需要資料庫,並直接透過 CLI 進行配置,一切都如預期般順暢。
所以現在我們有了一個由多個服務組成的應用程式,這些服務的複雜性越來越高,開發人員可能並不完全理解——對於經歷過#believeinserverless時代的人來說,這聽起來是不是很熟悉?
我最近使用 Projects 為我的團隊建立了一個轉錄應用程式,並在這裡記錄了整個過程:從初始化到部署。儘管該應用程式相當簡單,只使用了 Vercel 和 OpenRouter 這兩個供應商,但我仍然認為視覺化功能對於任何想要參與開發的團隊成員都會很有幫助,因此我花了一個下午的時間,有點瘋狂地建置了一個stripe-projects-visualizer應用程式。
該應用程式會查看專案的.projects/state.json檔案(它是專案已配置服務的真實來源),分析提供者環境變數在整個程式碼庫中的使用方式,並產生一個架構圖,顯示已配置的服務如何連接以及資料如何在它們之間流動。
例如,這是我的轉錄應用程式產生的流程圖:

這個工具酷炫又實用嗎?當然,我希望如此。它缺少功能嗎?當然,但考慮到它所花費的時間,缺少的功能並沒有想像中那麼多。我花了一個下午開發它的最大收穫是:我竟然能做到。
Stackery 由六位工程師耗時多年打造維護。 Infrastructure Composer 最初由五位工程師起步,後來擴展到近十二位工程師外加一個用戶體驗團隊,但即使是 2022 年 re:Invent 大會上發布的初始預覽版也耗費了超過九個月的密集開發。之後,我的前團隊又花了一年時間重新架構了 canvas 部分,使其更具可移植性和可擴展性。
Stripe 專案視覺化工具只花了一個人一個下午就開發完成了。我明天可能就能發布它的 Web 應用程式版本。這和我八年前的情況完全不同。也和八個月前截然不同,那時我還在摸索著使用 Kiro 和 Claude Code 來改進 Infrastructure Composer 的底層 canvas 技術。
我差點把這篇文章的標題定為“從數年到數小時的可怕現實”,因為在某些方面(那些我非常想保住飯碗的方面),這確實很可怕。安全方面也是如此,儘管我的對抗代理向我保證我的程式碼庫中沒有任何安全漏洞(呼!)。
但這同時也令人興奮,因為原本需要數年時間或根本無法啟動的專案,現在至少有機會以粗略的形式存在,供團隊進行完善和維護。
所以我想我也要加入這場既驚險刺激又令人興奮的旅程了。
如果您也想這樣做,不妨試試 Stripe Projects:
brew install stripe/stripe-cli/stripe && stripe plugin install projects
然後,想像一下你那令人驚嘆又無比震撼的作品:
npx stripe-projects-visualizer visualize
讓我們看看你能想出什麼主意!