过早停止应用程序或云迁移可能比根本不迁移造成更大的危害。
您是否正在计划应用程序迁移?也许您正在将本地应用程序迁移到云端，或者您正在将单体应用程序迁移到面向服务或微服务架构。
诸如此类的迁移是承诺。时间的承诺。资源承诺。心态和企业能量的承诺。
迁移并不容易实现。
迁移可能涉及长期且不断演进的过渡，而且通常所付出的努力与实现的收益并不直接一致。收益往往比投资晚得多。有时，事情在好转之前甚至会变得更糟。
很想提早退出迁移。
谁会想要这样做?这看起来很疯狂，但它确实发生了。从整体迁移到服务架构，但在迁移开始后不久停止，会使应用程序的状态比开始迁移前更糟。
那么您如何避免阻止迁移的诱惑呢?嗯，这完全是关于管理期望和了解真正的投资回报。
痛苦之谷
当我们开始重大迁移，尤其是复杂的迁移，例如单体到微服务的迁移时，我们对最终会看到的好处有一定的期望。我们预计收益取决于我们在迁移中投入的精力和时间。我们计算出ROI(投资回报)将使迁移的努力变得值得。
但这最终成为确定迁移价值和收益的简单观点。简单的ROI计算并不能充分体现我们对我们的努力将如何转化为收益的理解。通常，我们认为收益和投资会随着时间的推移而一致地发挥作用。
随着时间的推移，我们继续对迁移进行投资，我们预计我们获得的实际或感知的好处将继续增加。我们投入的精力和时间越多，我们获得的收益就越多。或者我们认为。
实际上，这种理想化的模型并不能代表迁移的正常工作方式。投资与收益之间的关系通常要复杂得多。
在这里，初始投资似乎没有太大的好处。事实上，随着最初情况变得更糟，我们实际上可能会看到收益的倒退。只有随着时间的推移，真正的好处才会开始显现。
让我们考虑一个例子。想象一下，您正在将单体应用迁移到面向服务的架构。最初，当您开始将单体应用的一部分更改为服务时，您可能会遇到性能下降的情况。应用程序的复杂性会增加，因为您的应用程序包含更多的活动部件。您继续向应用程序添加更多单独的服务，但单体应用程序的剩余部分仍然存在并且大量参与应用程序的功能。这种复杂性可能会导致可靠性问题;它可能会导致缩放问题;它可能会产生其他不可预见的问题。
简而言之，您的应用程序可能比开始迁移之前更糟。发生这种情况有几个原因：
- 您的代码处于临时状态，增加了与迁移相关的技术债务。
- 您的代码运行速度较慢，因为有些代码已更新而有些代码尚未更新。
- 您的代码更难理解，因为有些代码使用旧范式，有些使用新范式。
坦率地说，代码是一团糟。
但随着时间的推移，您会努力走出这个低谷，迁移工作的好处开始发挥作用。您的好处成倍增加。随着服务创建变得更容易并从整体中接管更多功能，您将开始看到您的努力得到回报。随着时间的推移，收益的增长将加速。最后，您将看到迁移的实际价值。
但是要看到这些好处，您必须渡过迁移初期的低谷。你必须通过我所说的痛苦之谷。
在这个山谷中，有一种强烈的想要放弃迁移的倾向。毕竟，您已经在迁移中进行了投资，却没有看到任何好处。相反，事情变得比以前更糟。
但不要在这里放弃。此时不要停止迁移。如果您坚持迁移一段时间，您将开始看到好处。最终，您将达到收益增长速度快于您投入的努力的程度。
掉进这个陷阱
我经历了许多迁移。几乎所有人都有这个山谷。但是，不幸的是，公司陷入了在这个低点放弃的陷阱并承担后果。
我合作过的一家大公司在最糟糕的时候放弃了他们的整体迁移——在谷底。在这样做时，他们只是“宣布胜利”。但是他们没有胜利。
他们告诉参与该项目的每个人，他们都从痛苦的迁移工作中“学到了足够多的东西”：“我们现在知道实施此迁移所涉及的内容，因此我们可以停在这里，也许稍后再重新选择迁移。”
该公司希望重新开始做“真正的工作”并停止投资迁移。他们最后告诉大家，“这次演习是一次宝贵的经历，你不觉得吗?”是的，这是一次宝贵的经历，但代价是什么?
该公司创建的是一个站不住脚的代码库。他们已经构建了几个服务，这些服务象征性地固定在剩余的单体的一侧。然而，巨石仍然存在，并且仍然难以处理。他们的代码一团糟，他们多年来一直饱受这种混乱所带来的问题的困扰。
这一决定严重削弱了公司在未来一段时间内生产新功能的能力。工程团队士气低落，公司失去了许多优秀的工程师。他们甚至造成了一些影响客户满意度的严重可用性问题。这在当时并不是一个愉快的工作环境。
这个故事的教训是：收益和努力之间的关系不是线性的。在迁移过程中，有时事情似乎变得更糟而不是更好。但不要放弃。隧道尽头会有光，好处将开始显现。从长远来看，这些好处将是非常值得的。
在开始迁移之前，请了解成本和收益。但更重要的是，要知道何时必须支付费用以及何时会看到收益。当成本开始增加时不要停止。如果你继续前进，好处最终会显现出来。
