簡介
IT 行業媒體關於成功遷移到雲的企業的報道鋪天蓋地，而且每天都有更多新的雲原生應用程式被建立。然而，大多數遷移到雲的應用程式是那些已經非常適合雲環境的應用程式。但在過去的幾十年來，企業紛紛投入了大量精力來構建更多的應用程式。2020 年的新冠病毒疫情只會增強這些現有資產對我們社會的重要性，需要以最少的投資讓這些應用程式適應新的需求。
企業希望從現代應用程式中獲益，以便：
大大縮短新的創新服務的上市時間透過與客戶實時互動，重新定義客戶體驗，並最大限度減少業務中斷最佳化 IT 資源以降低成本和複雜性，並獲得競爭優勢提高安全性並保護敏感資料要選擇合適的現代化方法並實現恰當的投資回報，您需要首先了解每個應用程式的當前狀態和您的業務需求。針對您的應用程式合適的現代化方法可能是：
將其保留在傳統架構上（不是真正的現代化，但對於某些應用程式來說是個有效的選擇）使現有應用程式現代化，並在可能的情況下進行重構（利用現有投資來生成現代應用程式）從頭開始構建新的替代應用程式（在某些情況下有效）本文將簡要介紹第一種和第三種選項，並更詳細地討論第二種選項，以及透過實現執行時、運營和應用程式架構的現代化來使現有應用程式現代化有何意義。
針對 Java 應用程式選擇合適的現代化方法您所採取的現代化方法可能因每個應用程式而異，並且應該基於以下幾個因素：
應用程式的預期壽命應用程式的業務需求（例如，創新、敏捷性）成本，無論旨在降低成本還是投資業務增長技術技能和程式碼重用儘管有許多言論指出，針對在容器中執行的應用程式使用微服務架構非常有效，但這並不意味著它是所有應用程式的最佳選擇，而且您選擇的架構會極大地影響您對執行時的選擇。最終目標是讓每個應用程式都在能為企業提供最佳投資回報的環境中執行。下圖顯示了可用的主要現代化選項：
我們來更詳細瞭解一下選擇每種現代化選項的原因。
保留在傳統架構上您可能會選擇將應用程式保留在傳統架構上，因為該應用程式不具有戰略意義，或者由於各種原因導致使用壽命有限。現在投入時間和資源來使這些應用程式現代化可能並不值得。保留在傳統架構上可以保護您的投資，同時您還可以規劃其他現代化操作，例如重新架構和重新編寫應用程式。
如果不進行遷移，無需執行任何操作，特別是已經在受支援的基礎架構上的情況。但如果該基礎架構的服務和支援終止，則需考慮升級到受支援的級別。為了保持為最新版本，修復關鍵安全漏洞，並在遇到問題時能夠獲得幫助，升級非常重要。您還將能夠獲得新功能和效能改進。
如果您的執行時是傳統的 IBM WebSphere Application Server（V8.5.5 和 9.0.5），支援將至少持續到 2030 年，無需脫離 Java 8。如果需要升級到新版本，可考慮執行執行時現代化作為替代方案。執行時現代化所帶來的成本節省可以提高投資回報，如果需要，它將來還可以實現進一步的現代化。
雲原生現代化對於戰略性應用程式，使其現代化並遷移到雲有助於降低成本，提高敏捷性。在許多情況下，最終目標是能夠在現代雲架構和執行時上快速更新、重用和擴充套件應用程式的各個元件，從而大大縮短價值實現時間。一步到位可能具有挑戰和風險，因此我們建議採用三個現代化步驟，每一步都能為業務產生價值，例如減少技術債務和運營成本，提高敏捷性：
執行時現代化（遷移到針對雲和容器進行了最佳化的現代執行時）運營現代化（遷移到基於 Kubernetes 的平臺）架構現代化（重構為單個可部署且可擴充套件的微服務）這種順序是最常見的方法，不過執行時現代化和運營現代化可以按順序進行，也可以同時進行。通常，是否選擇首先進行執行時現代化可能取決於企業是否已選擇並推出了容器平臺戰略，例如 Red Hat OpenShift。如果還沒有，那麼執行時現代化是為容器做好準備非常重要的第一步。
我們來更詳細地瞭解一下每個現代化步驟。
第 1 步. 執行時現代化：減少運營成本和技術債務操作將現有應用程式從傳統的執行時遷移到針對雲和容器進行了最佳化的現代執行時。
價值傳統應用程式伺服器非常適合您，並且具有高可用性和可靠性，那麼為什麼要進行現代化？傳統應用程式伺服器的問題不在於這些特性 — 而是在於達到使工作負載投入生產的程度所需的時間和成本，以及這些工作負載投入生產後的效率。
現代敏捷交付最佳實踐需要在由持續整合 (CI) 和持續交付 (CD) 流水線驅動、基於容器的部署中的輕量級執行時。這些方法消除了應用程式交付中的效率低下問題。它們可以：
降低運營成本（輕量級執行時消耗更少的資源，並具有更高的吞吐量）減少技術債務（增強部署最新、安全且受支援的軟體的能力）傳統應用程式伺服器執行時在設計時沒有考慮敏捷性和上雲，因此它們最終將限制您兌現雲原生承諾的能力。沒錯，您可以透過將現有應用程式和執行時放入容器中來實現運營現代化（這是邁向雲原生的有效措施），但最終，您還是需要遷移到專為敏捷交付現代應用程式而設計的現代執行時。
指南實現應用程式現代化以便在 Liberty 上執行（Open Liberty，或者根據應用程式，在 WebSphere Liberty 上執行，因為 WebSphere Liberty 提供一些更老的傳統 WebSphere 特定 API，您的應用程式可能正在使用這些）。牢記您要透過每個應用程式實現的目的。您可能想要透過採用容器/Kubernetes 實現運營現代化，並可能透過採用微服務實現架構現代化。您需要選擇一個支援這個旅程的執行時。現代化的執行時需要支援整體式應用程式、微服務以及這兩者所需的 API（Java EE、Jakarta EE、Eclipse MicroProfile 或 Spring Boot）。如果您選擇的執行時不具有這些特徵，那麼您就不是在進行現代化 — 要麼是在橫向遷移到另一個傳統執行時，要麼是在進行重寫，但重寫很有可能帶來更高的風險和更高的成本。由於 Liberty 支援 Java EE、Jakarta EE、MicroProfile 和 Spring Boot，而且能夠針對特定工作負載定製執行時，因此是理想的選擇。
客戶體驗
透過執行針對 Liberty 的執行時現代化，美國一家領先的醫療保健提供商將資源使用率優化了 75%，並將基礎架構佔用空間減少了一半。
檢視“Open Liberty 成為開發和部署微服務的理想之選的六大理由”（IBM Developer，2020 年 11 月），瞭解使用 Liberty 的好處。
當然，遷移到新的執行時並非易事，因此我們建議使用 IBM Cloud Transformation Advisor 來獲得幫助。Transformation Advisor 可以：
評估您的現有應用程式甚至部署關於需要變更的領域以及完成這些變更所需工作提供指導生成配置以幫助完成遷移第 2 步. 運營現代化：降低成本和複雜性，並提高靈活性操作透過採用基於 Kubernetes 的容器編排平臺，實現運營現代化。
價值採用 OpenShift 之類的容器編排平臺可以使您擺脫專有的部署和叢集方法，例如傳統的 WebSphere Network Deployment 單元。這樣，您將獲得諸多好處：
透過技術和技能標準化，降低運營成本和複雜性。您將獲得單一方法來在容器中部署、擴充套件和監控應用程式、資料庫、快取以及訊息傳遞。提高跨私有云和公共雲的運營可移植性。幾乎所有的雲都支援 Kubernetes，並且所有的主要雲平臺都支援 OpenShift。值得注意的是，Kubernetes 環境往往因雲而異，因此，Kubernetes 可以在單一環境（例如 IBM Cloud Kubernetes Service）中為您帶來一些好處，但如果選擇多雲管理的 Kubernetes 解決方案（例如 OpenShift），則可以在許多個雲中帶來這些好處。您可能不想部署到許多個雲，或者認為自己不需要這樣，但出於 GDPR 等監管原因，您可能不得不這麼做。
指南要遷移到容器編排平臺，您需要開始構建包含應用程式和配置的最佳實踐容器映象，並基於提供公共庫、執行時、Java 和底層作業系統的容器映象進行構建。
如果您已經執行了針對 Liberty 的執行時現代化，那麼您現在所採用的執行時非常適合遷移到容器。Transformation Advisor 工具有助於建立容器映象，並提供有關將配置從傳統 WebSphere 部署遷移到 Kubernetes 部署的建議。此外，Liberty 的每個版本都在 Docker Hub 中提供了容器映象：
UBI 上的 WebSphere Liberty 容器映象Ubuntu 上的 WebSphere Liberty 容器映象UBI 上的 Open Liberty 容器映象Ubuntu 上的 Open Liberty 容器映象用於建立這些映象的指令、指令碼和 Dockerfile 都是開源的，您可以使用它們來構建自己的容器映象：
構建 WebSphere Liberty 容器映象構建 Open Liberty 容器映象最後，Open Liberty Operator 有助於在 Kubernetes 環境中實現 Liberty 部署和管理。此運算子在基於 Kubernetes 的平臺中（該平臺支援 Operator Framework，包括 OpenShift）與 WebSphere Liberty 和 Open Liberty 協同工作。
如果您選擇先進行運營現代化再進行執行時現代化，而且您的應用程式目前在諸如傳統 WebSphere 之類的傳統應用程式伺服器上執行，則可以將應用程式和伺服器部署在單個容器中，並使用 OpenShift 對其進行擴充套件。 注意，Kubernetes/OpenShift 中並不提供在 WebSphere ND 中可用的全部叢集功能（例如，遠端 EJB 叢集），因此需要小心以確保應用程式正確執行和擴充套件。
為了幫助使用傳統 WebSphere Applications Server 實現運營現代化，IBM 針對當前支援的版本維護 Docker 映象。
將傳統應用程式伺服器遷移到容器只能作為邁向雲原生的墊腳石。傳統伺服器執行時在設計時從未考慮過容器、現代 DevOps 實踐或雲原生最佳實踐，例如十二要素應用程式。從長遠來看，遷移到專為容器和微服務設計的執行時將獲得更好的體驗，而 Liberty 是理想的選擇。
第 3 步. 架構現代化：實現最佳擴充套件和雲原生敏捷性操作將整體式應用程式重構為更細粒度的雲原生微服務。
價值您已經透過遷移到基於 Kubernetes 的平臺實現了運營現代化，並將整體式應用程式遷移到了專為容器和雲進行了最佳化的執行時上執行。下一步是開始採用微服務。這樣，您將能夠真正釋放雲原生微服務的全部優勢：
透過持續整合和持續交付流水線，敏捷交付各個服務更新。交付更新不再受交付整個整體式應用程式的約束。能夠獨立擴充套件單個服務，以最佳化雲使用和雲成本的方式響應各種工作負載需求。指南架構現代化有很多個方面，但第一步是要確定整體式應用程式中需要重構為微服務的功能。一種由 AI 支援的新工具稱為 IBM Mono2Micro（beta 版可用 ），它可以分析整體式應用程式，並建議將“分割槽”作為要分為微服務的候選物件。您不必採用大爆炸方法來分解整個整體式應用程式。事實上，諸如“扼殺模式”之類的策略已成功應用為增量方法。
在將整體式應用程式分解為微服務時，您不僅需要考慮如何分離業務邏輯，還要考慮如何分離任何關聯資料。將您的應用程式重構為更小的可部署單元會有一些好處，可以用作為向獨立微服務邁進的一步，但如果仍使用單片式資料儲存來支援所有服務，那麼您的服務仍然是耦合的。隨著時間推移，可以成功採用資料現代化“扼殺”式資料解耦策略。這些策略包括為新服務設定單獨的資料儲存、批次資料複製、雙重寫入以及代理來自整體式應用程式的資料請求，以使新商店上線，並與整體式應用程式一起執行新服務。
遷移到鬆散耦合的邏輯和資料的內在需求是瞭解對事務的影響。CAP 定理規定，只能同時保證一致性、可用性和分割槽容錯性中的兩個特質。 在傳統應用程式中，使用分散式兩階段事務管理器來確保始終一致。如果將應用程式分解為數十個或數百個微服務，而且每個微服務都由自己的資料儲存進行支援，這使分散式事務變得不切實際。這就產生了有利於可用性和接受最終一致性的方法。有兩種方法可以實現上述目標：Sagas（例如 MicroProfile Long Running Actions）和命令查詢職責分離 (CQRS)。從設計上看，在任何時間點，系統狀態都可能是不一致的 — 檢視資料可能無法立即反映最新更新，並且允許單獨完成微服務之間的“協調”活動。
構建新的雲原生應用程式對於特別具有挑戰性的應用程式，而且現代化成本高於收益，則可以考慮從頭開始構建新的雲原生應用程式。這樣，您就有可能實現前面現代化章節中概述的好處，例如降低基礎設施成本和提高敏捷性。
選擇執行時以跨技能、技術和成本進行最佳化非常重要。如果要使現有應用程式現代化以及重寫或編寫新的應用程式，就有必要最佳化所使用的執行時和 API 數量。您選擇的執行時應該有利於使用支援新的雲原生 API（例如 MicroProfile）、現有 API（例如 Java EE）以及您可能使用的架構樣式（例如整體式或微服務）的執行時。 還應考慮基礎架構以及與使用該執行時相關的許可成本。不要假設所有新應用程式都應實現為微服務，因為這樣做的收益和成本可能與您對應用程式的目標不符。
考慮不同架構樣式的利弊，有助於您選擇合適的執行時，同時思考您為何可能需要使用 Liberty。
如果您尚未採用 DevOps、持續整合或持續交付，則需要將其納入現代化策略中。在現代化旅程中儘早採用 DevOps 具有很多好處，但如果您遷移到微服務，則絕對必須採用 DevOps（例如，作為架構現代化或構建新應用程式的一部分）。僅憑勞動密集型的手動交付流程和孤立的組織，您的微服務策略無法取得成功。
許可靈活性有助於現代化無論採用哪種現代化策略，您的軟體基礎架構需求都會不斷演變。儘管一開始可能是在傳統的 WebSphere Application Server 上執行現有應用程式，但隨著不斷進步，一些工作負載將遷移到 Liberty，並可能帶有新的架構，例如在 Kubernetes 上執行的容器化微服務。
IBM 提供了靈活的許可選項來幫助完成這個旅程。WebSphere Application Server 的每個單獨版本均包含針對 Liberty 的權利。例如，您可以選擇使用針對傳統的 WebSphere 或 Liberty 的 WebSphere Application Server Network Deployment 權利。如果要在各個版本之間重新平衡，也可以使用 IBM WebSphere Application Server Family Edition 和 IBM Cloud Pak for Applications 之類的產品。您可以首先執行 WebSphere Application Server Network Deployment，然後等到需要在 Kubernetes 上部署到 Liberty 時，只需縮減所擁有的已部署 WebSphere Application Server Network Deployment 伺服器的數量，並使用這些權利來部署 Liberty。
結束語本文提供了一個用於為每個應用程式選擇適當的現代化方法的框架。本文概述瞭如何將現代化旅程分為三個步驟，每個步驟都能實現價值，以及 Transformation Advisor 和 Mono2Micro 等工具如何提供幫助：
執行時現代化：遷移到針對微服務和容器進行了最佳化的現代執行時，以減少基礎架構成本和技術債務。運營現代化：遷移到基於 Kubernetes 的平臺，以降低運營成本和複雜性，並提高跨公共雲和私有云的可移植性。架構現代化：分解為單個可部署且可擴充套件的微服務，以提高交付敏捷性，並最佳化雲資源的使用。本文描述了選擇合適的執行時來支援現代化的重要性：支援整體式應用程式和微服務的執行時，兩者所需的 API 以及 Liberty 為何是理想的執行時。本文還描述了 Kubernetes 作為通用雲基礎架構的好處，以及諸如 OpenShift 之類的平臺如何真正實現跨公共雲和私有云的自由部署。