SaaS-UPOS 初创企业选择合适的云基础设施

• 选择云选项时，重要的是要了解每个云选项提供的抽象级别都会直接影响管理成本。

• 考虑公司管理基础设施的能力，包括日常管理，以及产品对未来变化的适应能力。持续定制可能需要多次部署产品。

• 决定您想要对基础设施进行多少控制。与提供最少控制量的无服务器、低代码和无代码平台相比，高端专用实例将提供最大程度的控制。

• 确定可能出现的定制量、重大变更、垂直转移、水平转移以及新业务需求，然后相应地选择数据和应用服务。

• 尽可能避免任何固定成本。选择最便宜的即用即付订阅，然后再转向更好的可能性。

Gartner预测2022 年云采用投资将达到 $482B，这是云如何渗透到不同行业的重要指标。但令人担忧的是云迁移的失败率。目前，跨阶层企业的这一比例徘徊在44%至57%之间，这让预算约束明显的初创企业面临着不小的压力。

软件即服务(SaaS) 初创企业也不例外。作为一名解决方案架构师，我多年来一直在设计 SaaS 应用程序，我看到初创企业努力寻找合适的云基础设施并改进他们的产品。

这些经历促使我写这篇文章作为帮助公司做出务实的事实和数据驱动的决策的工具。

相关赞助内容

选择数据可观察性平台之前要考虑的 10 件事

SQL 到 NoSQL：架构差异和迁移注意事项

Azure 上的 .NET 初学者指南

Amazon Web Services Cookbook：AWS 成功秘诀

选择 NoSQL 数据库即服务 (DBaaS) 时的 7 个要点

使用 Kalix 轻松迁移到云并以惊人的速度进行创新！构建 NoOps 所需的高性能微服务和 API。了解更多。

在我们进入云选项之前，了解每个云选项提供的抽象级别非常重要，因为它直接影响管理成本。更高级别的抽象提供更少的控制、更低的性能输出并增加成本，但也涉及更少的工作和更高的利用率。

如果您正在构建 SaaS 产品，那么您需要首先购买硬件。然后，在其上安装操作系统，然后安装 JVM、v8 和 Python 等运行时。之后，您将安装所有依赖项，最后部署您的代码。

云基础设施选项

当今可用的每个基础设施选项都抽象了以下一两个内容：

云虚拟机（IaaS）：它们主要抽象硬件层，您不需要配置任何物理层，但仍然需要构建其他层。这将为您提供最大程度的控制，但设置需要时间，示例包括EC2、Azure VM、Google Cloud Platform (GCP)。
 
平台即服务 (PaaS)：它提供了硬件之上的另一层抽象，您无需担心操作系统/容器、升级、安全性等。示例包括 Azure PaaS、AWS Elastic Beanstalk 和 GCP PaaS。
 
无服务器（函数即服务）（FaaS）：这是具有运行时抽象的 PaaS。您无需担心这一点的运行时间。主要例子是AWS Lamda，Azure Functions和Google Cloud Functions。
 
低代码：除了硬件、操作系统和运行时之外，您还可以获得依赖关系管理的抽象。例如，解析。您需要认真思考最佳实践。
 
Kubernetes (K8)（容器编排）：如果您最初投资Kubernetes或在生产就绪时使用任何 Kubernetes 即服务 (EKS)，您将把代码作为 Pod 发布。从抽象的角度来看，它与Serverless类似，但仍然提供更多控制。
 
零代码：有些平台和服务允许您无需编写任何代码即可创建应用程序。但是，这并不意味着您不需要开发人员。它将提供快速原型、MVP 和初始引导代码。例如，Zoho 或 Quick Base。我们不会讨论零代码平台。
 
现在让我们深入讨论可能影响结果的关键因素。

影响 SaaS 应用程序基础设施的 7 个因素

因素 1：管理费用

首先考虑的是公司管理基础设施的能力，包括所需的时间、是否需要人工进行日常管理以及产品对未来变化的适应能力如何。

如果该产品主要由企业使用并且需要定制，那么您可能需要多次部署该产品，这可能意味着基础设施管理员需要投入更多的精力和时间。部署可以自动化，但自动化过程要求产品稳定。对于早期产品来说，投资回报率可能并不好。在这种情况下，我的建议是使用托管服务，例如用于基础设施的 PaaS、用于数据库/持久性的托管服务以及用于计算的 FaaS（无服务器架构）。

因素 2：上市时间 (TTM)

快速TTM的关键是快速开发、测试和发布。快速开发到发布的关键是在编码和测试上花费更多的时间，而不是在配置和部署上。低代码和无代码平台都是很好的起点。Serverless 和 FaaS 就是为了解决这些问题而设计的。如果您的系统涉及许多组件，那么构建自己的盒子将消耗太多的时间和精力。同样，设置 Kubernetes 并不会让速度变得更快。

PaaS 仍然提供比云虚拟机更好的选择，但您可能需要构建部署管道（CI/CD）以加快 TTM。CI/CD 管道在低代码平台中隐式可用。您可能还想选择与云无关的工具，并允许您稍后迁移到其他平台。在这方面，零代码和低代码平台存在很大的风险。

因素 3：敏捷性

产品敏捷性是一个关键因素。您需要考虑定制量、重大变更、垂直转移、水平转移以及可能出现的新业务需求。想象一下，您正在构建一个多租户系统，并且不同租户有不同的定制需求。您将不断收到这些更改/请求。从基础设施的角度来看，您需要一个不必为每个请求/更改更改它们的系统。与云无关在这里是无关紧要的。
 
对于数据，无服务器数据服务，例如AWS Aurora或Azure 的 Cosmos DB都是不错的选择。如果您正在构建工作流程或数据处理，那么步骤函数等在线服务是您的最佳选择。对于应用程序来说，Serverless 或 FaaS 是不错的选择。您还可以使用 Kubernetes 构建多租户系统，但这不是一个好的起点，因为您可能需要维护应用程序、数据和功能的多个版本。无服务器架构可能是正确的起始选择。

因素 4：控制

重要的是要考虑您将对基础设施获得多少控制权。如果出现以下情况，您会希望获得更多控制权：

• a) 将会有很多应用程序、很多数据库和很多服务。

• b) 这是一个您必须为客户配置硬件的系统（MongoDB Atlas）。

• c) 您需要为租户隔离数据或运行时或两者。

• d) 它是一项在线服务或 API，您的 USP 是为您的客户节省许可证、硬件和管理成本。

您可以使用物理机器或自己的机架获得最大程度的控制，但这些不再使用，因此保持高水平控制的下一个最佳选择是高端专用实例。无服务器、低代码和无代码平台提供的控制量最少。
 
Kubernetes 会消耗大量的时间和精力，但从长期控制的角度来看，这是一笔不错的交易，而且你必须 100% 与云无关。尽可能避免在线服务，并记住您正在构建一个在线服务。

因素5：成本

成本是最重要的因素之一。早期的成本估算总是很困难，但让我们从一个例子开始：

对于每天每小时 10K 的请求，无服务器基础设施的成本将比云虚拟机高得多。但是，如果负载是异构的，并且在某些随机时间为 10K，而在其他时间则为 1K，那么设置云虚拟机实例的成本可能会很高，因为它们在大多数时间都未得到充分利用，并且在空闲时间没有任何价值。
 
首先，您将尽量避免任何固定成本。但为了更好地利用，您需要找出收支平衡点并切换回较低级别（低代码到无服务器或无服务器到容器化应用程序）。避免过早的优化，一开始就不要追求优化或平衡。选择最便宜的即用即付订阅，然后再转向更好的可能性。

因素 6：迁移

迁移与云无关直接相关。总是有更新、更便宜、更好的云产品不断出现，因此您需要迁移。有时迁移取决于您的客户希望与哪些云提供商合作。仅使用虚拟机并不会使您的系统与云无关。

例如，如果您有不同的组件来访问其他组件，并且您的 DevOps 团队完全根据 IAM 角色设计了这种访问管理，那么从 AWS 迁移到 GCP 可能是一件棘手的事情。同样，如果您必须在无服务器上构建整个计算层，那么迁移到虚拟机可能并不简单。

因素 7：整合

如果您正在构建聚合平台，那么您可能会从第三方 API 抓取器收集数据，或者为您的客户与其他 API 进行交易。这是一个集成空间，作为一家初创公司，您最关心的是您的基础设施的速度、可靠性和一致性。

通过集成，您可能会在短时间内生成多个 Spot 实例或多个 Serverless 实例，以从其他 API 收集/提交数据，从而克服限制和 API 速率限制。无服务器在这里有很大的帮助。自动缩放的 Kubernetes 节点也很好。如果您选择云虚拟机实例，那么您必须花费一些时间和精力来自动化配置。

根据可用的基础设施选项和上面定义的因素，我提出了一个决策矩阵，可以帮助您为基础设施做出决策。

决策框架

我创建了一个包含选项、因素和难度级别的框架。我在这里使用的评级纯粹是主观的，因为它是基于我十多年来使用不同基础设施的经验，而不是基于基准。

我创建的表格将使您了解使用特定类型的基础设施选择来实现（构建和设置）一个因素有多么困难。

• 简单：您只需进行简单的配置即可完成。只需更少的精力和时间，您就可以达到所需的效果。

• 中：您可能需要进行更多配置/调整才能实现特定因素，这可能不是一个简单的方法。

• 困难：要实现这一目标，您可能需要使用明确的策略投入时间和精力。您可能还需要一定的专业知识。

判决

对于 SaaS 初创企业，我意识到最好从 Kubernetes（容器编排）开始，如果 Kubernetes 不是一个选择，那么云虚拟机应该是下一个基础设施选择。Kubernetes 以最小的努力提供最大的控制，并确保成本优化以及未来的迁移和集成。

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