揭開單體應用程式的神祕面紗

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

雖然這些單體繼續為業務做出巨大貢獻，但這些應用程式的現代化是一個令人沮喪和痛苦的話題。許多組織放棄了，而其他組織則通過重新定位或重新構建，將整個單體遷移到雲上作為權宜之計——這是舊的“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管道，並在應用程式的整個生命週期中檢測和修復技術債務。