SaaS 初創公司如何選擇合適的雲基礎設施

語言: CN / TW / HK

Gartner 預測 ,到 2022 年,雲應用方面的投入將達到 4820 億美元,這是雲端計算向不同行業滲透的一個重要指標。但令人感到擔憂的是雲遷移的失敗率。目前,各階層企業的這一比例在 44%到 57%之間徘徊,這給預算緊張的初創企業帶來了很大的壓力。

軟體即服務(SaaS)初創企業也不例外。作為一名解決方案架構師,多年來我一直在設計 SaaS 應用程式,我看到了初創企業在努力地尋找合適的雲基礎設施,並改進他們的產品。

這些經歷促使我寫了這篇文章,並將其作為一種工具幫助公司做出務實的基於事實和資料驅動的決策。

在開始討論雲端計算解決方案之前,我們需要了解每種解決方案提供的抽象級別,因為它直接影響了管理成本。更高級別的抽象提供更少的控制、更低的效能輸出,並增加了成本,但涉及的工作量更少,利用率更高。

如果你正在構建 SaaS 產品,首先需要購買和採購硬體。然後,你需要在硬體上安裝作業系統,再安裝 JVM、v8 和 Python 等執行時。之後,你需要安裝所有的依賴項,最後再部署程式碼。

雲基礎設施解決方案

現如今,每一種可用的基礎設施解決方案都至少抽象了一兩項以下這些東西。

雲虛擬機器(IaaS)——它們主要對硬體層進行了抽象,你不需要配置任何物理裝置,但仍然需要構建其他層。這將為你提供最大程度的控制,但需要花費更多的時間來設定,如 EC2、Azure VM、谷歌雲平臺(GCP)。

平臺即服務(PaaS)——它提供了位於硬體之上的另一層抽象,你不需要擔心作業系統/容器、升級、安全等問題,如 Azure PaaS、AWS Elastic Beanstalk 和 GCP PaaS。

無伺服器(函式即服務,FaaS) ——這是抽象了執行時的 PaaS。在這個抽象級別,你不需要操心執行時,如 AWS Lamda、 Azure Function 和 Google Cloud Functions。

低程式碼——除了硬體、作業系統和執行時之外,你還可以獲得依賴項管理的抽象,如 Parse。你需要認真思考最佳實踐。

Kubernetes(容器編排)——如果你一開始選擇了 Kubernetes,或者在 Kubernetes 即服務(EKS)達到生產就緒狀態時使用了它,那麼你將以 Pod 的形式釋出程式碼。從抽象的角度來看,它類似於無伺服器,但仍然提供更大程度的控制。

零程式碼——有一些平臺和服務可以讓你在不寫任何程式碼的情況下建立應用程式。然而,這並不意味著你不需要開發人員。它們可用於交付快速原型、MVP 和初始引導程式碼,如 Zoho 或 Quick Base。我們不打算在本文中討論零程式碼平臺。

現在讓我們深入討論一下影響結果的關鍵因素。

影響 SaaS 應用程式基礎設施的 7 個因素

因素 1:管理開銷

首先需要考慮的是公司管理基礎設施的能力,包括時間、日常管理是否需要人力,以及產品對未來變化的適應性。

如果產品的主要使用者是企業,並且需要定製,那麼可能需要多次部署產品,這可能意味著基礎設施管理員需要花費更多的精力和時間。部署可以自動化,但自動化過程要求產品穩定性。對於早期產品,ROI 可能不會太好。在這種情況下,我的建議是使用託管服務,比如用於基礎設施的 PaaS、用於資料庫/持久化的託管服務,以及用於計算的 FaaS/無伺服器架構。

因素 2:上市時間(TTM)

實現快速 TTM 的關鍵是快速開發、測試和釋出。快速開發到快速釋出的關鍵是將更多的時間花在編碼和測試上,而不是配置和部署上。低程式碼和無程式碼平臺都是不錯的選擇。無伺服器和 FaaS 被設計用來解決這些問題。如果你的系統涉及多個元件,那麼自己構建伺服器將會消耗太多的時間和精力。同樣,使用 Kubernetes 也不會使它變得更快。

PaaS 仍然提供了比雲虛擬機器更好的選擇,但你可能需要構建部署管道(CI/CD)來加速 TTM。CI/CD 管道在低程式碼平臺中是隱式可用的。你可能還希望選擇與雲不可知的工具,便於在未來遷移到其他平臺。在這方面,零程式碼和低程式碼平臺存在很大的風險。

因素 3:敏捷性

產品敏捷性是一個關鍵因素。你需要考慮定製量、主要變更、垂直轉換、水平轉換以及可能出現的新業務需求。假設你正在構建一個多租戶系統,不同的租戶有不同的定製需求。這些變更需求會不斷地湧向你。從基礎設施的角度來看,你需要一個不必為每個變更需求做出改變的系統。這個時候需要考慮雲的無關性。

對於資料,AWS Aurora 或 Azure Cosmos DB 等無伺服器資料服務是很好的選擇。如果你正在構建工作流或處理資料,那麼像函式這樣的線上服務可能是最好的選擇。對於應用程式,無伺服器或 FaaS 是很好的選擇。你還可以使用 Kubernetes 構建多租戶系統,但這不是好的入手點,因為你可能需要維護多個版本的應用程式、資料和功能。無伺服器架構可能是更好的選擇。

因素 4:控制程度

考慮對基礎設施的控制程度。基於以下這些原因,你可能想要更多的控制。

  1. 將會有大量的應用程式、資料庫和服務。

  2. 這是一個必須為客戶提供硬體的系統( MongoDB Atlas)。

  3. 你需要為租戶隔離資料或執行時,或兩者都隔離。

  4. 它是一種線上服務或 API,你的 USP 是為客戶節省許可、硬體和管理成本。

你可以通過控制物理機器或機架獲得最大程度的控制,但這些已經不再被使用了——因此,保持高程度控制的最佳方法是高階專用例項。無伺服器、低程式碼和無程式碼平臺提供的控制程度最低。

Kubernetes 將耗費大量的時間和精力,但從長遠來看,這是一筆不錯的交易。儘量避免使用線上服務,不要忘了你也在構建線上服務。

因素 5:成本

成本是最重要的因素之一。早期的成本估算總是很困難的,不過我們來看一個例子。

對於每天每小時一萬個請求,無伺服器基礎設施比雲虛擬機器的成本更高。但是,如果負載是異構的,並且在某些隨機時間是一萬,而在其他時間是一千,那麼使用雲虛擬機器例項的成本可能會更高,因為它們在大多數時間都沒有得到充分利用,在空閒時沒有產生任何價值。

你從一開始就要儘量避免固定成本。但為了更好的利用率,你需要找出平衡點,並切換回較低的級別(從低程式碼到無伺服器,或者從無伺服器到容器)。避免過早優化,在一開始不要追求優化或平衡。選擇最便宜的、現收現付的訂閱方式,之後再選擇更好的。

因素 6:遷移

遷移與雲不可知直接相關。更新、更便宜、更好的雲服務會不斷出現,所以你需要進行遷移。有時候遷移取決於你的客戶希望與哪個雲供應商合作。僅僅使用虛擬機器並不意味著你的系統是不可知的。

例如,如果你係統中有不同的元件訪問了其他元件,而你的 DevOps 團隊已經完全在 IAM 角色上設計了這種訪問管理,那麼從 AWS 遷移到 GCP 可能是一件棘手的事情。類似地,如果必須基於無伺服器構建整個計算層,那麼遷移到虛擬機器可能並不容易。

因素 7:整合

如果你正在構建一個聚合平臺,那麼你可能需要從第三方 API 收集資料,或者與其他 API 發生互動。這是一個整合問題,作為初創公司,你需要關心的是基礎設施的速度、可靠性和一致性。

在進行整合時,為應對節流和 API 速率限制,你可能會在短時間內生成多個 Spot 例項或多個無伺服器例項,從其他 API 收集/提交資料。在這裡,無伺服器提供了很大的幫助。自動縮放 Kubernetes 節點也很好。如果你選擇的是雲虛擬機器例項,那麼你必須花一些時間和精力來自動化配置。

基於上面定義的因素,我列出了一個決策矩陣,可以幫你做出決策。

決策框架

我提出了一個包含選項、因素和難度級別的框架。我在這裡使用的評價等級帶有主觀性,因為它是基於我十多年來使用不同基礎設施的經驗,而不是基於測試基準。

這個表格將讓你瞭解使用特定型別的基礎設施達到(構建和設定)某個因素級別的困難程度。

  • 容易:你可以做一些簡單的配置就可以完成。只需要付出較少的努力和時間,你就可以達到所需的因素級別。

  • 中等:你可能需要進行更多的配置/調優才能達到特定的因素級別,這可能不是一種最直接的方法。

  • 困難:為了達到這個目標,你可能需要基於一個明確的策略投入很多時間和精力。你可能還需要具備一些專業知識。

因素級別

雲虛擬機器

PaaS(GCP、Azure)

無伺服器(FaaS)

Kubernetes

低程式碼

管理開銷

困難

容易

容易

中等

容易

上市時間

困難

中等

容易

中等

容易

敏捷性

困難

困難

容易

容易

容易

控制程度

容易

困難

困難

容易

困難

成本

容易

中等

困難

容易

困難

遷移

容易

困難

困難

中等

困難

整合

困難

困難

容易

容易

容易

利用率

困難

困難

容易

容易

容易

結論

對於 SaaS 初創公司,我已經意識到最好從 Kubernetes(容器編排)開始,如果不選擇 Kubernetes,那麼可以考慮雲虛擬機器。 Kubernetes 只需要付出最小的努力就可以實現最大程度的控制,並可以確保成本優化以及未來的遷移和整合。

你需要遠離低程式碼/無程式碼平臺,它們在一開始可能看起來很容易,但它們在未來是個雷區,它們無法你解決三個關鍵因素:基礎設施成本、IT 管理成本和許可成本。PaaS 在某種程度上是可以接受的,但是如果涉及到作業系統級別的升級,它也會帶來一些障礙。

作者簡介:

Ratnesh Singh Parihar 是 Talentica 軟體公司的首席架構師。他是蘇拉特國立理工學院的校友,在超過 15 年的職業生涯中,曾與幾家早期和成長期的初創公司合作。他在架構和設計、擴充套件和處理大型系統、解決複雜的工程問題以及現代化遺留應用程式方面積累了大量的專業知識。

原文連結: