SaaS 初创公司如何选择合适的云基础设施

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 节点也很好。如果你选择的是云虚拟机实例，那么你必须花一些时间和精力来自动化配置。

基于上面定义的因素，我列出了一个决策矩阵，可以帮你做出决策。

决策框架

我提出了一个包含选项、因素和难度级别的框架。我在这里使用的评价等级带有主观性，因为它是基于我十多年来使用不同基础设施的经验，而不是基于测试基准。

这个表格将让你了解使用特定类型的基础设施达到（构建和设置）某个因素级别的困难程度。

• 容易：你可以做一些简单的配置就可以完成。只需要付出较少的努力和时间，你就可以达到所需的因素级别。

• 中等：你可能需要进行更多的配置/调优才能达到特定的因素级别，这可能不是一种最直接的方法。

• 困难：为了达到这个目标，你可能需要基于一个明确的策略投入很多时间和精力。你可能还需要具备一些专业知识。

结论

对于 SaaS 初创公司，我已经意识到最好从 Kubernetes（容器编排）开始，如果不选择 Kubernetes，那么可以考虑云虚拟机。Kubernetes只需要付出最小的努力就可以实现最大程度的控制，并可以确保成本优化以及未来的迁移和集成。

你需要远离低代码/无代码平台，它们在一开始可能看起来很容易，但它们在未来是个雷区，它们无法你解决三个关键因素：基础设施成本、IT 管理成本和许可成本。PaaS 在某种程度上是可以接受的，但是如果涉及到操作系统级别的升级，它也会带来一些障碍。

作者简介：

Ratnesh Singh Parihar 是 Talentica 软件公司的首席架构师。他是苏拉特国立理工学院的校友，在超过 15 年的职业生涯中，曾与几家早期和成长期的初创公司合作。他在架构和设计、扩展和处理大型系统、解决复杂的工程问题以及现代化遗留应用程序方面积累了大量的专业知识。

原文链接：

Choosing the Right Cloud Infrastructure for Your SaaS Start-up