【SaaS架构】SaaS架构基础: 最初的动机

为了理解SaaS，让我们从一个相当简单的概念开始，了解我们在创建SaaS业务时要实现的目标。最好的开始是看看传统（非SaaS）软件是如何创建、管理和操作的。

下图提供了几个供应商如何打包和交付其解决方案的概念视图。

打包和交付软件解决方案的经典模型

在这个图中，我们描述了一组客户环境。这些客户代表购买了供应商软件的不同公司或实体。这些客户中的每一个基本上都在一个独立的环境中运行，在这个环境中他们安装了软件提供商的产品。

在此模式下，每个客户的安装都被视为专用于该客户的独立环境。这意味着客户将自己视为这些环境的所有者，可能需要一次性定制或支持其需求的独特配置。

这种心态的一个常见副作用是，客户将控制他们运行的产品版本。这种情况可能有多种原因。客户可能担心新功能，或者担心采用新版本带来的干扰。

您可以想象这种动态会如何影响软件提供商的运营足迹。您越允许客户拥有一次性环境，管理、更新和支持每个客户的不同配置就越具有挑战性。

这种对一次性环境的需求通常要求组织创建专门的团队，为每个客户提供单独的管理和运营经验。虽然这些资源中的一些可能会在客户之间共享，但该模型通常会为每个新入职的客户引入增量费用。

让每个客户在自己的环境中（在云中或内部）运行他们的解决方案也会影响成本。虽然您可以尝试扩展这些环境，但扩展将仅限于单个客户的活动。本质上，您的成本优化仅限于在单个客户环境的范围内实现的目标。这也意味着您可能需要单独的扩展策略来适应客户之间的活动变化。

最初，一些软件企业会将此模型视为一个强大的架构。他们利用提供一次性定制的能力作为销售工具，允许新客户提出其环境特有的要求。尽管客户数量和业务增长仍然温和，但这种模式似乎完全可持续。

然而，随着公司开始取得更广泛的成功，这种模式的限制开始产生真正的挑战。例如，设想一个场景，您的业务达到了显著的增长高峰，从而快速增加了大量新客户。这种增长将开始增加运营开销、管理复杂性、成本和一系列其他问题。

最终，这种模式的总体开销和影响可能开始从根本上破坏软件业务的成功。第一个痛点可能是运营效率。与吸引客户相关的人员配置和成本增加开始侵蚀业务利润。

然而，运营问题只是挑战的一部分。真正的问题是，这种模式随着规模的扩大，直接开始影响企业发布新功能和跟上市场步伐的能力。当每个客户都有自己的环境时，提供商必须在尝试将新功能引入其系统时平衡一系列更新、迁移和客户需求。

这通常会导致更长和更复杂的发布周期，这往往会减少每年发布的数量。更重要的是，这种复杂性使得团队在每个新特性发布给客户之前就花了更多的时间来分析它们。团队开始更专注于验证新功能，而不是交付速度。发布新功能的开销变得如此巨大，以至于团队更加专注于测试机制，而较少关注推动其产品创新的新功能。

在这种较慢、更谨慎的模式下，团队往往会有较长的周期时间，这会在创意开始与客户手中之间产生越来越大的差距。总的来说，这会阻碍你对市场动态和竞争压力做出反应的能力。