专家建议：云迁移前先验证应用架构和必要性

更多企业正在转向混合云，因为它更符合业务需求。一些企业已经将部分数据从公有云迁回，而另一些则正从纯数据中心架构转移。使用多个公有云变得越来越普遍，许多组织也在通过混合云启用本地云服务。

对许多组织来说，将遗留应用迁移到云端面临挑战，主要是因为他们没有做好充分准备。例如，他们是否了解应用的依赖关系？能否真正迁移这个遗留应用？是否充分解决了数据和网络安全问题？应用真的需要迁移吗？如何确定迁移时机合适？

我们咨询了三位IT领导者的意见。以下是他们的详细回答：

Chronosphere的Bill Hineline：重构是关键

"你将在云上花费大量资金，所以必须理解关键应用不能简单地直接迁移。你可能能够将其容器化并快速部署到云上以获得一些快速效果，但如果不重构代码，就无法获得云端所需的优势和性能。

这需要全面的承诺，这就是为什么我从'为什么'开始。这意味着回到基础 —— 今天应用的健康状况如何，如果不健康，为什么不健康？然后，一旦它健康了，你需要承诺重构以及这对你架构的影响。否则，你可能会有一个无法按预期扩展的应用。

重构代码确实是一项重大工程。如果在建立良好的规范和治理之前就开始，那就是在为失败做准备。同样，如果你没有正确标记，就无法将其归属到项目，这就会成为成本问题。"

联合航空的经验教训

"我曾负责联合航空的可观察性，进行了大量云迁移。例如，MileagePlus忠诚度计划原本运行在大型机上，我们将其迁移到云端。代码重构和所有准备工作花了数月时间。

我们能够在一个晚上切换整个系统，因为我们从可观察性中获得了良好的洞察，了解系统如何运行以及相比大型机的性能表现。我们迁移是为了更好地扩展和进行更敏捷的开发。

我坚信保持技术的不可知性。如果你绑定到单一云提供商或单一工具，那没关系，但你会让不可避免的迁移变得更难。如果你不绑定到更专有的功能，就能为自己保留更多选择。"

Rimini Street的Eric Helmer：首先评估必要性

"首先要问为什么要这样做？很多时候是因为你要离开数据中心或硬件过时，但通常这是不必要的，可能会造成安全、集成或延迟问题。

如果你确实得出迁移是必要的结论，那么你真的必须确保应用架构正确。很多时候，这些工作负载并非为云环境设计，所以你必须调整它们，有意地为云工作负载设计架构。

对于关键任务应用的准备，关键是要查看适当性、操作系统和许可证。有时，许可证与CPU或其他东西绑定，可能会为你带来问题，所以回归、延迟和性能测试将是强制性的。

你必须测试以确保能够迁移应用，还应该有安装二进制文件（原始安装和设置文件）。有些人认为可以只备份应用并在那里恢复。有时可行，有时不行，所以你可能需要重新安装。如果你有应用二进制文件，是否仍有访问权限？能在公有云模型中执行吗？第一步是为应用找到合适的家。"

仔细权衡风险和成本

"IT领导者还必须了解将事物迁移到云端的相关风险和成本，以及与保持现状相比的利弊。因为旧系统，无论是昨天还是五年前采购的，从网络安全角度来看本质上都是脆弱的。风险二是互操作性和兼容性，因为旧系统不与新系统通信。第三个是可支持性，因为很难找到支持旧系统的老专家。

但是，如果我能让应用完全安全，与任何东西互操作和兼容，我能完全支持它，并且我们同意技术债务转化为技术，那么情况就不是火烧眉毛，我们不必对云做出膝跳反应。如果我们无法解决这些（网络、互操作性、兼容性和可支持性）风险，或者是时候转向SaaS模式或将基础设施即服务或云进行直接迁移，那么就是时候做出这些决定了。

在谈论投资回报率时，我的首要因素是投资回收的年份或月份是什么？这在很大程度上有助于指导决策，至少在财务上是这样。

一个例子是一个中型客户有多个仓库需要提高效率。问题是仓库经理必须登录ERP系统查看一些东西，登录供应商系统订购合适的东西，登录库存系统做其他事情。传统思路是将其整合到单一系统中。这是一个昂贵的提议，但这是我们必须做的。

我们还做的是在这三个系统之上放置一个界面，代表这些库存经理登录系统，提供完整的智能工作空间和聊天机器人，所以你可以询问五号仓库有多少小部件，而不是让某人登录三个不同的系统并在电子表格中协调事物。"

Pega的David Vidoni：警惕错误假设

"考虑遗留系统现代化是一个很好的机会，重新审视你正在做的所有事情，并对这些是否是要争论的正确事情进行理性检查。

这始于了解你拥有的系统和连接的性能概况 —— 事物在哪里运行，如何运行，如果有问题，如何将其转移到其他可用的地方？如果你在数据中心运行应用，它们一直在运行，所以你不用按分钟或小时付费处理。你真的需要了解你运行的应用的性能概况并进行适当的规模调整，因为如果你过度配置资源或运行太多，当下个月账单到来时，你可能会得到一些不愉快的惊喜。

有时，人们有一种错误的感觉，如果在云中，那我就万事俱备了。一切都可用，一切都高度冗余。确实如此，如果你在设计时考虑到了这些因素。

冗余不是免费的。如果组织可以容忍短暂中断，你可能可以选择成本低得多的选项来支持故障转移。如果是你能承受近零停机时间的东西，那会带来额外成本，因为你必须同时运行两个系统。我见过的两个最大错误是不了解今天运行系统的成本，以及没有足够的控制来监控和管理这些。

在保护方面，关键是确保禁用所有设置，这样在迁移到云端时不会过度暴露在互联网上。你需要系统之间以及调用它们的地方之间的安全通信。你还需要良好的监控，这样如果你看到任何异常，正确的团队就能收到警报并采取适当行动。

主要的成本驱动因素是工作负载本身。你在运行什么？在什么样的硬件资源上运行？你有什么功能可用？有不同层次的存储。有些比其他的成本更高。"

Pega迁移的经验教训

"在2020年，我们将ERP实施从托管数据中心迁移到Google Cloud，从开始到完成用了13周。这包括所有规划和开发环境的所有迁移。我们迁移了40多个环境，包括开发、测试和生产环境。

首先，我们进行了所有初始测试 —— 多次模拟运行并确保环境安全 —— 来正确调整环境规模，这样我们每月不会花费超过需要的钱。一旦我们了解了性能概况，我们通过预留一些容量锁定了进一步的节省。

我们还从数据中心迁移到AWS，这让我们能够利用弹性容量。我们还能够利用云中的一些AI功能。连接这些功能以及其他服务要容易得多，我们能够非常快速地做到这一点，而不必发送软件许可证或走传统路线。我的团队现在有很大的敏捷性来开启这些功能并快速为应用添加功能。

如果这是了解其余迁移情况的更广泛策略的一部分，你应该明白一些云在做某些事情上比其他云更好。如果你在AWS、Google和Azure中有工作负载，它们有数据出口费用。所以，你需要了解你的系统去向以及它们将与之通信的系统。它们是否都在同一个云中，还是跨不同云，这真的很重要。"

Q&A

Q1：云迁移前为什么需要重构代码？

A：因为关键应用不能简单地直接迁移。虽然可以容器化并快速部署获得一些效果，但如果不重构代码，就无法获得云端所需的优势和性能。重构代码能让应用更好地适应云环境，实现预期的扩展性。

Q2：如何判断遗留应用是否需要迁移到云端？

A：首先要问为什么要迁移。需要评估应用的健康状况、依赖关系、安全问题等。如果能让应用完全安全、互操作兼容并能得到支持，且技术债务可以转化为技术资产，那就不需要急于迁移。只有在无法解决网络安全、互操作性和可支持性风险时才考虑迁移。

Q3：云迁移中最常见的错误有哪些？

A：最大的两个错误是不了解今天运行系统的真实成本，以及没有足够的控制来监控和管理这些成本。另外，许多人误以为在云中就万事俱备了，但冗余和高可用性需要额外设计和成本。还有就是过度配置资源导致意外的高额账单。