【SaaS架构】SaaS架构基础 : SaaS与托管服务提供商（MSP）

SaaS和托管服务提供商（MSP）模型之间的界限也存在一些混淆。如果您查看MSP模型，它可能具有与SaaS模型类似的目标。

然而，如果您深入了解MSP，您会发现MSP和SaaS实际上是不同的。下图提供了MSP环境的概念视图。

托管服务提供商（MSP）模型

该图表示MSP模型的一种方法。在左侧，您将看到使用MSP模型运行的客户。通常，这里的方法是使用任何可用的自动化来配置每个客户环境，并为该客户安装软件。

右边是MSP为支持这些客户环境而提供的运营足迹的近似值。

需要注意的是，MSP通常安装和管理给定客户想要运行的产品版本。所有客户都可以运行相同的版本，但MSP模型通常不需要这样做。

总的策略是通过拥有这些环境的安装和管理来简化软件提供商的生活。虽然这让提供商的生活更简单，但它并没有直接映射到SaaS产品所必需的价值观和思维方式。

重点是减轻管理责任。这样做并不等同于让所有客户都在同一版本上运行，并拥有统一的管理和运营经验。相反，MSP通常允许单独的版本，并且通常将这些环境中的每一个视为在操作上独立的。

在某些领域，MSP可能开始与SaaS重叠。如果MSP本质上要求所有客户运行相同的版本，并且MSP能够通过一次体验对所有租户进行集中安装、管理、运营和计费，那么可能会开始比MSP更多的SaaS。

更广泛的主题是，自动化环境安装并不等于拥有SaaS环境。只有当您添加了前面讨论的所有其他注意事项时，这才更能代表真正的SaaS模型。

如果我们从本故事的技术和运营方面进行回顾，MSP和SaaS之间的界限将变得更加明显。通常，作为SaaS业务，您的产品能否成功取决于您是否能够深入参与体验的所有活动部分。

这通常意味着掌握入职体验的脉搏，了解运营事件如何影响租户，跟踪关键指标和分析，并与客户保持密切联系。在MSP模型中，如果这项工作交给了其他人，那么您可能最终会从SaaS业务运营的核心关键细节中脱离一个层次。