這文章至少值一千元，因為這是我保守估計花出去的冤枉錢（請自行腦補一個苦笑的 emoji）
文章中會穿插選擇雲服務的一些建議，當然也會提供一些“薅羊毛”的技巧。不過在此之前我們要想清楚一件更重要的事情：我為了什麼購買雲服務
做產品還是做技術
這個問題不僅決定了你接下來的購買策略，還是你編碼開始的前提。
以技術為出發點想達到的目的是：我想把程式碼寫對（先學會），並且把程式碼寫好（然後精通），程式碼是一切工作的出發點， 編碼過程中的困難越多越好，能夠遇到的業務場景越複雜越好，對行業內的最佳實踐越熟悉越好，收穫和實際投入的程式碼量成正比。
如果從產品側看，好程式碼不等於好產品，驗證想法的可行性才是當務之急。在有使用者買單前，人天、機器、程式碼都是沉默成本，對於個人開發者而言這些都是自掏腰包承擔的損失，所以從做產品出發“快”其實是最高優先順序。我相信你或多或少體驗過這類技術與產品的矛盾：高質量的程式碼離不開時間投入，但時間又是一款產品“跑馬圈地”最大的敵人——這樣的選擇一點也不難，公司會毫不猶豫的犧牲前者，如果你在網際網路創業公司工作過一定更加深有體會。產品與技術並非二元對立，你依然可以在開發產品的過程中可以刻意熟練某項技術，只不過同時身兼產品和程式碼作者的你需要小心計算成本和回報。
正如標題所示，本文所處視角是個人（獨立）開發者。對於這類群體而言，雖然他們自帶編碼天賦點，但是把一款產品運營好遠比寫出完美程式碼重要，也就是說在本文裡“雲”所服務的首要物件是產品。
一旦接受了產品優先的前提，你就要開始嘗試“克服”各種程式碼潔癖，學會接受開發產品中的各種不完美。假如回到兩年前給我機會重寫 site2share，編碼實現上我會做大量裁剪，例如：
- 使用原生 SQL 語句而不是 ORM 做資料儲存
- 不寫測試
- 不做 CI/CD，而是選擇本地編譯、人工壓縮、手動上傳部署
如果你還是不能理解我為什麼推崇各類顯而易見的反模式，讀下去就知道了
購買哪些服務
正確的提問題應該是遞進式的：
- 產品的哪些功能是需要服務支撐的？
- 這些服務我可否自行編寫？
- 如何判斷又或是我應該購買自第三方？
從 MVP(Minimum Viable Product) 開始
我們要藉助產品思維回答這個問題。假如你的網站需要登陸功能——等等，你的網站真的需要登陸嗎？
考慮到個人有限的人力和財力，我的建議是在編碼前，你需要清晰的認識到網站哪些功能是必須實現 (Must have)， 哪些又是可有可無的 (Nice to have) 的。之所以提前給你打這支預防針，是因為絕大部分產品在壽終正寢之前被人們看到的機會都極其有限，不確定性的投入大機率會造成浪費。不妨看看下面兩個例子。
ProductHunt 是一個行業內知名的網際網路產品釋出平臺，如果保守估計每天有十款產品在此釋出的話，在過去一年中全世界至少上線了3650款新產品——而你回憶一下在過去的2022年裡，有任何一款新應用讓記憶尤深嗎？
再回到 site2share 的例子上，根據 google analytic 統計，過去一年內至少 3000 名新使用者訪問了我的網站，但實際使用 google 郵箱進行 OAuth 登陸的使用者只有47人。今年恰逢 Google 催促我將 Google Authention SDK 升級，又考慮到後續的維護成本（比如硬體上購買 Azure Redis 每個月就需要花費15美元），我選擇將登陸功能徹底下線
回到登陸功能上來，如果確認它是完整功能的一部分，在購買基礎設施支撐它之前，還應該想想買是不是唯一的方式：
- 如果登陸是為了儲存個性化資料，能否採用類似於excalidraw 本地快取（比如 localStorage）方案解決？
- 如果需要後端儲存個性化資料，那麼登陸功能我們能否採用輕量級實現，比如整合 OAuth 而非從零開始搭建賬號體系
- 如果確認使用 OAuth，直接選擇 Auth0 是否是更好的選擇？
Auth0 的免費版本支援最多7000名註冊使用者無限次登陸。也許你會問7000名使用者之後該怎麼辦？我不知道，那是我還沒走到過這麼遠。不過我猜真到那個時候，深思熟慮的使用者體系應該被提上議程，資金和人力都不再是問題。不過在此之前，先活下去。
衡量隱藏成本
錢不是問題，問題是沒錢，所以才會有這篇文章。但是除了錢以外，大家往往會忽略時間上的付出。長遠看創作成本不佔程式碼成本的大頭，維護成本才是。
舉個例子，假如你現在需要做爬蟲，必須要用到代理池，是應該自己搭建還是購買代理池？
市面上已經有很多的代理池開源專案了，比如這個 proxy_pool 。代理池的原理非常簡單，本質上它是一個聚合服務，替你去抓取網際網路上公開的代理庫然後儲存在一起。回到這個問題上，我傾向於購買現有的代理服務而非自建，以部署這個開源專案為例，自建會給我帶來以下困惱：
- 需要重新撿起 Python 和 Docker，這是學習成本
- 我的 web 服務是部署在 App Service 上的，如果要將 proxy_pool 部署為獨立服務，需要額外購買虛擬機器
- 服務的安全、測試、維護、監控成本
- 需要額外的開發工作量對 IP 做再次有效過濾，因為公共 IP 庫通常質量不高，無法滿足抓取指定網站的需求和 web 服務進行聯調
如果你把你的工資按照小時換算，乘以一下未來相當長一段時間投入在上面這些工作的時間，可能直接把這筆錢買一個適用的代理服務更划算。因為代理池目前是一個非常成熟的產業，行業內有大筆的成熟玩家。以最大的 bright data 為例，它不僅可以更細分的提供代理 IP，還可以替你把程式碼寫了，直接提供抓取服務 API，並且支援在瀏覽器內除錯：
bright data 可能存在一些准入門檻，但你總可以在行業內找到適合於你的“平替”，出於競爭考慮大家提供的服務都類似，比如對我來說我覺得 Geonode 的代理服務可能更適合我。
我想表達的是，不一定不花錢就等同於免費，別忘了需要把隱形成本計算在內。話說回來手動搭一個還是能學到不少東西的，也可以算是當作學費了吧。但我在這裡的立場還是從產品出發，fast 很重要，無論是 move fast 還是 fail fast
買什麼配置的服務
在確定購買雲服務之後，接下來的問題是應該購買什麼配置的雲服務。我自己對雲服務有個不正經的分類：託管型（managed）和非託管型（non-managed）。簡單來說非託管型不提供你基本需求以外的額外價值，例如你需要伺服器，那它能提供給你的真只有一臺（虛擬機器）伺服器而已，DigitalOcean 的 Droplets 或者是 阿里的 ECS 都屬於這種型別，這些產品型別下還會有子類，比如CPU最佳化型、記憶體最佳化型。有的在購買時你可以選擇預裝的系統或者執行時環境，但本質上它們依然是伺服器，不關心你將來要用它們做什麼。
相反，託管型除了能夠滿足你程式的基本需求以外，它還提供更多的額外服務，比如 Digital Ocean 的 App Platform 在首頁展示的 slogan 便是 "Fully-managed infrastructure"，提供了包括直接從 GitHub 部署、應用監控、日誌分析等功能，以我現在正在使用的 Azure App Service 為例，在介面上我可以使用到以下功能：
但問題是，你的應用支撐得起這麼多功能嗎？沒錯，我問的是你的應用能否支撐的它？
我所購買的是最低配置套餐 Basic B1, 它提供的記憶體容量是 1.75G。但根據 app service 服務提供的監控統計，我的應用常年使用的記憶體（memory working set）只需要140MB。想當然硬體基礎設施在相當長一段時間內都足以保證功能的正常執行。所以我不需要 Monitoring 裡的對於基礎設施的報警 alert （執行 alert 也需要額外花費），也不需要在選單欄上常駐一個升級硬體用的 Scale up 按鈕。而關於應用級別的監控，我可以利用第三方的免費服務 UptimeRobot：
再比如以 Deployment slots 為例，它提供的是多環境部署機制：你可以先建立一個 Staging 環境，將即將上線的程式碼部署其中，在測試無誤之後，一鍵將 Staging 環境程式切換為 Prod 環境。但是作為小本經營的個人開發者，準備隔離的多個環境其實是奢侈的一件事（比如隔離的資料庫環境），並且作為冷門應用當機部署以及直接用線上環境試錯也是可以接受的——deployment slots 也不是剛需。
所以關於應該購買何種配置的雲服務，我的答案是夠用就行，擴容便利。如果 Digital Ocean 上4美元一個月記憶體只有 512MB 的虛擬機器能夠執行你的應用，那買它就好了。至少在專案初期託管型服務帶來的效用沒有那麼明顯，但如果有一天現有的基礎設施支撐不住流量了，保證擴容不應該是舉步維艱的一件事就好。
免費的怎麼選
“免費”的雲服務比我們想象中的要多——打引號是因為這個說法並不準確，大部分服務只會在一定限額內免費，只不過個體開發者“薅羊毛”的行為大部分情況下達不到免費的上線額度而已。
我以 阿里雲效、Azure DevOps、GitHub Actions 三個免費 DevOps 工具為例，說明我認為應該如何選擇的選擇免費 CI/CD 工具，優先順序從高到低
- 熟悉程度：“快”是本文的主題。如果有任何的工具是你已經在日常工作中熟練使用的，它就是首選
- 選擇生態：所有的雲服務最好都來自同一家提供商。如果你的應用部署在 Azure 上，那麼用 Azur DevOps 是最好的選擇。它天然會提供較好的支援，例如會內建機制便於你一鍵將流水線連線到雲服務
- 附加價值：Github Actions 最為純粹它聚焦於 CI/CD。但另外兩者還同時提供團隊協作、專案的管理功能，因為它們倡導的是 DevOps 價值而非僅限於流水線。雲效甚至還能和阿里生態進行結合，比如釘釘。在我使用 Azur App Service 的過程中，我發現它預設提供日誌收集工具 Application Insights 非常好用，幾乎可以滿足你對日誌工具的一切幻想：支援多種程式語言、同時支援前後端以及分散式追蹤、主動採集，還有（部分）免費
- 開發體驗：包括和第三方整合的難易程度，對排查問題是否友好等等。提一點：雲效的 UI 很棒，還可以提供免費的人工的諮詢服務，但是卻不支援 IaC （Infrastructure as code）。對我來說 IaC 更加重要。
- 核心功能：CI/CD 流水線作為業內標準的，大家已經領悟的很透徹了。這方面無需多慮，差異不大。
- 行業地位：這個參考條件並非針對這三者而言的，在這個領域內差別不會太大。但是其他雲服務，比如靜態資源託管，我的經驗是 Netlify 會比 Azure Static Web Apps 體驗更好，提供的服務也更多更專業。例如可能考慮到許多人會使用 Netlify 託管單頁面應用，它們還提供表單功能。你可以在你的網頁上整合表單提交到它們給出的指定地址上，它們會自動為你收集整理。當然也有免費的第三方服務 FormKeep 可供選擇
書籍推薦
如果你真的有興趣製作自己的應用，有兩本書值得推薦：《重來》(Rework)就不說了，我印象中都出版有十年了，basecamp 團隊經典著作。它帶來的更多是精神支援和抽象的意見。
《The Indie Maker Handbook》是我在 Product Hunt 上發現的。它更偏向實戰，比如你應該如何釋出，在釋出，什麼時候釋出你的產品。作者自己也是一款從 Product Hunt 上發跡產品的創始人。
你可能也會喜歡：