不要停止云遷移
過早停止應用程序或云遷移可能比根本不遷移造成更大的危害。
您是否正在計劃應用程序遷移?也許您正在將本地應用程序遷移到云端，或者您正在將單體應用程序遷移到面向服務或微服務架構。
諸如此類的遷移是承諾。時間的承諾。資源承諾。心態和企業能量的承諾。
遷移并不容易實現。
遷移可能涉及長期且不斷演進的過渡，而且通常所付出的努力與實現的收益并不直接一致。收益往往比投資晚得多。有時，事情在好轉之前甚至會變得更糟。
很想提早退出遷移。
誰會想要這樣做?這看起來很瘋狂，但它確實發生了。從整體遷移到服務架構，但在遷移開始后不久停止，會使應用程序的狀態比開始遷移前更糟。
那么您如何避免阻止遷移的誘惑呢?嗯，這完全是關于管理期望和了解真正的投資回報。
痛苦之谷
當我們開始重大遷移，尤其是復雜的遷移，例如單體到微服務的遷移時，我們對最終會看到的好處有一定的期望。我們預計收益取決于我們在遷移中投入的精力和時間。我們計算出ROI(投資回報)將使遷移的努力變得值得。
但這最終成為確定遷移價值和收益的簡單觀點。簡單的ROI計算并不能充分體現我們對我們的努力將如何轉化為收益的理解。通常，我們認為收益和投資會隨著時間的推移而一致地發揮作用。
隨著時間的推移，我們繼續對遷移進行投資，我們預計我們獲得的實際或感知的好處將繼續增加。我們投入的精力和時間越多，我們獲得的收益就越多。或者我們認為。
實際上，這種理想化的模型并不能代表遷移的正常工作方式。投資與收益之間的關系通常要復雜得多。
在這里，初始投資似乎沒有太大的好處。事實上，隨著最初情況變得更糟，我們實際上可能會看到收益的倒退。只有隨著時間的推移，真正的好處才會開始顯現。
讓我們考慮一個例子。想象一下，您正在將單體應用遷移到面向服務的架構。最初，當您開始將單體應用的一部分更改為服務時，您可能會遇到性能下降的情況。應用程序的復雜性會增加，因為您的應用程序包含更多的活動部件。您繼續向應用程序添加更多單獨的服務，但單體應用程序的剩余部分仍然存在并且大量參與應用程序的功能。這種復雜性可能會導致可靠性問題;它可能會導致縮放問題;它可能會產生其他不可預見的問題。
簡而言之，您的應用程序可能比開始遷移之前更糟。發生這種情況有幾個原因：
- 您的代碼處于臨時狀態，增加了與遷移相關的技術債務。
- 您的代碼運行速度較慢，因為有些代碼已更新而有些代碼尚未更新。
- 您的代碼更難理解，因為有些代碼使用舊范式，有些使用新范式。
坦率地說，代碼是一團糟。
但隨著時間的推移，您會努力走出這個低谷，遷移工作的好處開始發揮作用。您的好處成倍增加。隨著服務創建變得更容易并從整體中接管更多功能，您將開始看到您的努力得到回報。隨著時間的推移，收益的增長將加速。最后，您將看到遷移的實際價值。
但是要看到這些好處，您必須渡過遷移初期的低谷。你必須通過我所說的痛苦之谷。
在這個山谷中，有一種強烈的想要放棄遷移的傾向。畢竟，您已經在遷移中進行了投資，卻沒有看到任何好處。相反，事情變得比以前更糟。
但不要在這里放棄。此時不要停止遷移。如果您堅持遷移一段時間，您將開始看到好處。最終，您將達到收益增長速度快于您投入的努力的程度。
掉進這個陷阱
我經歷了許多遷移。幾乎所有人都有這個山谷。但是，不幸的是，公司陷入了在這個低點放棄的陷阱并承擔后果。
我合作過的一家大公司在最糟糕的時候放棄了他們的整體遷移——在谷底。在這樣做時，他們只是“宣布勝利”。但是他們沒有勝利。
他們告訴參與該項目的每個人，他們都從痛苦的遷移工作中“學到了足夠多的東西”：“我們現在知道實施此遷移所涉及的內容，因此我們可以停在這里，也許稍后再重新選擇遷移。”
該公司希望重新開始做“真正的工作”并停止投資遷移。他們最后告訴大家，“這次演習是一次寶貴的經歷，你不覺得嗎?”是的，這是一次寶貴的經歷，但代價是什么?
該公司創建的是一個站不住腳的代碼庫。他們已經構建了幾個服務，這些服務象征性地固定在剩余的單體的一側。然而，巨石仍然存在，并且仍然難以處理。他們的代碼一團糟，他們多年來一直飽受這種混亂所帶來的問題的困擾。
這一決定嚴重削弱了公司在未來一段時間內生產新功能的能力。工程團隊士氣低落，公司失去了許多優秀的工程師。他們甚至造成了一些影響客戶滿意度的嚴重可用性問題。這在當時并不是一個愉快的工作環境。
這個故事的教訓是：收益和努力之間的關系不是線性的。在遷移過程中，有時事情似乎變得更糟而不是更好。但不要放棄。隧道盡頭會有光，好處將開始顯現。從長遠來看，這些好處將是非常值得的。
在開始遷移之前，請了解成本和收益。但更重要的是，要知道何時必須支付費用以及何時會看到收益。當成本開始增加時不要停止。如果你繼續前進，好處最終會顯現出來。
