面向 ISV 的 Oracle SaaS 迁移
手册

在过去的几年里,我们已经将 60 多个基于 SaaS 的应用程序迁移到了 Oracle Cloud Infrastructure。这些应用程序为八个行业垂直市场的核心企业功能提供支持,在全球拥有超过 199,000 名客户。

在本手册中,我们将分享关键挑战、经验教训、优秀实践以及我们在云之旅中获得的好处。让我们的云转型经验为您所用。

用心、精心计划和周到执行的云迁移可以带来巨大的利益。以下是我们迁移的亮点。

 
将数据中心从
80 个整合为 11 个
 
资本支出降低
80%
 
基础架构成本降低
64%
 
软件支出减少
42%
 
软件供应商从
28 家减少到 10 家
 
配置时间缩短了
98%

执行摘要

如果您运行自己的数据中心和托管环境,迁移到云是一个重大转变。虽然云增强了基础架构服务的弹性、规模和范围,但完成这一旅程需要您重新审视和调整技术、组织结构与业务实践。这会对从长期产品路线图到计划技术投资的广泛变量造成影响。

在进行转型时,您必须应对独特的挑战,找到基本问题的答案并抓住影响深远的机遇。通向云的道路并非康庄大道。云应用程序种类繁多,并没有一种万能的适用方法、架构或服务集。

这本面向独立软件供应商 (ISV) 的软件即服务 (SaaS) 迁移手册是我们在将 60 多个基于 SaaS 的应用程序迁移到 Oracle Cloud Infrastructure (OCI) 的过程中积累的经验结晶。这些应用为八个行业垂直市场的核心企业功能提供支持,全球拥有超过 199,000 名客户。我们的团队应对的许多挑战和实施的解决方案与您在迁移到云模型时可能遇到的挑战和实施的解决方案相同。该手册提炼了我们在各个过渡阶段的经验,提供了强大的洞察力和观察力,可协助您完成旅程。您也可以访问我们的 Oracle@Oracle 网站参考十多篇白皮书和博客,这些文章介绍了我们的云转型之旅,并分享了此旅程的优秀实践、挑战和经验教训。

我们相信所有的 ISV—或提供面向内部或外部、基于 SaaS—的应用程序的企业都可以通过迁移到云获得类似的优势。

第 1 章:转型的驱动因素

为您的云之旅保驾护航

任何包含应用程序迁移的云转型过程都会十分复杂。然而,虽然整体复杂,但云之旅有几个明确的目的地。其中一个目的地涉及如何使目标应用程序具有"云就绪性"。为了在期望的时间内迁移到云,您希望/需要应用程序达到怎样的云就绪程度?在本文中,我们将概述其中一些目的地,并重点介绍我们旅程的优秀实践和经验教训。成功的关键是提前明确自己的迁移目标,以便就如何实现这些目标制定优质决策。您会发现,面前有很多潜在途径。在迁移的过程中,开发人员、交付团队和管理层人员需要对推进方法进行评估并做出众多选择。

我们建议您重点关注以下技术和业务驱动因素,为实现业务目标所需制定的决策打好框架。

可扩展性

云服务可提供大规模计算能力,远远超出托管基础架构的能力范围,使您的企业能够不断发展,应对市场机遇。基于云的基础架构即服务 (IaaS) 和平台即服务 (PaaS) 使 ISV 能够专注于利用现代组件构建可扩展的架构。迁移的另一个好处是,内部开发团队不必再管理和扩展 IT 运营,可以专心调整和优化性能。

现代化

工具集、服务和架构的现代化简化了组件之间的集成,帮助应用程序发挥云中可用工具和技术的全部价值。这些工具包括从基础架构升级到自动化部署通道,再到可提高应用程序性能的集成式机器学习模型。在市场快速且持续变化的领域,现代化尤为重要,因为应用程序必须保持动态才能与时俱进。在某些情况下,可能要完全重写和重塑服务,利用全新技术堆栈来提供成本更低或更简化的服务选项。这些变化可能会更新日益老化的产品,扰乱以许可产品为常态的既定市场。在其他情况下,可能会采用新方法对产品进行大检,在改善服务的同时保持品牌知名度和客户忠诚度。这不一定需要对产品套件进行全面更改。

迁移到云会成为广泛推动现代化的一个触发点。由于云为您和您的团队提供了以前组织中无法获得的服务、技术和专业知识,实现新目标和提供新能力便成为可能。您的团队可将注意力从堆栈转移到普遍适用的新产品功能上来,不必操心对不同客户的特定部署编写自定义代码。随着服务供应、产品更新和客户支持的速度比以往更快,可以将资源重新集中在开发新功能上。这样一来,云迁移就为大量现代化活动创造了条件,改变了从产品升级执行到客户服务质量的方方面面。


"迁移到第二代云使 Oracle 能够通过强大的 DevSecOps 模型确保成功交付我们的服务,并使我们能够支持客户的业务转型。我们现在每天都会发布软件,供应时间减少了 98% 以上。"— Karthic Murali,Oracle 全球业务部门高级首席产品战略经理

oracle@oracle


标准化

IaaS 和 PaaS 实现标准化能够减少开销,使团队更加灵活,互换性更强。随着组织的发展,您的团队将采用不同成熟度的工具。将这些工具集整合到云服务中会大大消除这一 IT 管理层的复杂程度。它允许开发和使用标准操作实践,完成可映射到整个产品组合的任务。标准化还可使常规活动更简单、更可预测,从而减少基本任务的劳动力需求。以前被束缚在应用程序间指导可能不兼容的各种流程中的资源得到释放,专注于解决更重要的问题,包括为客户开发新一代产品和服务。

值得注意的是,标准化使得围绕安全、风险、合规性和其他运营活动实施全球政策和实践变得更加简单,您的团队可以轻松地将这些政策和实践应用于现有产品和新产品中。事实上,应用程序可以继承 IaaS 平台的许多内在功能,例如经认可的合规性认证。

收入优化

收入优化可以通过两种主要方式实现。首先,降低成本的效果最为显著。利用 IaaS 消除数据中心不仅可将财务模式从资本支出转变为运营支出,通常还会实现显著的 TCO 成本节省。而效果可能不太明显的方式是,通过合理调整已迁移到云的应用程序组合所采用的技术体系,实现成本节约。通用工具集可建立起机构知识体系,省去采用非标准化工具时临时培训产生的相关费用。如此来看,将基础架构视为代码的通用工具集提供了自动化功能,最终节省了时间和劳动力成本。最后,整个产品组合基础领域(例如安全性)的专业团队便无需在每个产品团队中培养专家。

其次,迁移到云可以帮助您更快地进入市场,最终实现收入优化,因为一旦应用程序具有云就绪性或云原生性,产品开发的时间通常便会缩短。更快地进入市场意味着更快地实现收入。一旦应用程序具备云就绪性,便可以在几分钟内将其部署到全球任何地方。

综合上述原则,应该可以实现产品和服务架构标准化,提高部署速度和质量。扩展源于重复模式的设计,这有助于优化收入、更快实现价值,并且能够重新集中资源,为客户提高服务的质量和完整性。


WorkForce Software 将其员工管理解决方案迁移到了 Oracle Cloud Infrastructure,实现了 30% 的性能提升。

Workforce"出色的财务绩效使我们刚开始就能节省 30% 到 35% 的资本支出,再加上从 OCI 获得的卓越性能,我们通过套件提供的 ROI 也越来越好。"—Mike Morini,WorkForce Software 首席执行官

了解更多信息


在云中实现价值的途径

云计算可以包括一系列 IaaS 和 PaaS 资源以及多种软件部署模型,范围可从访问裸机实例涵盖到集成的容器化环境,再到功能齐全的服务堆栈。在最基本的层面上,云计算是指用核心 IaaS 资源替代物理基础架构组件。

大多数企业应用程序最初并非是针对云构建的。对于许多应用程序来说,转换或适应云模式既耗时又困难。从时间和劳动力的角度来看,平台重构十分昂贵,因此有时重新设计云原生主体反而更加容易也就不足为奇了。考虑到这一点,公司在考虑云迁移时通常会发现自己会面临三种主要场景。

  • 退出传统的数据中心:运行数据中心十分昂贵。建筑、人员、电力、制冷、维护和升级只是日常职责的一小部分。许多企业正在积极评估应用程序组合,选出从本地移除的候选应用程序,致力于减少或消除他们对数据中心的依赖。当务之急是将应用程序从同位、主机托管或本地数据中心移出,以减少或消除资本支出。通常采用全面迁移战略,将应用程序按原样迁移到云中的裸机服务器或虚拟机中。
  • 不断演变的技术体系:在这种情况下,公司开始对应用程序进行增量更改,这虽然需要额外投资,但也有望随着时间的推移带来更多价值。例如,用基于云的 Oracle Autonomous Database 替代 Oracle Database 的本地版本,而不对应用程序本身进行重大更改。这有时被称为迁移-改善战略。
  • 全身心投入云原生:从头到脚重新构建应用程序以实现云就绪,可能比在实施上述某种场景时保留不太成熟的应用程序更节省成本。云原生应用程序本质上是高度分布的,通常使用 12 要素原则构建,因此被设计为独立于底层架构,这意味着即使其下的基础架构出现故障,应用程序也能继续运行。简而言之,评估该途径是否适合目标应用程序是值得的,因为迁移到云肯定比迁移与其底层基础架构紧密耦合的应用程序更容易。
Cloud Native Patterns eBook
要了解 Oracle 如何定义云原生、云原生应用程序的起源以及构建时可遵循的优秀实践,请阅读此电子书

设想这些场景的另一种方法是在将企业应用程序移至 Oracle Cloud Infrastructure 时,看看您可以采取哪些行动将其移至更接近云原生架构的位置。见下图 1。


图 1:云迁移变化和投资水平

图 1 的左侧代表了最少的变化、最短的价值实现时间和最低的初始投资。随着您向右移动,变化、投资和时间通常会增加,但实现的价值也会增大。此模型可帮助您制定一种方法来预测在移动阶段要考虑进行的投资类型。请注意,由于应用程序以多种方式构建,场景不一定是离散的,还会有一些重叠。

上述场景成为评估现有成熟度水平和云过渡目标的关键参考点。您可根据当前状态与目标状态之间的差距对云过渡所需的技术和流程变更范围进行粗略估计。在理想情况下,云过渡应该使所有应用程序都过渡到云原生交付模式。然而,鉴于资源和时间的限制,很少有组织能够在单个流程中将其整个产品组合过渡到云原生模式。即使是简单的平台重构工作也可能需要大量资源,并且需要大量投资来复制旧功能。

因此,云过渡是一个确定理想云成熟度水平(应用程序在上述云托管到云原生连续体中的位置)与重新设计产品及其相关业务流程所需的工程投资之间的权衡问题。在这个阶段,关键步骤是确定每个应用程序当前和目标成熟度水平,并粗略估计弥合差距所需的开发投资。

在迁移过程中改变成熟度水平的应用程序也必须改变运营模式和期望。成熟度级别的变化会影响支持服务的团队、流程和策略。

 

第 2 章:就绪性和投资目标

评估云的技术就绪性

对目标应用程序的技术理解,或者对于提供多种基于 SaaS 的应用程序的公司来说,对整个应用程序组合的技术理解对于理解迁移的要求和依赖项至关重要。在此阶段,重点关注的领域应该是确定应用程序所需的功能以及它们与这些依赖项的关系。这有助于确定迁移活动的相对时间安排,帮助明确重点关注领域。评估应涉及三个关键方面。

  1. 基础架构要求:云将软件与其底层硬件或操作环境分离。高成熟度的应用程序基本上独立于它们的环境,仅依赖于通用的基础架构资源(如 CPU 或 Kubernetes 集群),可在云中轻松扩展。低成熟度的应用程序依赖于所提供的特定设备、组件或环境,例如托管基础架构或其他专用系统。应用程序对云中基础架构组件和配置的硬性依赖程度必须首先记录并最终消除。与底层基础架构相关联/耦合的定制项(您或您的客户定制)并不少见。
  2. 服务组件:云将支持能力作为独立的服务提供,独立于应用程序进行运营和交付。高成熟度的应用程序围绕离散组件构建,在整个堆栈中依赖性最小,允许有针对性的更改和升级并充分延长正常运行时间。低成熟度的应用程序由紧密耦合的大型组件构建而成,变得高度相互依赖,必须作为单个实体进行管理。必须针对每个应用程序记录这些服务关系。
  3. 运营就绪性:云改变了技术架构以及工作流程、技能组合、可用工具和运营模式。高成熟度的应用程序已经可以像云应用程序一样运行,并使用在云中运行良好的流程、标准和工具集。低成熟度的应用程序会发现云中缺少关键的支持服务,支持团队采用的技能组合不适合云工作,或者使用的流程会因迁移到云而中断。

根据这些因素评估应用程序的成熟度后再开始迁移,您可以制定适当的计划,避免下游出现意外,造成延迟、增加成本并未实现目标。由于当前的生产环境、支持服务套件和目标云环境将在整个过程中继续演变,迁移的复杂性很难小觑。揭示服务和应用程序之间的联系不仅可以提前进行智能规划,而且可以使规划灵活地应对迁移过程中不可避免的变化。如果有效地记录下来,这种评估应为迁移过程提供一个清晰的待办事项清单。这将有助于确保预计的迁移时间表会继续与不断变化的路线图保持一致。


Zoom 可在 Oracle Cloud Infrastructure 上快速扩展并激活数百万个并发会议。

Zoom"我们最近经历了业务有史以来最为显着的增长,需要大幅提高我们的服务能力。我们了解了多个平台,Oracle Cloud Infrastructure 在帮助我们快速扩展容量和满足新用户需求方面发挥了重要作用。"—Eric S. Yuan,Zoom 首席执行官

了解更多信息


财务目标

与任何 IT 计划一样,云过渡需要一系列投资才能实现其全部价值,特别是如果目标应用程序是为本地托管模式而构建的,更需要投资。被认为值得迁移到云的应用程序最终将随着时间的推移成为云原生应用程序或停止使用。然而,最初的目标通常是让应用程序达到云版本状态。

将应用程序从其当前状态变为云版本状态需要做出一系列决策和初始投资。您是否计划简单地将应用程序直接迁移到裸机服务器(在这种情况下,大部分投资落在云基础架构上),或者计划在移动之前使应用程序具备云就绪性(在这种情况下,需要一些投资将部分应用程序堆栈迁移到基于云的模型,例如将数据库从本地迁移到 DBaaS 或 Oracle Autonomous Database)?如果您创建了硬编码的定制项来启用特定于客户的功能,则必须针对某种模式对其进行重构,在该模式中平台组件被封装并通过 API 作为产品化功能交付。为了在云中扩展高度分布的应用程序,需要删除硬件或平台依赖项。了解这些投资是规划和实现迁移到云相关财务目标的关键因素。

初始投资涉及在我们刚刚讨论的云迁移阶段做出所需产品更改需要的开发时间和劳动力。然而,额外的开支也必须考虑在内。组织在过渡期间可能产生的大量开支包括:

  • 开发投资:重新构建产品或加速迁移工作(包括支持数据库迁移和应用程序配置等活动的自动化功能)所需的开发劳动力
  • 迁移执行:配置新资产、迁移现有环境和数据以及停用旧库存所需的劳动力资源
  • 基础架构采用:IaaS 过渡期间产生的订阅费用,IaaS 将过渡到稳定状态,该费用代表在迁移期间出现的新增长
  • 搁置的基础架构:迁移过程中产生的数据中心和资本支出折旧成本,在可以被消除或冲销之前一直存在
  • 员工过渡:与培训、教育或重组现有团队或获取具有所需云技能组合的新资源相关的开支
  • 客户过渡:与新模式中无法支持的环境特征或服务条款变更相关的成本,包括新开发、激励措施、合同项目的重新谈判或客户流失

这些成本中每一项都或多或少是向 IaaS 过渡的必要组成部分。每个都以不同的方式影响着您的成本状况。例如,开发投资和迁移执行开支可能属于一次性费用,即使与这项工作相关的资源可能是固定的。新基础架构的采用将导致一段时间内开支净增长,直到消除搁置的基础架构开支。一些员工和客户过渡开支(如培训或迁移奖励)为一次性开支。员工扩招或客户合同的变化等其他因素可能会导致出现新的持续开支。

了解这些动态随着时间的推移将发生怎样的变化对于组织为云过渡做好准备和设定预期至关重要。如果组织对云的巨大优势很感兴趣,但对过渡风险缺乏清晰的了解,那么最初的早期开支增加会令您震惊,特别是前期要承担迁移、重叠基础架构和过渡成本。设定正确的期望并了解增量进度是在组织过渡期间保持一致性和原则性的基本要素。

云迁移清单

云迁移清单对迁移到云必不可少。什么是云迁移清单?简单来说,它是包含了环境中所有资产以及描述每项资产的相关关键数据元素的列表,列出了要移动的应用程序及其所有依赖项。用于捕获该数据的媒介无关紧要,并且由于数据通常会跨越公司内的各个部门,使用多种工具十分常见。所需的信息通常散落在一系列生产、销售和运营数据库中。例如,配置管理数据库可以详细跟踪技术依赖项和资产位置,获取物理服务器和机架位置。但是,该清单不包含对确定何时以及如何通知客户过渡至关重要的企业和客户注意事项。这类信息通常包含在为运营和支持利益相关方设计的信息库中。此外,收购、特殊用例和产品孤岛可能意味着这类信息被进一步分散在多个信息库中。

迁移清单的主要目的是提供管理迁移到云所需因素的集中式视图。例如:资产是什么?资产在哪里?它支持什么产品?有何用途?它支持哪些客户?

从一开始就要意识到,蓝图是一份鲜活的文件。它必须是灵活的,因为它会随着时间的推移而演变,特别是对于拥有多个应用程序或多个应用程序版本的公司来说。清单将随着新问题的出现和新需求的发现而演变。甚至底层云基础架构也可能在迁移过程中发生变化,从而再次改变清单。迁移清单应尽可能多地获取可用数据,让您能够开始初步规划,然后在过渡显示新需求时增加细节。

管理迁移清单本身就是一个跨职能的项目,必须平衡对详细数据的需求和收集数据的工作。它还包括确定依赖项、限制和资源的要素,这些要素将对时间和速度造成影响,例如精细技术规范、架构方法、客户要求和数据传输路径。如果信息太少,清单就没什么用处。但若信息太多,维护起来又会产生很大的负担,可能会很快过时,无法使用。

我们推荐以下迁移清单框架,作为云迁移的起点。

从迁移清单到运营清单

虽然我们把重点放在迁移清单上,但云过渡最终会带来两个挑战。最直接的是,它产生了对迁移活动进行规划、优先排序和跟踪的需求。但是,迁移本身会强制改变其日常运营跟踪所需的数据。例如,有关物理服务器和机架的迁移后配置详细信息将变得无关紧要,甚至个别实例的信息也将变得没那么重要。与此同时,总体使用情况和数据出口等指标可能会变得至关重要,尤其是在组织采用自助服务模式时。

创建迁移清单会开启向这些以云为中心的新数据模式和流程的过渡。虽然创建清单和迁移应用程序的双重挑战相互独立,但不应孤立地解决。迁移工作是主要工作,组织可能是第一次创建详细的综合资产视图。这是一个变革性时刻,应该形成新的迁移后清单视图的模板。如上所述,迁移清单需要具有灵活性和适应性。如果管理得当,迁移清单将演变成一个有价值的迁移后清单管理工具。

第 3 章:开始云之旅

试行云转型之路

设计托管 SaaS 应用程序的基础架构

作为提供基于 SaaS 的应用程序的 ISV,您需要安全、可扩展的企业级基础架构来托管您的服务并以隔离的方式管理您的客户。下面图 3 中描绘的参考架构提供了一种包含优秀实践的经验证框架,使您能够在 Oracle Cloud Infrastructure 上托管您的 SaaS 应用程序。

在此参考架构中,您可部署和管理多个隔离的应用程序实例。每个部署都针对特定租户,这些单独的租户应用程序实例通过共同的管理层进行管理。

您可以选择使用单个代码库构建所有的租户应用程序实例,也可以为每个租户提供自定义版本的应用程序。这种模式非常适合需要完全隔离应用程序环境的 SaaS 客户。

图 3:OCI 上 SaaS 应用程序的优秀实践参考架构

有关上述参考架构的更多详细信息,请访问 Oracle 架构中心。此外,我们还创建了基于 Terraform 的工具,协助为四个租户部署架构,并提供分步指南。最后,我们始终建议遵循 Oracle Cloud Infrastructure 优秀实践指南,它为四个常见的业务目标提供了指导:安全性和合规性、可靠性和弹性、性能和成本优化以及运营效率。

除了架构变化之外,您还需要考虑服务体系在云中会发生怎样的变化。在为本地架构开发的旧环境中部署的用于监控、网络管理或安全的核心工具集将针对云发生演变。迁移到云为扩大这些工具的处理范围提供了机会。基于云的工具不是主要监控端点,而是监控整个堆栈。有时,云服务提供商会在核心功能之外提供基于云或混合云的监控工具。在 Oracle Cloud Infrastructure 中,原生监控、标记和审计功能的组合能够实现服务体系的全面监控,且通常会自动修复在指定规范之外发现的异常。如果您当前在本地使用的是第三方监控工具,这些供应商也可能会提供混合云或基于云的工具。


Cisco Tetration 将其核心应用程序移到 Oracle Cloud Infrastructure,性能提升了 60 倍。

Cisco Tetration"与 Oracle 的合作非常愉快。所以 Cisco Tetration 才会出现了这样的奇迹。"—Navindra Yadav,Cisco Tetration 创始人


制定试验计划

与所有工程工作一样,从一个小型试验计划或原型入手,让试验团队和组织了解可以做什么以及如何进行,能够充分提高成功的几率。试验和概念验证计划可明确和解决挑战,没有全组织范围的全面变革面临的那种时间和财务压力。试验计划可以帮助您缓慢迁移并熟悉新的运营环境,控制变革的速度。

试验是核心开发人员和运营人员团队探究目标云环境、了解架构、服务和运营模式的机会。该团队掌握了实践知识、有用的工具和优秀实践,积累了信心、专业知识和经验。团队在积累这些知识的同时,也调整着在基于云的环境中团队间协作的路线方针。云迁移需要应用程序团队从直接的资源管理者转变为其他团队提供的服务的消费者。试验可让应用程序团队了解服务边界的变化,如何与提供所用服务的运营团队建立关系,并学习如何向这些运营团队传达自己的需求。

试验有以下好处:

  • 提供一个环境,可验证(或质疑)技术可移植性的假设,特别是在技术一直在相同环境中运行的情况下。这有助于团队了解他们是否做好了迁移的准备,并确定为实现迁移需要做出怎样的改变。
  • 提供了确认应用程序/数据库是否准备好与目标环境中的服务集成的机会。团队可从中了解需要进行哪些更改,以及应用程序和目标服务环境何时准备好进行迁移。
  • 能够针对目标环境进行构建,创造立足点,作为其余产品组合迁移到新服务和新环境的起点。这为团队的产品组合提供了战略目标。

Manhattan Associates 将他们的供应链解决方案迁移到了 Oracle Cloud Infrastructure,比之前的云解决方案节省了 50% 的成本。

Manhattan Associates"Oracle Cloud 在应用程序层和数据库层灵活且功能多样,与以前的云解决方案相比,我们在基础架构方面的成本节省了约 50%。"—Jeff Demenkow,Manhattan Associates 副总裁


管理试验计划

试验对技术和运营员工以及执行和管理团队来说,是一次学习体验。执行和管理团队应与试验团队保持持续沟通,帮助清除组织障碍,确保组织充分利用试验项目的经验教训(即哪些有效、哪些失败、优秀实践、经验教训和标准模式或发现的反模式)。获取这些有价值的信息,然后与组织的其他成员共享,在理想情况下可以使后续的云项目更加高效。管理层可借助试验测试制定计划时提出的假设,理清不确定的地方。虽然这些假设因组织而异,但试验计划在任何迁移中都会面临一些关键挑战。

  • 培训:试验可测试现有技能,揭示组织对技术迁移工作的准备情况。管理层应该使用试验来评估技术熟练能力,了解哪些工具和能力最需要学习,并计划如何快速培养(或雇用人员获取)这些关键领域的技能。
  • 协作:试验展示了开发、运营和支持团队将如何以不同的方式协同工作。管理层应确保这些团队在试验期间可切实合作,暴露新要求并了解如何在这种新环境中运营。
  • 改变的欲望:试验是发现会对更广泛迁移造成影响的文化壁垒的机会。在试验中出现问题的团队在大规模推行时也同样会出现问题。试验是管理层发现问题、部署培训并根据特定组织的现实情况调整计划的机会。

顺利迁移的关键是奠定坚实的基础。迁移的第一阶段将推动一系列核心服务和平台的开发,随着迁移的进行,这些服务和平台将逐渐扩展。最终,这些核心功能需要进行扩展以为整个迁移产品组合提供支持。因此,初始云版本不仅要成功,还要为所有后续版本和升级开辟道路,这一点至关重要。

第 4 章:基于云的组织成果

适应组织的变化

设计托管 SaaS 应用程序的基础架构

组织交付模式和客户关系的改变可能需要新的技能、知识、业务流程和思维方式。这些改变会对整个组织产生广泛影响,这就是为什么文化改变常常被认为是云过渡中最困难的方面。

由于这些变化的范围很广,可能会给人留下这样的印象:云过渡需要大规模重组并替换员工,引入具有云经验和专业知识的劳动力。虽然内部职能专业化的改变和注重招聘具有云技能的新成员是云过渡的重要环节,但失去迄今为止对成功至关重要的既定流程、动态和贡献者也是难以承受的。您必须平衡组织改变的速度与对当前业务和客户体验的潜在干扰。维持这种平衡需要重新调整职业发展能力的结构变化,有助于现有员工过渡到新的运营模式。

将存在已久的软件业务过渡到云交付模式,在众多关键业务领域的假设、技术知识和标准操作流程方面都要发生巨大转变。虽然需要改变的体量可能令人生畏,但我们的经验表明,保留和投资现有团队通常比尝试全面改革云专家要好。计划进行类似过渡的组织应该看看我们的 GBU 组织,首先对变革需求进行自下而上的分散评估,允许每个团队制定各自的迁移清单和服务体系路线图,从而在各自的控制范围内确定了所需的执行步骤。这种方法使团队能够将他们的计划与具体的变革驱动因素相结合,同时避免对可能的所需作出概要假设。


8x8 通过迁移到 Oracle Cloud Infrastructure,实现了全球互联,不仅成本降低 80%,服务也得到了完善。

8x8"随着视频会议迅速成为连接当今新世界的关键,我们的用户数量激增。为了支持这种指数级增长,我们考察了多个平台,最终选择了 Oracle 的第二代 Cloud Infrastructure,因为它具有强大的安全性、出色的性价比和卓越的支持服务,可以满足新激增用户的需求。"—Vik Verma,8x8 首席执行官

观看视频


业务影响

成功实现云转型既能促进整个组织发生变化,也能通过组织的改变获得支持。从主要托管或本地产品组合转变为基于云的业务,组织与客户的互动方式需要发生根本性的转变。但是,既定业务实践和假设的变化程度将在很大程度上取决于云过渡中产品的更改范围。

即使在变化很少的场景中,向 IaaS 的转变也会推动业务流程的转变。我们的 GBU 确定了这种情况中的两个关键变革机会。

  1. 用考虑短期波动和长远预期的以运营支出为导向的预测模型取代资本支出密集型物理基础架构管理
  2. 发展从传统职责中解放出来的安全和合规性团队,专注于提供服务内容

应对这些变化和应用程序技术变化的组织将更好地发挥云迁移的全部潜力。

客户调整

从提供"收缩包装的"产品,甚至从托管产品到实际云服务的过渡,是您和您客户要携手完成的旅程。事实上,正是这种向即服务模式的转变,将云与之前所有的托管模式区分开来。向着云服务的每一次改变都会影响客户的体验,从可扩展性到正常运行时间再到弹性都会受到影响。某些情况下,客户可能会要求,甚至恳求改变为新的交付模式。在其他情况下,对特性、功能和成本的期望可能会向着只能通过基于云的交付获得支持的方向发展。

当您开始让客户参与云战略制定时,您须做好准备,可能会面对两种观点:对路线图兴奋不已和不愿走出舒适圈。回应这些观点需要清晰、有分寸的沟通,指明努力的方向,不要迷失在技术细节中或引发危险信号。这是让组织内面向客户的团队参与其中的关键时刻,确保他们了解正在开展的工作、企业正在进行的投资以及产品和交付的预期成果。为此,面向客户的团队需要将这种改变转化为能够增强客户对服务的信心的条款。

对于将要使用云服务的客户来说,情况可能会变得更复杂一些。有一些客户群体需要云服务,他们了解 SaaS 在效率和灵活性方面的优势。然而,随着云或 SaaS 选项已成为赌注,客户需要了解区分供应商服务的功能和服务级别协议,而不是云本身的价值。

不过,并非所有客户都渴望得到云服务。尤其是采用托管或代管服务模式的现有客户可能会很满意现状,如果他们拥有与云交付不一致的定制服务组件或非标准环境和访问模式则更是如此。即使客户看到了迁移到云服务的优势,也可能会对交付条款的变化或迁移环境需要中断服务的情况感到不安。

让客户安心需要营销、销售、支持和客户成功团队之间进行协调、一致的沟通。在理想情况下,客户根本不会意识到他们的工作负载已迁移,不知道发生了什么变化,但有一天发现性能得到了改善。可现实情况是,将服务迁移到云通常需要升级和停机时间,并且服务条款或可用功能也可能需要更改。指导客户完成这些同时与整体过渡时间表保持一致是一项复杂的工作,仅仅了解改变的好处是不够的,还需要认同发生的变化,与可能影响客户业务的迁移步骤保持一致。


CMIC 将他们的建筑企业软件迁移到了 Oracle Cloud Infrastructure,部署速度提高了 10 倍。

CMIC"除了 OCI 相比其他云提供商更具成本优势之外,我们现在还更加敏捷。OCI 使我们的技术灵活性达到了新的水平。借助 Oracle Container Services 和 Oracle Autonomous Database 等技术,我们可以继续专注于提供卓越的建筑 ERP 软件,大步向未来迈进。"—Vince Di Piazza,CMIC IT 和云基础架构总监

观看视频


一旦客户接受了云过渡所带来的好处和变化,组织面临的最后一步就是将客户的工作负载实际转移到新环境中。于是,确定新环境迁移和验证测试的理想时间便成了又一挑战。接受了将面临一段时间停机的客户通常仍会对具体的停机时间态度强硬。

虽然客户的喜好对您来说很重要,但您必须平衡许多其他问题。计划迁移涉及到多种因素的权衡,包括产品或服务的技术属性、所有客户偏好的协调、内部资源限制和业务目标,例如整合/消除现有的旧数据中心或终止否决的产品线。为了平衡这些相互冲突的优先事项,可以让面向客户的团队参与迁移规划活动,因为他们将代表市场预期发表关键意见。

正如组织必须为投资和迁移期以及云交付模式的技术和业务流程持续变化做好准备一样,它也必须为如何就迁移接洽客户及产品与客户关系的新常态做好准备。

我们的 GBU 审查了过渡在技术、运营和交付承诺方面会对客户造成怎样的影响,将那些需要特别关注、接洽和可能改变商业关系的客户分离出来,率先满足了这些需求。让面向客户的团队做好准备的工作逻辑也与之类似,涉及产品、运营、战略和其他团队之间的协作,以提供通用的云知识,同时解决具体的产品和客户变化。

这项工作不仅仅是让面向客户的团队做好接洽客户的准备。将跨职能的核心领导层聚集在一起协调客户接洽,也创造了宝贵的机会,可将主要由技术主导的计划扩展为更广泛的举措,重新审视我们解决方案的核心价值,重新阐明我们产品的独特之处,并规划在市场中保持和发展这种价值的理想方法。

第 5 章:五大挑战

提前准备

设计托管 SaaS 应用程序的基础架构

在此手册中,我们根据数千个实例中托管的 60 多个 GBU 应用程序的迁移经验,提供了优秀实践指导。下面,我们总结了整个旅程中所面临的五大挑战,我们认为这些挑战适用于将应用程序迁移到云的任何组织。

  1. 确定迁移前的开发工作
    针对云版本准备既定应用程序可能需要大量投资,尤其是使产品达到云原生状态更是如此。投资云原生应用程序原则可从云中获得最大受益,但同时也会消耗大量时间和开发资源才能达到最终状态。产品达到云就绪所需的时间越长,就会进一步推迟获得迁移到云的固有、增量优势,并且还可能延长通常与传统环境相关的风险的暴露时间。同时,并非所有产品都能平等受益,具体取决于它们的生命周期阶段和客户态度。充分了解并记录迁移前要进行的开发工作量是迁移成功的关键。

    GBU 应用程序群多种多样,包括处于各个云成熟度水平和生命周期阶段的产品。虽然所有应用程序都需要迁移到云中,但问题在于在云发布之前应该对产品进行多少更改。要找到正确的平衡点需要组织对每个产品的生命周期阶段、发展潜力和将产品移动到云所需的工作进行评估。基于这些综合评估,GBU 确定了每个产品的优先级和开支水平。
  2. 确定开发组合
    在为云投资准备提供多少工程带宽与开发满足市场需求的新特性和功能之间寻得平衡,对 GBU 来说十分不易。

    GBU 并非难以就云过渡的优先事项达成一致,但产品团队确实难以理解应该为云功能付出多少努力才能改善客户体验和性能,又不替换客户所需的功能。云开发需要投资培养基础运营能力,这可能会分散企业对客户需要新功能的反应能力。这些权衡使得我们很难弄清楚如何分配云就绪和产品增强计划的分配时间。

    为了应对这一挑战,GBU 依靠第 1 章中讨论的云成熟度框架来深入了解每条路径所需的相关开发投资。然后,他们研究了每个潜在云过渡阶段的 ROI,并在该结果与新功能开发预期的潜在收入贡献之间进行了权衡。这提供了一种通用评估框架,可用于确定正确的工作组合,保持对目标业务成果的可见性。
    Altair 选择了 Oracle Cloud Infrastructure 的高性能计算功能,性价比提高了 20%。

    Altair"我们纵观外面的所有云供应商,发现 Oracle 非常专注于 HPC。他们的裸机产品,我认为是业内首创,具有高速、低延迟的网络,这对我们来说非常重要。"—Piush Patel,Altair 战略关系高级副总裁


  3. 了解机群
    无论您的公司是拥有单个应用程序还是大型产品组合,在云迁移过程中都有许多因素需要跟踪和清点。为了充分理解需要进行哪些更改,您必须充分了解现有应用程序信息库中的当前清单以及计划在云中使用的内容。如果您有许多应用程序要迁移,则可能并没有现有清单,或者您可以依赖有关特定应用程序状态的口口相传的知识。即使公司只拥有单个面向客户的应用程序,也仍然需要清点整个应用程序堆栈,以确定在迁移到云时需要更改哪些方面。了解哪些需求在云中会发生变化及需要什么样的设计是记录过渡所需工作的关键方面。

    根据每个应用程序实例的特点(版本、硬件/平台依赖项、定制、客户访问模式等),需要对每个实例执行不同类型和体量的工作。此外,应用程序数据可能会分布在多个记录系统中。

    Oracle GBU 整合了 30 多个收购企业,机群涵盖 80 个数据中心和 12,000 多个应用程序实例。与这些实例相关的关键数据高度分散,并且在组件产品团队之间也不一定是以一致的方式进行管理。如果没有这些信息,他们就无法有效地组织和规划迁移劳动力。为了清楚地了解需要迁移的内容,GBU 必须开展专门的数据收集和整合工作。

    "通过迁移到 OCI,Oracle GBU 团队将资本支出降低了 80%,将基础架构成本降低了 64%。"—Mike Prindle,GBU Cloud Architecture 副总裁
    Oracle@Oracle


  4. 优先考虑和组织迁移工作
    实际上,移动工作负载可以采用多种方式,从复制现有 VM 的映像到安装新实例和复制数据都是具体的移动方法,但所有方法都需要一定程度的技术投资或劳动力投入才能完成。迁移涉及的劳动力数量和各种类型在组织机群的各个产品环境中成倍增加,很容易变得难以应对。可用于完成迁移的资源是有限的,通常还需负责管理日常运营。
    OceanX 将他们的商业智能系统从 Amazon Web Services (AWS) 迁移到了 Oracle Cloud Infrastructure,性能提升了 3 倍。

    OceanX"我们需要我们的数据平台以较低的成本实现扩展和提供高性能。将数据平台从 AWS 迁移到 Oracle 是 OceanX 最成功的迁移之一,再加上性能的大幅提升和大量的成本节约,意味着整个项目取得了巨大的成就。最终,我们能够为客户提供一个平台,让他们能够更快地做出更明智的决策。"—Vijay Manickam,OceanX 数据和分析部副总裁


    GBU 云过渡需要 3,000 多个独立的迁移项目。这些项目最初是根据客户偏好(即根据客户的综合反馈确定迁移时间框架的优先级)或特定环境的迁移就绪情况来确定优先级的。但到头来,这种方法未能在迁移过程中对推动增量业务收益有所助益。由于没有共同的优先级或协调框架,GBU 发现迁移活动量也未能一致。高资源争用期和资源浪费期交替出现,给负责完成迁移工作的团队带来了沉重的负担。

    为了解决这些难题,GBU 建立了一个专门负责迁移的中央计划管理办公室和一个执行监督委员会,负责根据目标业务成果确定迁移的优先级并确定关键机会。
  5. 管理组织的变化
    云转型涉及的变化需要新领域的知识、技能组合和流程,以及其他领域的文化改变。应对这些人力资源挑战可能比管理云过渡的技术组件更难。为了解决这个问题,Oracle GBU 大力开展培训,帮助现有团队演变为云团队。要解决何时引入新人才以及何时寻找其他机制来发展组织的问题,需要 GBU 针对其主要职能领域和产品组进行员工评估,然后针对每个用例制定适当的改进计划。如果您的公司有多个应用程序需要迁移,考虑可以在哪里培养涵盖所有产品的基础云知识,如安全性和通用 IaaS。

第 6 章:结果和入门

庆祝结果

本手册根据 Oracle GBU 团队在将 60 多个基于 SaaS 的应用程序迁移到 Oracle Cloud Infrastructure 的实践中积累的经验编写。这些应用为八个行业垂直市场的核心企业功能提供支持,全球拥有超过 199,000 名客户。用心、有计划且执行良好的迁移带来了巨大的收益。

  • 将 80 个数据中心整合为 11 个
  • 资本支出降低了 80%
  • 基础架构成本降低了 64%
  • 软件供应商从 28 家减少到 10 家
  • 软件开支减少了 42%
  • 改为每天发布软件
  • 配置时间缩短了 98% 以上
  • 计划停机时间缩短了 98% 以上

虽然此 ISV 手册根据我们 GBU 团队的经验编写,但他们的实践只是向 Oracle Cloud Infrastructure 的几次大型迁移中的一个。鉴于我们所有 SaaS 应用程序的收入和客户数量,Oracle 可被视为世界上最大的 ISV 之一,我们十分了解迁移过程。实际上,我们已将整个产品组合(包括 Oracle Fusion Cloud ERP、Oracle Fusion Cloud EPM、Oracle Fusion Cloud HCM、Oracle Advertising and CX 和 Oracle Fusion Cloud SCM)迁移到了 Oracle Cloud Infrastructure。这些迁移是我们 Oracle@Oracle 转型计划的一部分。这是一个多年期项目,涉及分布在数十个数据中心的数万个应用程序。

以下是这些迁移带来的一些好处。

  • 基础设施 – 在我们的应用程序组合中实现了 99.99% 的可用性,成本节省了 30%,性能提升了 2 倍– 10 倍
  • 财务 – 获得了在不到 10 天的时间内结账和报告收益的能力
  • 人力资源 – 人才审核周期缩短了 70%
  • 供应链 – 供应链计划周期从 1 周缩短至 48 小时,速度提高了 71%
  • CX – 活动准备实践从 4 周缩短至 5 天,速度提高了 82%
  • 可持续性 – 2019 财年,Oracle 收集的停用设备有 99.4% 得到了再利用或再循环

与 Oracle 合作

我们正在帮助 ISV 扩大他们的潜在市场,同时提高他们的顶线收入增长潜力。向我们发送电子邮件:oraclecloud-isv_ww@oracle.com,了解更多。

要详细了解 ISV 为何选择 Oracle Cloud,请考虑查看以下资源:


Körber 将仓库管理系统整合到了 Oracle Cloud Infrastructure 上,运行速度提高了 40%。

Korber"我们在评估不同的决策时,OCI 对我们在进入市场战略方面的尝试非常具有战略意义。"— Rick Schrader,Körberö 北美销售和联盟高级副总裁

观看视频


注:为免疑义,本网页所用以下术语专指以下含义:

  1. Oracle专指Oracle境外公司而非甲骨文中国。
  2. 相关Cloud或云术语均指代Oracle境外公司提供的云技术或其解决方案。