成功的云迁移： 迈出这一步

您可能不知道，但我们今天所知的云是由当时的谷歌首席执行官埃里克施密特 (Eric Schmidt) 于 2006 年 8 月首次定义的。 如果我们对自己诚实的话，直到很久以后才有人认真对待这个想法（至少在任何实际意义上）。

仅仅五年之后，云计算就已获得广泛应用，人们开始认真思考将传统应用迁移到云平台的影响。 事实上，以前在平台迁移方面吸取的很多教训今天仍然适用。

正如我之前在这个论坛上分享的那样，没有什么是容易的，一旦你决定迈出云计算的一步，真正的工作就开始了。

每一次成功的迁移工作不仅需要制定支持迁移的全面策略，而且还需要提前做出有时很艰难的决定。 最诱人的决定是完全跳过这一步并直接进入迁移活动，但这种“简单”的决定可能会导致云迁移失败。

采用最佳实践模型的 IT 专业人员首先要了解期望的结果以及验证和衡量旅程成功的机制。 从那时起，就可以充分评估需要迁移哪些应用，并了解迁移目标（例如，提高性能、减少延迟、扩展）。

第一阶段——你真的想这样做吗？

尽管人们对其大肆宣传并承诺降低成本，但并非每个企业或每个应用都应迁移到云框架。 请不要误会，许多应用程序都非常适合云部署，而且有些应用程序比其他应用程序更容易移动，但需要仔细考虑业务影响。 我经常听到这样的恐怖故事：一位高管在没有充分理解这意味着什么的情况下就命令 IT“迁移到云端”……如果您像我一样，那么没有什么比充分理解更好的了。 更好的方法是根据您在总体战略中设定的目标制定真实的商业案例。 回答这个问题：“我为什么要这样做？” 而且，老实说，如果节省成本的吸引力是唯一考虑的标准，那么您可能犯了一个错误。

第二阶段——我应该移动什么以及为什么？

不同的专业人士对这一阶段有各种不同的称呼，但它实际上是对现有环境进行盘点。 例如，如果您有机会在本地环境中的 VMware 框架中运行您的应用，并且您正在寻求额外的扩展，那么利用刚刚宣布的组合 F5/VMware/IBM Cloud 产品可能正适合您。 通过提供经过验证的解决方案，该解决方案不仅利用 F5 的 BIG-IP 虚拟服务套件，还利用 VMware Solutions 产品组合的 IBM Cloud 的自动配置和集成，使我们的云迁移变得更加容易。

利用此解决方案的一些好处包括：

• 可扩展的应用交付以减少停机时间
• 利用对 F5 可编程性的现有投资来缩短产品上市时间
• 消除快速工作负载部署的障碍
• 提供本地和 IBM Cloud 之间的工作负载可移植性
• 通过无缝应用故障转移消除停机时间
• 一致应用F5 企业级性能、可用​​性和安全服务

如果您在不同的框架内运营，请仔细考虑底层支持设施（例如计算、存储、基础设施）和与软件许可相关的限制。

此阶段的一个好的经验法则是真正考虑应用本身（除了运行它需要什么）。 虽然迁移几年前开发的应用可能有意义，但尝试迁移已存在十年的应用可能意义不大。 永远不要忘记技术债务的负担——是的，这是当今被过度使用的术语，但真正的挑战是使其正常运行所需的领域特定知识，更不用说在新领域了。 就像 CTR/IBM 的托马斯·沃森在 1911 年所说的那样，“思考！”，你就会成功。

第三阶段 — — “我要去！”

设计。 设计。 设计。 迁移。 证实。 重复。 如果您遵循这个简单的建议，您的成功机会就很高。 当今许多企业都采用了 CI/CD（持续改进、持续交付）策略来推行云计算。

大多数努力都是从本质上相对简单的应用开始，并从那里学习。 我也发现这种方法即使在我自己的团队中使用也是最有效的。 迭代过程有助于快速、持续地改进产品和服务——在这种情况下，您的应用在云中取得成功。 当你的第一步取得成功后，随着你的学习，下一步就会变得更容易。

当然，一旦您确定一切正常运行并且宇宙还没有终结，请确保您有一个概述的策略来测试新部署的应用并关闭传统系统。

我对这一阶段的最后一个建议是......我个人发现最好（也是最成功）的部署是应用开发团队和网络运营团队在整个过程中协调一致并共同努力的部署。

第四阶段——采用现代的、面向云的实践

作为您踏上云之旅的第一步，并且当您的第一个应用从您放弃的那些传统系统中迁移出来时，请记住现代 IT 是关于系统级思维，而不是任务级参与。 成为一个按钮创造者，而不仅仅是一个按钮推动者。

在我的下一篇文章中，我将为您提供一些有关实际迁移选项的更具体的想法。 敬请关注。