31、迈向云端迁移：可行性分析与实施策略

迈向云端迁移：可行性分析与实施策略

在当今数字化时代，众多公司将 SaaS 业务模式视为软件产品的未来发展方向。然而，从基于软件现货的公司向 SaaS 导向的公司转型是一项极具挑战性的任务。错误的业务模式转型或技术迁移可能会给公司带来致命后果，甚至导致破产或消失。本文将探讨如何通过可行性分析和制定现代化策略，帮助公司顺利实现向云端的迁移。

可行性分析

要判断迁移是否可行，可行性分析是一种有效的方法。与现有的向 SOA 迁移的方法不同，本文介绍的可行性分析主要依靠一系列工具，旨在提供数据和图形图像，以便更轻松地决定是否进行迁移。

技术可行性分析工具

• 代码分析 ：代码分析有两个主要目标。一方面，通过常见的指标，如代码行数（LOC）、McCabe 圈复杂度、对象间耦合度（CBO）等，来表示方法、类型、类、命名空间或程序集的耦合情况，从而获得代码内聚性和复杂性的有用视图。这些视图可以以矩阵、依赖图或树的形式呈现。另一方面，要识别遗留软件对第三方 COTS 和公司内部其他应用程序的依赖关系。
• 高级建模 ：该活动的主要目标是轻松理解可能作为服务公开的候选功能或模块。最好的方法是使用 UML 对应用程序进行不同视图的建模，并利用逆向工程技术。同时，分析数据库模式、数据和事务模型，以选择最佳的数据库架构（RDBMS、NoSQL 或混合解决方案）和迁移策略。
• 工作量估算工具 ：根据目标云平台，该工具可以估算将应用程序迁移到该平台所需的工作量。

业务可行性分析

业务可行性分析的目标是为管理层提供基于经济因素决定是否进行迁移的指导。通常采用成本 - 效益分析的方法。虽然每个迁移项目的成本 - 效益分析都需要定制，但通常会有一些常见的假设：
- 降低无质量成本 ：由于应用程序作为服务更频繁地进行升级，并且每次升级都会进行回归测试，因此应用程序的质量更高。这体现在减少返工和解决客户投诉的时间上。
- 降低维护和安装的差旅成本 ：将应用程序迁移到云端可以减少现场维护和安装的需求，从而降低差旅成本。
- 降低营销成本 ：SaaS 模式可以通过互联网进行营销，减少传统营销渠道的成本。
- 云服务提供商成本 ：有三种选择，需要根据公司的需求和预算进行评估。
- 开拓新市场带来的更高利润 ：通过 SaaS 模式，公司可以进入以前无法触及的新市场，从而增加利润。
- 降低劳动力成本 ：使用（半）自动化工具支持迁移可以减少手动编程和迁移的工作量，从而降低劳动力成本。

业务可行性分析还会为管理层提供以下数据：
| 指标 | 详情 |
| ---- | ---- |
| 未来 5 年的净现值 | 反映项目在未来 5 年内的盈利能力 |
| 未来 5 年的投资回报率 | 衡量投资的收益情况 |
| 投资回收期 | 表示收回投资所需的时间 |

此外，还需要分析公司内部的业务流程，以确定业务模式转型对流程层面的影响。云计算业务模式意味着重新定义旧流程并创建新流程，如 SLA 控制和维护、客户服务等。

现代化策略

在分析了上述活动的指标和数据后，组织需要决定是否继续进行现代化进程。如果决定继续，就需要定义一个策略，为公司提供实现问卷中所表达的期望成熟度的路线图。现代化策略将根据迁移前阶段的结果进行个性化定制，但有一些关键问题具有共同的方面：
- 多租户 ：这是所有符合云标准的应用程序的关键方面。应用程序作为 SaaS 提供时，通常需要为不同的租户提供服务。多租户是指从软件应用程序的单个共享实例向多个客户组织或租户交付软件，而不影响数据完整性。多租户有几个级别，如仅共享硬件的云虚拟化、共享数据库的简单应用程序等。
- 可扩展性 ：要实现应用程序的可扩展性，最重要的是定义和分离包含静态和动态数据的层。静态数据容易扩展，而动态数据需要特定的机制。将无状态节点与事务性节点分离可以简化问题。保持应用程序无状态是扩展应用程序的最佳方式，这样可以创建多个数据库实例而无需同步它们之间的状态。可扩展性可以从应用层和存储层两个角度来考虑。
- 监控 ：当应用程序作为 SaaS 提供时，监控应用程序的使用情况和所有使用的资源非常重要。监控可以用于制定收费政策，例如监控物理资源（CPU、存储）和应用程序使用情况（访问、并发用户），以便根据实际使用情况进行计费。
- 业务模式 ：现成软件的业务模式不能直接应用于 SaaS 业务模式，需要进行调整。SaaS 业务模式可能涉及一些流程的自动化，以满足客户对与 SaaS 交互的一些事实上的标准期望，如在线订阅、基于消息的支持或可配置的邮件通知。

用例分析

本文介绍的方法目前正在西班牙的八家不同公司进行测试。虽然样本数量不足以确保完全正确，但该方法已被证明是有效的。下面将介绍两个具体的用例。

用例 1：聚焦业务轴

这是一家小型 IT 公司，为银行、电子商务或航空航天等多个行业提供解决方案。该公司希望迁移一个虚拟帮助助手解决方案，以适应云业务范式。迁移不仅意味着业务模式的改变，还需要在技术方面进行一些调整。

首先，描述了当前应用程序的情况和迁移后应用程序的主要想法，具体如下表所示：
| 方面 | 当前情况 | 期望情况 |
| ---- | ---- | ---- |
| 技术方面 | SaaS 导向，三层架构风格，两种类型的服务，用户认证，XML/JSON 响应处理 | 相同架构，新的用户管理模块，监控和控制新的计费方法，客户和统计管理 |
| 业务方面 | 安装初始费用和少量使用费用，每日维护和支持费用 | 大致相同的业务模式，但监控某些方面以调整费用，定义 SLA 协议 |

使用图形表示当前和期望的应用程序成熟度水平，当前位置为 [2（技术），1（业务）]，期望位置为 [3（技术），3（业务）]。

接下来进行成本 - 效益分析，假设资本成本为 10%，第一年的实施过滤率为 75%，每年增加 5%。从业务流程的角度来看，该组织需要考虑以下流程：
- 计费流程 ：根据监控活动获得的数据，改进计费流程以实现自动化。这意味着在应用程序中集成或创建一个计费模块。
- SLA 相关流程 ：实现 SLA 的自动协商和监控，之前 SLA 监控活动是手动的，由纸质文件控制。

根据 ROI 分析数据，该公司决定继续进行现代化进程，并实施了以下现代化策略：
- 集成一个用于监控新计费流程所需方面的元素，从头开始创建。主要监控应用程序级别的并发用户数量和任何给定用户执行的查询数量。
- 插入基于监控模块提供的数据进行自动计费的模块。该计费模块能够根据客户的偏好创建和发送账单。
- 创建用户认证机制，这对于上述两个活动也是必需的。
- 定义清晰的 SLA 流程和机制。

用例 2：技术和业务层面的迁移

这是一家 IT 中小企业，开发并商业化了一款用于公司内部即时通讯和聊天的产品。该公司希望实现的迁移不仅包括业务方面，还包括技术方面，如可扩展性、多租户和计费功能。

同样，先描述了当前和期望的应用程序情况：
| 方面 | 当前情况 | 期望情况 |
| ---- | ---- | ---- |
| 技术方面 | 基于 J2EE 的三层架构，业务层与表示层分离，非纯多租户，vCloud 基础设施，用户资源监控，特定时间有高使用高峰 | 纯多租户应用程序，但数据库未重构，架构由 Web 服务组成，可扩展性要求，自动计费 |
| 业务方面 | 按用户收费的许可证 + 安装、定制和部署的咨询费 + 维护费，已实施帮助台，SLA 未定义 | 按使用付费，根据应用程序的使用情况计费，SLA 需要定义并区分与应用程序和基础设施相关的 SLA |

当前位置为 [2（技术），1（业务）]，期望位置为 [3（技术），3（业务）]。

进行成本 - 效益分析时，假设与用例 1 相同，并且迁移将（半）自动进行，自动化程度在 20% 到 40% 之间。需要重新设计的业务流程包括：
- 升级和软件更新 ：目前没有定义相关机制，更新是“即时”进行的。
- 计费 ：目前账单是手动生成的，新的“按使用付费”模式需要实现计费活动的自动化。该公司集成了一个开源的计费组件并进行了定制。
- 帮助台 ：现在可以通过电子邮件或其他参与方式管理事件。
- 营销策略 ：公司希望开拓新市场，现有的传统营销策略不再适用，因此对病毒式营销活动感兴趣并正在建立相关机制。

需要从头定义的流程包括：
- SLA 管理 ：建立 SLA 参数，如响应时间和 QoS，之前这些参数未定义和控制。
- 隐私和安全 ：主要是基于角色的访问和数据位置。该公司选择的云类型确保是私有的，只有公司内部人员可以访问。

综上所述，通过全面的可行性分析和个性化的现代化策略，公司可以更好地应对向 SaaS 业务模式的迁移挑战。虽然目前的方法在八家西班牙公司的测试中表现良好，但仍有一些方面需要进一步改进和发展，如问题集的扩展、分析过程的自动化等。未来，随着更多公司的实践和研究的深入，这种迁移方法将不断完善，为软件行业的发展提供有力支持。

迈向云端迁移：可行性分析与实施策略（续）

实施流程总结

为了更清晰展示从可行性分析到最终实施迁移的整个过程，我们可以用 mermaid 流程图来呈现：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始]):::startend --> B{是否进行迁移?}:::decision
    B -->|是| C(可行性分析):::process
    B -->|否| D([结束]):::startend
    C --> C1(技术可行性分析):::process
    C --> C2(业务可行性分析):::process
    C1 --> C11(代码分析):::process
    C1 --> C12(高级建模):::process
    C1 --> C13(工作量估算工具):::process
    C2 --> C21(成本 - 效益分析):::process
    C2 --> C22(业务流程分析):::process
    C11 --> C3(确定可迁移性):::process
    C12 --> C3
    C13 --> C3
    C21 --> C3
    C22 --> C3
    C3 --> E{迁移是否可行?}:::decision
    E -->|是| F(制定现代化策略):::process
    E -->|否| D
    F --> F1(多租户设计):::process
    F --> F2(可扩展性设计):::process
    F --> F3(监控方案设计):::process
    F --> F4(业务模式调整):::process
    F1 --> G(实施迁移):::process
    F2 --> G
    F3 --> G
    F4 --> G
    G --> H(用例分析与优化):::process
    H --> I([结束迁移]):::startend

这个流程图展示了从最初决策是否进行迁移，到进行详细的可行性分析，再到制定现代化策略，最后实施迁移并进行用例分析优化的完整过程。

关键技术要点回顾

在整个迁移过程中，有几个关键的技术要点需要再次强调：
1. 代码分析 ：通过多种指标来评估代码的耦合性和复杂性，这有助于了解遗留软件的结构，为后续的迁移提供基础。例如，通过代码行数（LOC）可以了解代码的规模，McCabe 圈复杂度可以评估代码的逻辑复杂度。
2. 高级建模 ：利用 UML 进行应用程序建模，并结合逆向工程技术，能够更好地理解应用程序的功能和结构。同时，对数据库架构的分析和选择也是关键，不同的数据库架构适用于不同的应用场景。
3. 可扩展性设计 ：将静态数据和动态数据的层分离，保持应用程序的无状态性，是实现应用程序可扩展性的重要方法。这样可以在不影响其他部分的情况下，轻松扩展数据库实例。
4. 多租户实现 ：多租户是 SaaS 应用的核心特性之一，不同级别的多租户实现方式（如云虚拟化、共享数据库等）需要根据应用的需求和特点进行选择。

未来发展方向

虽然目前的迁移方法在八家西班牙公司的测试中取得了一定的成效，但仍有许多方面需要进一步完善和发展：
1. 问题集的扩展 ：目前的问题集在测试的八家公司中表现良好，但由于测试环境在业务模式、产品和技术方面的范围相对较窄，如果扩大范围，可能需要扩展问题集，以更全面地评估不同公司的迁移需求。
2. 分析过程的自动化 ：目前部分分析工作（如应用程序在象限中的位置分析）是手动进行的，未来应尽可能实现自动化，提高分析效率和准确性，并且可以将其作为一项在线服务提供。
3. 可行性分析的深化 ：技术和业务可行性分析需要进一步发展和自动化，目前的分析结果较为分散，需要建立更统一的评估标准和自动化工具，以便更好地支持决策。

总结与建议

通过对可行性分析、现代化策略和用例的研究，我们可以得出以下结论和建议：
1. 全面评估 ：在进行迁移之前，公司应进行全面的可行性分析，包括技术和业务方面。这有助于识别潜在的问题和风险，为迁移决策提供有力支持。
2. 个性化策略 ：根据公司的实际情况制定个性化的现代化策略，考虑多租户、可扩展性、监控和业务模式等关键因素。
3. 持续优化 ：在迁移过程中，不断进行用例分析和优化，根据实际情况调整策略和方法，确保迁移的顺利进行。
4. 关注未来发展 ：密切关注迁移方法的未来发展方向，积极参与相关的研究和实践，不断提升公司的迁移能力和竞争力。

总之，向 SaaS 业务模式的迁移是一个复杂而具有挑战性的过程，但通过科学的方法和策略，公司可以降低风险，实现成功迁移，为未来的发展奠定坚实的基础。随着技术的不断进步和实践经验的积累，相信这种迁移方法将不断完善，为软件行业带来更多的机遇和发展。