單體聽上去就很神秘。在數千個全球組織中，單體應用程序通常是獨立的，并排的，充滿神秘感而令人敬畏。單體應用程序是現代商業的組成部分，也是每個關鍵業務流程的重要貢獻者，從后臺到供應鏈，從客戶服務到商業參與等。

雖然這些單體繼續為業務做出巨大貢獻，但這些應用程序的現代化是一個令人沮喪和痛苦的話題。許多組織放棄了，而其他組織則通過重新定位或重新構建，將整個單體遷移到云上作為權宜之計——這是舊的“lift and shift”。2022年，新希望、新技術和新方法正在打破圍繞單體應用程序的神秘。

誤解#1：單體現代化是一項失敗的事業

每個云提供商、云原生平臺和系統集成商都有一個模型，該模型幾乎包含現代化詞典中的所有“R”。最初，這個行業的現代化只有五個R：重托管、重構、重新架構、重建或替換。隨著現代化的成熟和更多顧問的參與，R的數量也隨之增加，包括重新平臺化、重寫、保留和退役。這令人困惑。幾乎沒有數據、數學和自動化應用于單體的現代化過程。有書籍和最佳實踐，還有許多顧問和解決方案架構師愿意提供建議和交付。這些都是很好的開端，但通常要么專注于DIY方法，要么專注于昂貴、高風險的外包。

新一波的工具、應用人工智能和自動化正在應用，以彌合所有DIY或所有外包選項之間的差距。這些方法的基礎是基于對單體的實際架構分析，不僅是需要遷移到新版本的底層平臺組件，而且是實際的業務邏輯本身。業務邏輯是應用程序的核心，架構師可以在其中開始識別可以導致更清晰的微服務領域驅動設計的領域。至少，這些服務代表的是更獨立的迷你服務，或者只是具有更高排他性的普通服務。缺乏基本的數據驅動方法導致應用程序團隊脫離現代化，選擇遷移策略作為權宜之計，這導致我們陷入誤區2。

誤解#2：將單體遷移到云=現代化

將應用程序遷移到云是一個引人注目的目標，也是一個“登月計劃”愿景，它將IT和應用程序團隊凝聚到一個更大的目標上。但要明確的是，遷移并不等于現代化。單體遷移到云，可以獲得巨大的DevOps和數據中心縮減好處。幾乎所有組織都實現了這些短期收益，反過來又為希望加速和簡化企業工作負載向云移動的云提供商帶來了意外之財。許多技術領導者犯的錯誤是認為他們的工作已經完成了——我們現在已經現代化了!

這個誤解很快就破滅了：現在大多數組織都清楚，云中的單體存在著與內部部署相同的棘手問題——工程速度慢、缺乏可擴展性、難以維護和低可持續性。隨著成本開始上升，云效益仍然遙不可及，許多人稱這一階段為“lift-and-shift后悔”或“遷移后悔”。

要打破這一誤解，必須在更大、更具戰略性的現代化戰略的背景下看待和規劃遷移問題——只要是邁向全面現代化的基石，遷移就沒問題。單體的現代化使其能夠充分利用云原生架構的價值，從容器和微服務到Kubernetes和無服務器。再加上利用常見CI/CD、安全性和DevSecOps策略和平臺的好處，你的業務案例就會很快到位，這讓我們陷入誤解3。

誤解#3：構建準確的應用程序現代化業務用例是不可能的

對于大多數組織來說，應用程序現代化最困難的部分是為現代化項目構建準確的業務用例。我們探討了誤解#1中解決此問題所缺少的元素之一：預測時間和精力的架構師與批準預算和資源的業務領導之間缺乏數據驅動的討論基礎。由于缺乏共同的語言和衡量基礎，領導層和管理層之間的信任出現了雙向破裂。打破這種循環需要數據和測量才能開始。

從分析測量單體的復雜性和改變整體所涉及的風險開始。要理解復雜性，首先需要識別社區或依賴關系集群，這表明哪些領域是明顯的，因此可以提取微服務。然后，可以通過類依賴關系在它們之間糾纏的程度來計算復雜性，從而降低代碼的模塊化水平。風險可以通過依賴關系鏈的長度來衡量，依賴關系鏈的長度決定了應用程序某個部分的更改對應用程序下游不相關部分的影響程度。所有這些都可以匯總成一個總體技術債務分數，該分數可以顯示當前在債務與創新方面的支出，從而顯示現代化項目的ROI和TCO業務用例效益。從這一強有力的量化立場來看，業務優先級更容易達成一致，這導致我們打破了誤解#4。

誤解#4：所有的單體都是平等的

單體有各種形狀和大小，具有不同的商業價值和截然不同的復雜性。事實上，單體架構可以是各種用例的相關現代設計模型。簡單的第一步是根據今天的業務價值對單體進行堆疊排序。評估它們的業務實用性和工程負載、功能積壓和維護成本。通常，這些應該是一致的，因為團隊的規模、待辦事項功能的數量和維護成本應該與企業單體的業務價值一致。事實上，這些單體抵制“傳統”標簽，因為它們仍然是企業和支持它們的工程團隊的一等公民。一個不斷老化、業務價值不斷下降的單體，是簡單重組或最終退休的絕佳選擇。

如果應用程序仍然是可行的業務貢獻者，那么就必須全面評估其復雜性以及與現代化相關的風險(參見誤解#3)，以制定最佳計劃，從而制定更準確的業務用例。通過計算這些關鍵業務單元的復雜性、風險和由此產生的技術債務，你可以使用基于AI的自動化工具將較不復雜的部分轉移到更快的應用程序現代化項目中，以加速該過程。更復雜的單體(通常稱為“megaliths”)將需要更多的時間，應該遵循更迭代的重構方法，使用扼殺模式將控制從單體切換到新服務，一次有選擇地提取一個或兩個微服務。這些單片應用程序可以存在于任何地方，甚至在云中。

誤解#5：單體是一個內部問題

誠然，今天的大部分單體仍然存在于內部，牢固地固定在其原有的基礎設施上。但越來越多的單體已成功遷移到云，在云提供商的IaaS基礎設施中運行，使用提供商的電源、CPU和內存，但不幸的是，它們仍然作為單體運行。云中的這些單體可能會成功運行一段時間，但當出現可伸縮性問題時，唯一的解決方案是以越來越多的費用購買越來越大的鏡像——更多的CPU和更多的內存。這些可能需要更昂貴的保留實例，云工程師必須始終在紅線級別上運行這些實例——沒有彈性，沒有橫向可擴展性。

上述相同的數據驅動評估方法和優先級劃分方法與云中的這些單體完全相關，甚至可能更相關。為什么?數據驅動的評估、支持人工智能的現代化和遷移后重構是所有解決方案和軟件架構師所需的關鍵能力。云中的單體離完全實現其現代化命運如此之近。一旦單體重構過程完成，容器、Kubernetes、DevOps、無服務器和服務網格服務就可以在云上啟動。

誤解#6：單體依賴關系無法解開

承擔維護任務的架構師面臨著嚴峻的挑戰，更不用說在他們的責任下對單體進行現代化改造了。大多數時候，他們不是最初的架構師或開發人員，即使他們是，單體也會隨著時間的推移而發展，承擔越來越多的技術債務，這可能會埋葬大部分的原始意圖。這些錯綜復雜的單體有很多相似之處。

AI可以提供幫助。當一個系統可以將單體的深度依賴關系表示為一個圖形時，圖形機器學習可以檢測到形成潛在領域活動社區的集群和鏈接，這帶來了一系列好處，從了解復雜性和變化風險到實際檢測潛在的微服務和社區之間的邊界。構建支持它的圖形和模型需要動態和靜態分析的結合，但最終的結果是更加高效和有效的現代化工作。單體現代化成為可能，它們可以變得更加可預測和更快。

誤解#7：單體現代化永遠做不完

在打破了上述六個誤解之后，應該清楚的是，如果你遵循這些建議，時間和預算應該不會成為現代化的一個因素。現在，討論的應該是實現哪些現代化，從而帶來業務效益和成果。清晰的評估和數據驅動的規劃也應該塑造實現現代化的方式。復雜度較高的應用程序應該遵循迭代的、選擇性的重構策略，在這種策略中，不太復雜的業務關鍵型整體可以更快地通過流程。

在過去十年中，應用程序現代化一直是一種人力密集型最佳實踐，需要廣泛的培訓和文化、組織變革。這些實踐都是關鍵技能，但由于缺乏自動化和支持工具，由于技能差距和故障疲勞，這一過程已放緩到停滯狀態。這里有一些新的工具，它們采用這些方法，并通過人工智能和自動化將它們提升到新的水平。下一步是部署一種持續現代化方法，該方法插入CI/CD管道，并在應用程序的整個生命周期中檢測和修復技術債務。