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 年的職業生涯中,曾與幾家早期和成長期的初創公司合作。他在架構和設計、擴展和處理大型系統、解決複雜的工程問題以及現代化遺留應用程序方面積累了大量的專業知識。

原文鏈接: