传统软件交付模型

在深入探讨SaaS的定义之前，我们需要先了解这一发展历程的起点以及推动SaaS交付模式发展的关键因素。让我们首先回顾传统软件的构建、运营和管理方式。通常SaaS出现前的系统主要采用“安装式软件”模式，客户需要参与软件的安装和配置。客户的IT团队可能在供应商提供的环境中安装软件，也可能在自有基础设施上运行。在此模式下，这些环境的管理和运营在一定程度上可由客户的IT团队承担。专业服务团队也可能在安装、定制和配置客户环境的过程中发挥一定作用。在此模式下，软件开发团队通常与交付和部署细节保持一定距离。他们更专注于持续提升解决方案的功能能力。交付和运营工作往往被视为开发流程的下游环节，由专门团队负责。

图1-1

我引入了独立软件供应商（ISV），代表向客户销售软件的实体，还展示了两个目前拥有ISV软件的客户，即客户1和客户2。每个客户都在运行ISV产品的特定版本。作为其流程的一部分，他们还要求对产品进行一次性定制，这些定制由ISV的专业服务团队处理。我们还有其他客户可能在运行不同版本的产品，这些版本可能有定制也可能没有。随着每个新客户的加入，服务提供商的运营团队可能需要组建专门的团队，以支持这些客户环境的日常运营需求。这些团队可能专职服务于单一客户，也可能跨部门支持多个客户。这种传统的软件交付模式是一种高度销售驱动的模式，业务部门专注于获取客户，并将客户移交技术团队以解决每个新客户的具体需求。你可以想象这种动态如何塑造整体文化和开发周期。产品如何构建、新功能如何发布、如何考虑定制化——这些领域均受此模式影响。在此模式下，达成交易的优先级可能高于敏捷性、可扩展性和运营效率。此类解决方案通常伴随长期合同，限制客户轻松迁移至其他供应商的方案。

客户环境的分散性和多样性往往会延缓新功能的发布和采用。客户在这些环境中通常拥有控制权，往往决定如何以及何时升级到新版本。测试和部署这些环境的复杂性可能变得难以管理，迫使供应商转向季度或半年度发布。可以说，采用这种模式构建和交付软件对某些企业而言是完全可行的，且未来仍将如此。特定领域的遗留系统、合规要求及业务现实可能与这种模式高度契合。然而，对于许多企业而言，这种软件交付模式引入了诸多挑战。其核心在于更注重通过在规模、敏捷性及成本/运营效率方面做出权衡，以满足客户的个性化需求。表面上看，这些权衡似乎并不显著。如果你只有有限的客户数量，且每年仅能获取少量客户，这种模式可能完全足够。虽然仍存在低效问题，但其影响远不显著。然而，假设你拥有庞大的客户基础并计划快速扩张业务，这种模式的痛点将逐渐显现，并成为许多软件供应商的现实难题。

运营和成本效率通常是采用这种模式的公司首先感受到压力的领域。支持每个新客户的额外开支开始对业务产生实际影响，侵蚀利润率并持续增加业务运营的复杂性。每个新客户可能需要更多的支持团队、更多的基础设施以及更多努力来管理每个客户安装过程中伴随的独特需求。在某些情况下，公司甚至会故意放缓增长步伐，因为这种模式带来的运营负担已难以承受。然而，更核心的问题在于这种模式对敏捷性、竞争力、增长和创新的影响。从本质上讲，这种模式与敏捷性背道而驰。允许客户自行管理环境、为每个客户支持独立版本、提供一次性定制化服务——这些都是严重削弱速度和敏捷性的因素。想象一下在这些环境中推出新功能的情景。从提出功能想法、迭代开发到最终将功能推向所有客户，往往是一个缓慢而谨慎的过程。等到新功能上线时，客户和市场需求可能已经发生变化。这也会影响这些公司的竞争格局，限制其快速响应基于低摩擦模型构建的新解决方案的能力。

在运营和开发规模日益难以扩展的同时，客户的需求和期望也在发生变化。客户不再专注于保留管理或控制环境的能力，而是更关注如何从软件中获取最大价值。他们越来越要求低摩擦的体验，能够持续创新以满足需求，并根据业务需求的演变自由切换解决方案。客户还更倾向于与自身价值和消费模式相匹配的定价模式。在某些情况下，他们寻求订阅和/或按需付费定价模式的灵活性。这里存在一种自然的张力。对于许多企业而言，传统的交付模式与他们扩展业务、满足客户不断变化的需求的能力并不匹配。云计算的兴起在此过程中也发挥了关键作用。云计算模式从根本上改变了企业对软件托管、管理和运营的看法。云计算的按需付费特性及其运营模式转变了行业思维，更加重视敏捷性和规模经济。这些因素共同促使软件供应商重新思考如何构建、交付、运营和销售其解决方案。

SaaS行业现状

我曾与多个团队合作，他们正在开发软件即服务（SaaS）解决方案。当我与他们坐下来规划其迈向SaaS的路线图时，他们通常会从一个看似合理且高屋建瓴的SaaS概念出发。然而，当我深入挖掘并探讨其解决方案的细节时，往往会发现他们的愿景存在显著差异。例如，假设有人告诉你他们想建造一栋建筑，虽然我们都大致知道建筑需要墙壁、窗户和门，但这些结构的具体形式可能千差万别。有些团队可能设想的是摩天大楼，而另一些团队可能在建造一栋房子。对于SaaS的具体形态存在一些困惑是比较自然的。正如所有技术领域一样，SaaS领域也在不断演进。

云计算的兴起、客户需求的转变以及软件领域的模式都在不断变化。我们昨天对SaaS的定义可能与今天不同。另一个挑战在于，SaaS的范围远不止于技术层面。在许多方面，它是一种贯穿SaaS提供商组织各个维度的思维方式。基于此，我们开始这段旅程的自然起点是明确我对SaaS的定义，以及这一定义如何塑造我们对SaaS解决方案架构、设计和构建的思路。本章的目标是构建一个基础的思维模型，以减少对“什么是SaaS”的困惑。我们将超越对SaaS的一些模糊概念，并在本书的范围内，为SaaS的定义附上更具体的指导原则，这些原则将塑造我们在后续章节中探讨的策略。

要实现这一目标，我们需要分析推动向SaaS转型背后的驱动力，并探讨这些驱动力如何直接影响最终形成的架构模型。追踪这一演进过程，将为我们提供更清晰的视角，理解构建SaaS解决方案时所遵循的根本原则，这些原则能够充分实现SaaS的价值主张，并融合技术与业务参数，这些参数是构建现代SaaS环境的核心。对于SaaS架构师而言，理解SaaS并非以技术为先的思维方式至关重要。SaaS架构师不会首先设计多租户架构，然后再考虑如何在该架构上叠加业务策略。相反，业务与技术需协同合作，寻找业务目标与多租户解决方案的最佳交汇点，以实现这些策略。这一主题将贯穿全书。尽管您可能对SaaS的含义感到熟悉，但我们在此探讨的基础概念可能会挑战您对SaaS的认知以及我们用来描述SaaS环境的术语。因此，尽管您可能觉得可以跳过这一章，但它可能是本书中最重要的一章。这不仅仅是一次介绍；它旨在建立一个共同的术语体系和思维模型，这些将贯穿于本书后续将探讨的架构设计、编码实践和实施策略之中。

共享基础设施模型

如今，传统模型的基本挑战已十分明确。部分组织仍在与该模型抗争，而另一些组织已意识到这种模型在经济和运营层面均难以规模化。例如，若您是拥有数千客户的B2B独立软件供应商（ISV），您的业务很可能无法支撑一种需要为每位客户单独提供支持、管理和运营的模式。对于许多企业而言，解决方案在于转向一种能够统一用户体验的模型，从而降低支持客户独立模型所带来的复杂性和成本。这就是我们看到团队开始采用共享基础设施模型，以实现业务规模化并更有效地优化运营模式。向更统一、共享的模型转变为软件提供商开辟了新的机遇。图1-2展示了一个简化的共享基础设施SaaS环境的概念视图。

图1-2

在图1-2中，您将看到传统SaaS概念的简化视图。我们完全摒弃了图1-1中经典模型中分散、一次性定制的特性。取而代之的是，我们转向了一种统一策略，其中所有系统的应用服务和基础设施均由客户共享。您还会注意到，我已将“客户”一词替换为“租户”。我们在第2章中将深入探讨租户的概念。其核心思想是，随着我们转向这一统一思维模式，我们对环境的视角发生了变化。现在，环境被视为一组共享资源，由一个或多个消费者共同使用。这些消费者代表了环境中的临时使用者，仅消耗其所需的资源——因此得名“租户”。将应用程序迁移到共享基础设施模型中，可以消除许多单独客户环境带来的缺点。现在，由于一切资源共享，我们拥有一组可以集体扩展、管理和运营的资源。在图1-2的右侧，您会看到我添加了一个框，用于表示该环境的管理、运营和部署。想象一下这将如何简化更新部署。借助共享基础设施，您的部署自动化只需将更新部署到这个统一的SaaS环境中，所有租户即可立即访问这些更改。独立部署、版本控制、管理和运营客户环境的理念已不复存在。

共享基础设施的优势几乎涵盖软件业务的方方面面。它能简化运营数据的聚合与收集，简化DevOps自动化的复杂性，并显著降低新租户的接入难度。或许最大的优势在于成本效率。通过将基础设施使用与实际租户活动关联，团队可最大化利润率并实现规模经济。不难理解为何这种模式对那些在传统模式下苦于成本和运营挑战的组织极具吸引力。除了统一用户体验外，它还为这些环境带来了新的敏捷性。若设计得当，这些环境可实现新功能和能力的更快发布，使组织能够更灵活地响应客户和市场需求。

该模式的本质也为部分ISV创造了新的增长机遇，使其能够以更快的速度新增租户，同时不削弱利润率并避免承担额外运营成本。云基础设施的弹性、按需付费特性与该模式高度契合，支持与云弹性自然匹配的定价和扩展模型。值得注意的是，转向共享基础设施这一举措也带来了诸多新的挑战。随着您逐步阅读本书，您将深入了解共享基础设施所带来的种种细节与复杂性。支持共享基础设施将直接影响您SaaS环境的安全性、性能、可扩展性、可用性和弹性特征。这些因素将对您设计和实施SaaS环境的方式产生显著影响。

所有租户运行同一版本的软件服务，这一概念是SaaS环境中的一个常见关键指标。它是实现采用SaaS交付模型核心业务优势的基础。

为了实现统一的用户体验，我们还需引入一套新的跨组件组件，以提供集中管理、运营和部署SaaS应用所需的所有功能。将这些组件分离出来是构建成功且可扩展的SaaS业务的关键——即使您的应用程序没有共享基础设施。实际上，这些组件是驱动SaaS企业敏捷性、创新和效率目标的核心。为了更好地理解这一点，让我们看看SaaS环境的另一种视图（如图1-3所示）。

图1-3

在图1-3的中心位置，您会看到一个用于放置您的SaaS应用程序体验的占位符。这里是您SaaS应用程序的各个组件部署的位置。您可以在这里找到应用程序的基础设施。围绕应用程序的是一组用于支持更广泛的SaaS环境需求的组件。例如，在顶部，我标出了“入驻和身份验证”组件，它们提供了将新租户引入系统所需的所有功能。在左侧，您会看到SaaS部署和管理功能的占位符。而在右侧，您会看到一些基础概念，如计费、计量、指标和分析。

对于许多SaaS开发者而言，将这些周边组件视为次要、不那么关键的架构元素是常见的误区。事实上，我曾与一些团队合作，他们选择推迟引入这些组件/服务，将全部初始精力投入到多租户应用程序的开发中。虽然确保应用程序架构的正确性是SaaS模型的重要组成部分，但SaaS业务的成功将高度依赖于这些周边组件的能力。这些能力是实现运营效率、增长、创新和敏捷性等目标的核心，而这些目标正是推动企业采用SaaS模型的动力。因此，这些在所有SaaS环境中通用的组件必须在构建SaaS解决方案时被置于核心位置。这就是为什么我一直鼓励SaaS团队从这些组件开始进行SaaS开发。正是这些与应用程序功能无关的构建模块，将对架构、设计、代码以及业务产生重大影响。

这应凸显SaaS效率与敏捷性故事的多维性。效率的一部分通过这里展示的服务实现，另一部分则通过您应用架构中采用的策略实现。如果应用架构共享基础设施，可以为环境带来更多效率和规模经济效益。关键在于，这些周边服务必须代表我们统一模型的基础要素。在此基础上，我们可以进一步思考如何优化应用架构以最大化效率和敏捷性。

重新定义多租户

到目前为止，我一直避免引入多租户的概念。这是一个在SaaS领域被广泛使用的术语，并在本书的剩余部分中会多次出现。然而，这是一个我们必须谨慎对待的术语。多租户的概念带有许多复杂的内涵，在厘清这些内涵之前，我希望先为推动企业采用SaaS交付模型的核心原理打下基础。另一个挑战在于，本书中将定义的多租户概念将超越传统定义中通常附带的含义。

多年来，在许多领域，"多租户"一词被用来表示某些资源被多个租户共享。这种情况可能出现在多种场景中。例如，某些云基础设施组件可能被视为多租户，因为它允许租户共享其底层基础设施的某些部分。许多在云中运行的服务可能采用多租户模型以实现规模经济。不管在云环境还是在自建环境中，团队都可以构建解决方案，其中计算、数据库和其他资源被多个租户共享。这使得多租户与共享资源的概念紧密相连。事实上，在这种背景下，这种多租户概念是完全合理的。

现在，当我们开始考虑SaaS环境时，将多租户映射到其中是完全自然的。毕竟，SaaS环境共享基础设施，而这种共享基础设施显然可以被标记为多租户。为了更好地说明这一点，让我们看一个将本章讨论的概念结合起来的SaaS模型示例。图1-4展示了一个示例多租户SaaS环境的视图。

图1-4

在此示例中，我们将应用程序服务的共享基础设施部署在外围的一组微服务中，这些微服务用于管理和运维SaaS环境中的所有组件。假设所有租户共享基础设施（计算、存储等），这种架构仍符合多租户的经典定义，且许多SaaS提供商都会采用此模式定义并交付其解决方案。挑战在于，SaaS环境并不完全遵循此模型。例如，假设我创建了一个类似图1-5的SaaS环境。

图1-5

请注意，我们对部分应用微服务的基础设施布局进行了调整。产品微服务保持不变，其计算和存储基础设施仍由所有租户共享。然而，当我们转向订单微服务时，会发现资源分配有所变化。我们的域、性能和安全要求可能需要我们将每个租户的存储分离出来。因此，订单微服务的计算资源仍然共享，但每个租户都有独立的数据库。

最后，我们的履行微服务也发生了变化。我们的需求推动我们采用了一种模型，其中每个租户运行专用的计算资源。不过，在这种情况下，数据库仍由所有租户共享。这种架构无疑为我们对多租户的理解增添了新的复杂性。如果严格遵循多租户的定义，我们不能说这里运行的所有组件都符合多租户的原始定义。例如，订单服务的存储不与任何租户共享基础设施。我们的履行微服务的计算资源也不共享，但该服务的数据库仍由所有租户共享。

在SaaS领域，模糊多租户边界的情况非常常见。当你构建一个SaaS环境时，你并不是严格遵循任何一种绝对的多租户定义；而是根据系统业务和技术需求，选择共享资源与专用资源的最佳组合。这都是为了优化SaaS架构的资源占用，以更好地满足业务需求。尽管此处的资源并非所有租户共享，但我们之前概述的SaaS基本原则仍然适用。例如，此环境不会改变我们的应用程序部署方法。该环境中的所有租户仍将运行同一版本的产品。此外，该环境仍将由我们在先前示例中依赖的同一组共享服务进行部署、运营和管理。这意味着我们仍能从该环境中提取与完全共享基础设施（带有一些限制）相当的运营效率和灵活性。为了进一步说明这一点，让我们看一个更极端的例子。假设我们有一个类似于图1-6所示的SaaS架构。在此示例中，域、市场和遗留要求迫使我们所有计算和存储都运行在专用模型中，每个租户都拥有完全独立的基础设施资源。

图1-6

尽管在此模型中租户未共享基础设施，但您会发现它们仍通过贯穿所有示例的同一组共享能力进行部署、管理和运维。这意味着所有租户仍在运行同一版本的软件，且仍被集体管理和运维。这可能看起来像是一个不太可能的场景。然而，在实际应用中，SaaS提供商可能面临各种因素，迫使他们采用这种模式。迁移到SaaS的提供商通常将此模式作为迈向SaaS的第一步。其他行业可能有极端的隔离要求，不允许共享基础设施。导致SaaS提供商采用此模式的因素不胜枚举。

因此，在这一背景下，我们有必要思考如何在SaaS环境中定义多租户。单纯采用多租户的字面定义（即共享基础设施）似乎无法准确映射到部署租户基础设施的各种模型。相反，SaaS模型的多样性似乎要求我们对多租户的定义进行演进。在本书的范围内，至少目前而言，“多租户”这一术语将被扩展以适应此处所述的实际情况。随着我们深入探讨，多租户将指代任何通过单一、统一的体验来接入、部署、管理和运营租户的环境。基础设施的共享性与“多租户”这一术语之间不存在任何关联。在接下来的章节中，我们将引入新术语，以帮助我们克服与多租户相关的一些模糊性。

避免使用“单租户”术语，图1-6所示，当我们的解决方案没有共享基础设施时，仍会将其标记为多租户环境，因为所有租户仍在运行同一版本并被集体管理或运营，术语“单租户”在本章之后将不再使用。我们讨论的每种设计和架构都将被视为多租户架构，我们将使用新术语来描述各种部署模型。此处的总体目标是将多租户概念与共享基础设施脱钩，将其作为更广泛的术语，用于描述任何以SaaS模型构建、部署、管理和运营的环境。

SaaS的边界在哪里

我们已经为 什么是SaaS 奠定了基础，但还有许多细节我们尚未深入探讨。例如，假设你的SaaS应用程序需要将系统的一部分部署在外部位置，或者想象一下应用程序依赖于其他供应商的解决方案的场景。也许你正在使用第三方计费系统，或者你的数据必须存储在另一个环境中。存在诸多不同原因导致你需要将整体SaaS环境的部分组件托管在无法完全掌控的外部环境中。那么，这种更分散的部署架构如何与为所有租户提供统一体验的理念相兼容？毕竟，对系统所有组件拥有完全控制权无疑能最大化创新能力和响应速度。同时，认为所有SaaS提供商都能完全避免因领域或技术限制而必须支持外部托管组件、工具或技术的想法并不现实。

这就是我们不希望在SaaS定义上过于极端的地方。在我看来，界限更多在于这些外部依赖项的配置、管理和运营方式。如果它们的存在完全对租户隐藏，且仍通过您的集中化管理和运营，这在我看来仍然是SaaS。虽然这可能引入新的复杂性，但并未改变我们试图构建的SaaS模式的核心精神。

当SaaS提供商依赖于直接暴露给租户的外部资源时，情况就变得更加复杂。例如，如果SaaS解决方案将数据存储在托管的数据库中，那么问题就变得更加棘手。此时，您可能对部分基础设施存在依赖，而这些基础设施并不完全处于您的控制之下。更新此数据库、更改其架构、管理其健康状态——这些操作在这种模式下会变得更加复杂。此时，我们开始质疑外部资源是否突破了SaaS的第三道壁垒，基础设施暴露于租户，破坏SaaS环境敏捷性、运营效率和创新能力的期望或依赖关系。我的基本原则是，我们提供的是服务体验，在服务模式下，租户的视图仅限于我们服务的表面。用于实现该服务的工具、技术和资源应完全对租户隐藏。

托管服务提供商模型

在我们努力完善对多租户SaaS环境的理解时，还有一个关键问题需要解决。部分组织选择了所谓的“托管服务提供商”（MSP）模式。在某些情况下，他们会将MSP视为SaaS的一种变体。这在SaaS领域引发了一些混淆。为了更好地理解这些挑战，让我们先看看MSP环境，并探讨它在这一讨论中的定位。图1-7展示了MSP环境的概念模型。该模型与我们之前提到的经典安装软件模型相似。在该图的底部，会看到一群客户正在运行软件供应商产品的不同版本。每个客户都在自己的基础设施或环境中运行。然而，通过MSP，我们试图通过将运营转移到一个集中化的团队或实体来实现效率和规模经济。这就是这些MSP提供的服务。他们通常负责安装、管理和支持每个客户，并试图通过他们用于运营这些客户环境的工具和机制来提取一些规模和效率。

图1-7

图1-7顶部还标注了软件供应商，此处旨在说明软件供应商可能与一家或多家管理其客户环境的MSP存在第三方合作关系。您可以理解为何有人会将MSP模型与SaaS相提并论。毕竟MSP确实试图为所有客户提供统一的托管和运营体验。然而，若回顾我们用于描述SaaS的核心原则，便能发现MSP模型与SaaS之间存在显著差异。其中最大的区别在于，客户被允许运行独立的版本。因此，尽管可能存在一些集中管理和运营的尝试，但MSP必须在运营体验上做出个性化调整，以支持每个客户环境的不同需求。这可能需要专门的团队；至少，这意味着必须有能够处理支持每个客户独特需求复杂性的团队。再次强调，MSP模型确实能带来大量价值并提升效率，但它与通过让客户运行单一产品版本（并在许多情况下通过共享部分或全部基础设施实现规模经济）来实现效率的“单一管理界面”模式截然不同。在MSP模型中，您很可能仍会继承来自单一客户变体的部分痛点。MSP可以采取一些措施来缓解部分挑战，但仍需面对支持独立客户环境中独特、一次性需求所带来的运营和敏捷性复杂性。

另一个区别主要体现在SaaS团队的组织结构和运营方式上。通常，在SaaS组织中，我们尽量避免在运营团队与其他部门之间划出严格的界限。我们希望运营团队、架构师、产品所有者以及团队中的各种角色紧密合作，持续评估和优化其服务体验。这通常意味着这些团队之间紧密相连。他们同样关注理解租户如何使用系统、如何施加负载、如何进行部署，以及其他一系列关键洞察。SaaS企业需要并渴望对系统运行状况了如指掌。这是推动业务成功并直接连接到整体租户体验的核心。尽管这并非一个明确的界限，但它仍代表了SaaS与MSP之间的一个重要差异。需要强调的是，MSP是一种完全有效的商业模式。它往往适合部分软件供应商。MSP甚至可以成为部分SaaS供应商的过渡阶段，在团队持续推进SaaS交付模式的同时，帮助其获取部分运营效率。关键在于，我们需明确SaaS与MSP的界限，避免将两者视为同义概念。

SaaS本质上是一种商业模式

到目前为止，您应该对如何定义SaaS有了更清晰的认识。SaaS本质上是构建一种技术、商业和运营文化，专注于实现特定的商业成果。尽管人们一般从技术模式和策略的角度看待SaaS，但实际上应将其视为一种商业模式。为了更好地理解这种思维方式，想想采用SaaS如何影响S提供商的业务。它直接影响并塑造了团队如何构建、管理、运营、营销、支持和销售其产品。SaaS的原则最终融入了SaaS公司的企业文化，模糊了业务与技术领域的界限。在SaaS模式下，业务战略聚焦于打造能够帮助企业快速响应当前及新兴市场需求的服务，同时保持增长势头且不牺牲增长潜力。

功能和特性对SaaS公司依然重要。然而，在SaaS公司中，功能和特性很少会以牺牲敏捷性和运营效率为代价而被引入。当提供多租户SaaS解决方案时，多数用户的需要始终应优先于少数用户的需要。那些为了追求一次性机会而牺牲服务长期成功、需要专门的一次性支持的时代已经一去不复返了。这种思维方式的转变影响了SaaS公司中的几乎每一个角色。例如，产品所有者的角色发生了显著变化。产品所有者必须拓宽视野，将运营属性纳入产品待办事项列表的构建中 。

用户入驻体验、价值实现时间、敏捷性——这些都是产品所有者必须关注的重点。他们必须优先考虑并重视这些对成功构建SaaS业务至关重要的运营属性。架构师、工程师和质量保证人员同样受到这一转变的影响。他们现在必须更多地考虑所设计、构建和测试的解决方案如何满足服务体验的动态需求。SaaS产品的营销、定价、销售和支持方式也发生了变化。这种新职责和重叠职责的主题在大部分SaaS组织中都很常见。因此问题是：塑造和指导SaaS公司商业模式的核心原则是什么？虽然对这个问题可能存在一些争议，但有一些关键主题似乎在驱动SaaS业务战略。以下概述了这些关键的SaaS业务目标：

• 敏捷性

  这个术语在软件领域常被过度使用。与此同时，在SaaS领域，它常被视为SaaS业务的核心支柱和驱动力之一。许多转向SaaS的组织之所以做出这一选择，是因为其现有模式已导致运营陷入瘫痪。采用SaaS意味着转向一种注重速度与效率的文化和思维方式。发布新版本、应对市场动态、开拓新客户群体、调整定价模式——这些都是企业期望从采用SaaS模式中获得的诸多好处之一。服务的设计、运营方式以及销售策略，都受到提升敏捷性的需求所驱动。如果一个多租户解决方案仅降低了成本却未能实现敏捷性，那么它必然会错失SaaS更广泛的价值主张。

• 运营效率

  在许多方面，SaaS就是关于规模。在多租户环境中，我们高度专注于持续扩大客户基数，而无需为新增客户配备专门的资源或团队。通过SaaS，您本质上是在构建一个能够支持持续增长（理想情况下是快速增长）的运营和技术基础架构。支持这种增长意味着需要在整个组织范围内投资于高效的运营基础架构。我经常会问SaaS公司，如果明天有1000个新客户注册使用他们的服务，会发生什么。有些人会欣然接受，另一些人则会感到不安。这个问题往往揭示了SaaS公司运营效率的关键问题。需要注意的是，运营效率不仅关乎响应速度，还包括对客户需求的反应能力。新功能的发布速度、客户的入驻速度、问题解决的效率——这些都是运营效率故事的一部分。组织中的每个部门都可能在构建高效运营体系中发挥作用。

• 创新

  更快的行动能力对SaaS组织有诸多好处。它让企业更加灵活，能够更开放地进行实验和调整战略。对敏捷性和运营效率的投资使组织能够变得更加流畅和灵活。这使他们能够把握新机遇、开拓新市场细分、采用新的包装/定价策略，以及探索其他众多可能性。总体目标是将运营和成本模型的内在优势作为创新引擎的燃料。正是这种创新能在更大程度上推动SaaS业务的成功。

• 无摩擦的客户入驻

  SaaS企业必须仔细考虑客户如何进入其环境。如果您希望保持尽可能的敏捷和运营效率，就必须思考如何简化客户入驻流程。对于一些SaaS企业，这可以通过经典的注册页面实现，客户可以完全自助完成入驻流程。在其他环境中，组织可能依赖内部流程来推动入驻。关键在于，每家SaaS企业都必须专注于打造一个消除摩擦、提升敏捷性和运营效率的入驻体验。对于部分企业，这可能较为简单。而对于其他企业，可能需要重新思考团队如何构建、运营和自动化入驻流程。

• 增长

  每个组织都追求增长。然而SaaS组织对增长有着截然不同的理解。它们正在投资一种模式和组织架构，旨在通过持续增长实现繁荣。想象一下，你建造了一座高度高效的汽车工厂，将生产流程的每一步都进行了优化和自动化。然而你只要求它每天生产两辆汽车。这似乎毫无意义。在SaaS领域，我们正在构建一个业务架构，旨在简化整个客户获取、入驻、支持和管理流程。SaaS公司进行这种投资，是期望它能支持并推动增长引擎，最终影响企业的利润率和整体成功。因此，当我们谈论增长时，我们指的是通过SaaS带来的敏捷性、运营效率和创新，实现一种无法通过其他方式达到的加速水平。你实现的增长程度是相对的。对一些公司而言，增长可能是新增100个客户，对另一些公司则可能是新增50,000个客户。尽管增长规模可能因公司而异，但以增长为导向的目标对所有SaaS企业同样至关重要。

文中提到的这些要点代表了SaaS业务的核心原则。这些概念应在SaaS公司中自上而下贯彻执行，领导层需明确强调通过投资敏捷性、运营效率和增长目标来驱动以增长为导向的业务战略。几乎您SaaS架构和战略的每一个维度都将源自您的业务愿景。目标客户群体、产品包装、定价策略、成本模型以及其他众多因素都将塑造您最终构建的解决方案的架构、运营模式和管理范围。如果您在这些关键点上缺乏清晰的业务共识和对齐，您很可能无法构建一个能够充分实现业务目标的SaaS产品。

构建服务，而非产品

许多软件供应商认为自己从事的是产品开发业务。从某种程度上说，这与他们的商业模式相契合。这种思维模式聚焦于一种模式：我们开发产品，客户购买后，产品基本上归客户所有并由其使用。这种以产品为中心的模式存在诸多变体和细微差别，但本质上都倾向于创建静态产品并让客户购买的模式。在这种以产品为中心的思维模式下，重点通常放在定义功能和特性上，以帮助软件提供商填补空白并把握新机遇。如今，随着SaaS的出现，我们从创建产品转向创建服务。那么，这只是术语上的变化，还是对我们构建SaaS产品的方式有实质性影响？事实证明，这绝不仅仅是术语的转变。

当你以服务形式提供软件时，对成功的定义会发生根本性变化。当然，你的解决方案必须满足客户的功能需求。这一维度的挑战不会消失。但作为服务，你将更加关注客户在业务全维度上的整体体验。让我们通过一个例子来更好地说明服务与产品的区别。餐厅是一个探索这些差异的绝佳场所。当你外出用餐时，你当然期待的是食物（产品）。然而，服务也是你体验的一部分。你被迎接到门口的速度、服务员何时来到你的餐桌、你何时得到水，以及食物何时送达，这些都是衡量服务体验的标准。无论食物有多美味，服务质量都会对你对餐厅的整体印象产生重大影响。

现在，让我们从SaaS服务的角度来思考这个问题。您的SaaS客户也会有类似的服务期望。他们能否轻松完成系统部署，实现价值所需的时间，新功能的发布速度，反馈渠道的便捷性，系统停机频率——这些都是SaaS团队必须重点关注的服务维度。如果整体体验未能满足客户期望，再优秀的产品也无济于事。在SaaS模式下，这一问题具有特殊意义，因为客户对您系统的唯一视角就是SaaS解决方案的表面。SaaS客户无法洞察系统底层的组成部分，他们不会考虑补丁、更新和基础设施配置。他们只关心服务能否提供让用户最大化解决方案价值的体验。在这种服务模式下，我们还经常看到SaaS公司利用其运营敏捷性来提升客户忠诚度。这些SaaS提供商将进入一种模式，即快速发布新功能、响应反馈并以迅猛速度迭代系统。

这种持续快速的创新让客户相信他们将受益于这种持续演进。事实上，这往往是新兴SaaS公司从传统非SaaS市场领导者手中抢占业务的利器。尽管一些规模庞大、根基深厚的市场领导者可能拥有更丰富的功能集，但其无法快速响应市场和客户需求的能力，可能导致客户转向更灵活的SaaS解决方案。因此，尽管产品与服务的对比可能显得有些刻板，但我认为这是SaaS思维模式中不可或缺的一部分。它直接关联到SaaS作为一种思维方式，塑造了整个SaaS组织对待工作和客户的方式。事实上，许多SaaS组织会采用一系列指标来衡量其实现服务导向目标的能力。虽然可能有人认为这些指标可以作为未来某个时间点附加到服务上的功能，然而，许多成功的SaaS组织将这些指标作为其SaaS业务的核心支柱。

B2B与B2C SaaS的故事。 当团队讨论SaaS时，他们通常会将策略和模式映射到面向消费者（B2C）和面向企业（B2B）的商业模式中。如在前言中所述，理解这两种模式在架构设计上的差异至关重要。例如，B2C的规模通常需要高度专业化的策略，以适应这些环境的工作负载特征和成本模型。同时，在概念层面，这里讨论的许多主题和机制也适用于B2C和B2B环境。我不会试图突出所有需要不同方法的具体场景。由于变量太多，无法对B2C和B2B的适用性做出绝对结论。因此，在本书范围内，我们承认B2C或B2B的属性确实会影响解决方案的整体架构模型。

定义SaaS

我在这章的大部分内容都致力于澄清SaaS的边界、范围和本质。现在，我认为有必要将我们讨论的所有信息整合起来，尝试给出一个明确的SaaS定义，理想情况下，包含我们已讨论的概念和原则。这是我认为最能概括本书后续内容中将采用的SaaS视角的定义：

SaaS是一种商业和软件交付模式，使组织能够以低摩擦、以服务为中心的模式提供解决方案，从而为客户和提供商创造最大价值。它依赖于敏捷性和运营效率作为商业战略的支柱，以促进增长、扩展和创新。

这一定义始终围绕SaaS作为商业模式的主题展开。这里没有提及任何技术或架构考虑。作为SaaS架构师和开发者，您的职责是创建支撑业务目标实现的底层模式和策略。虽然这可能看似是任何架构师的职责，但SaaS环境中业务与技术需求的独特融合将直接融入SaaS解决方案的设计、架构和实施过程中。

需要一个更广泛的多租户定义，该定义不应与是否共享基础设施相关。明确多租户术语的使用场景和方式，是讨论SaaS及描述SaaS架构的基础。最后，在本章后半部分，我开始尝试进一步明确SaaS的边界。例如，我分析了MSP（管理服务提供商）模型，并回顾了区分MSP与SaaS模型的关键因素。我还探讨了构建SaaS组织及服务时应遵循的核心原则，其中包括对比构建服务（而非产品）时面临的关键差异。希望本章能帮助您更好地理解本书中对SaaS的整体视角。对这些原则的共识将使我们能够以共同的视角探讨后续更具体的概念，明确影响和指导架构选择的驱动力。理想情况下，这也将消除历史上围绕这一主题的一些困惑。现在我们已经建立了SaaS思维模式的基础，可以开始思考这些原则如何映射到更具体的架构模式和构造中。在下一章中，我将对所有关键的SaaS架构机制和策略进行一次梳理，而不涉及任何特定解决方案或技术栈的细节。这将揭示在定义任何SaaS架构时应考虑的全部范围。定义租户上下文、讨论所需的通用服务和能力、解释数据分区——这些都属于更详细的内容，我们将后续展开。