SaaS 迁移

许多采用 SaaS 的提供商都通过传统的软件安装模式（如前所述）迁移到 SaaS。对于这些提供商来说，在 SaaS 的核心原则上保持一致性尤为重要。

在这里，人们可能会对迁移到 SaaS 模式的含义感到困惑。例如，有些人将迁移到云视为迁移到 SaaS。有些人则认为在安装和预置过程中增加自动化就是实现了迁移。

公平地说，每个组织可能从不同的位置开始，需要考虑不同的遗留问题，并且可能面临不同的市场和竞争压力。这意味着每次迁移看起来都会有所不同。

尽管迁移途径可以不同，但在某些领域却并没有遵循迁移策略的核心原则。在概念和原则上保持良好的一致性可以对 SaaS 迁移的整体成功产生重大影响。

基于前面所述的概念，应该清楚的是，向 SaaS 的迁移应该从了解业务战略和目标开始。但在迫切需要尽快迁移到 SaaS 的迁移环境中，这一点可能会被忽视。

在这种模式下，组织通常主要将迁移视为一项技术活动。实际上，每次 SaaS 迁移都应该从清晰地了解目标客户、服务体验、运营目标等开始。更明确地关注您需要什么样的 SaaS 业务，这将对您将解决方案迁移到 SaaS 的形式、优先级和路径产生深远影响。

从迁移一开始就要有这个清晰的愿景，这将为在迁移到 SaaS 的过程中如何迁移技术和业务奠定基础。当您开始迁移时，就要把注意力放在那些最能为您指明前进方向的问题上。

下表显示了侧重技术和侧重业务的迁移思维方式的对比。

表 1 — 侧重技术的迁移与侧重业务的迁移

侧重技术的思维方式	侧重业务的思维方式
我们如何隔离租户数据？	SaaS 如何帮助我们发展业务？
我们如何将用户与租户联系起来？	我们的目标是哪些细分市场？
我们如何避免近邻干扰？	这些细分市场的规模和概况如何？
我们如何进行 A/B 测试？	我们需要支持哪些层级？
我们如何根据租户负载进行扩展？	我们的目标是怎样的服务体验？
我们应该使用哪个计费提供商？	我们的定价和包装策略是什么？

左边是侧重技术的迁移思维方式的示例。工程团队专注于努力获得对任何 SaaS 架构都很重要的经典多租户话题。

但问题是，左边许多问题的答案通常会直接受到右边问题答案的影响。任何关注迁移的人都应该已经很清楚这一点。然而，现实是，许多组织从一开始就将追求运营和成本效率作为第一步，认为业务部分能自行解决。

在这种迁移策略下，人们可能会对如何改进原有环境以适应 SaaS 模式感到困惑。在这个领域，迁移到 SaaS 的选择也很多。但是，对于任何迁移，我们通常都提倡要有一个共同的价值体系。

在之前对 SaaS 原则的讨论中，我们概述了用于描述 SaaS 环境的不同模式和术语。涵盖所有这些解决方案的共同主题是：围绕应用程序提供共享服务。身份识别、加入、指标、账单 — 这些都被称为任何 SaaS 环境的核心要素。

现在，当我们研究迁移时，您会发现这些相同的共享服务在任何迁移案例中都起着关键作用。下图提供了迁移场景的概念视图。

迁移到 SaaS

此图展示了任何迁移路径的目标体验。它包括前面描述的所有共享服务。中间是您的应用程序的占位符。

关键思想是，您可以在此环境的中间放置任意数量的应用程序模型。迁移的第一步可能是让每个租户在自己的孤岛中运行。或者，您可能有一些混合架构，在这些架构中，元素是孤立的，而其他功能则是通过一系列现代化的微服务来实现的。

根据原有环境的性质、市场需求、成本考虑等，您起初对应用程序进行现代化改造的程度会有所不同。相同之处是引入了这些共享服务。

任何 SaaS 迁移都需要支持这些基础共享服务，以使您的业务能够在 SaaS 模式下运营。例如，应用程序架构的所有变化都需要 SaaS 身份。您需要具备租户感知能力的运营来管理和监控您的 SaaS 解决方案。

在迁移时优先部署这些共享服务，这样即使底层应用程序仍在各个租户的全堆栈孤岛中运行，您也可以向客户呈现 SaaS 体验。

总体目标是让您的应用程序在 SaaS 模式下运行。然后，您可以将更多精力放在应用程序的进一步现代化和完善上。借助这种方法，您能以更快的速度迁移业务的其他部分（营销、销售、支持等）。更重要的是，您能够开始参与和收集客户反馈，并使用这些反馈持续构建现代化的环境。

值得注意的是，您提供的共享服务可能不包括您最终需要的所有特征或机制。主要目标是创建迁移开始时所需的共享机制。这使您可以专注于系统中对应用程序架构的发展和运营演变至关重要的元素。