為您的 Java 應用程式選擇正確的 Azure 服務
本文會引導您使用 Azure 服務進行 Java 應用程式部署，強調 Azure 對各種 Java 技術和架構的支援。 它概述部署方法，例如「隨即轉移」、容器化和平臺即服務（PaaS），專為各種控制和簡單層級量身打造。
本文提倡 A +B 思維，建議您根據應用程式需求，選擇固定 A 或 B 選擇來選擇服務。 它建議考慮彈性方法的使用案例、商務目標、安全性和預算。 本文強調Microsoft與 Java 生態系統領導者的合作關係，以增強開發人員體驗，並建議使用 Azure 服務來部署 Java 應用程式，無論是來源、二進位檔還是容器。 這個細微的方法可協助您專注於創新，Microsoft承諾為 Java 應用程式提供最適合部署策略的 Azure 服務、將效率、延展性和成本效益最大化。
放心部署任何 Java 應用程式
Java 生態系統包含各種技術，例如 Java SE、Jakarta EE（Java EE 和 J2EE 的後續任務）、Spring、許多應用程式伺服器和其他架構。 無論您在 Java 上做什麼 ，例如使用架構建置應用程式、使用架構和執行應用程式伺服器，Azure 支援 您的工作負載，並有豐富的選擇。 同樣地，Azure 支援 任何應用程式架構 - 從在 VM 或容器中執行的整合型應用程式，到在完全受控服務上執行的雲端原生微服務型應用程式。
Azure 提供下列三種在雲端中執行 Java 應用程式的主要方法，專為不同層級的控制與簡單性量身打造：
「隨即轉移」方法可讓您將現有的應用程式直接移轉至 Azure 虛擬機器。
容器化提供彈性，Azure Kubernetes Service （AKS） 和 Azure Red Hat OpenShift 是協調容器化應用程式的主要平臺。
平臺即服務 （PaaS） 代表簡化和效率的頂峰，提供最佳的開發人員生產力和營運管理能力，通常加上最經濟的總擁有成本。
無論您的 Java 應用程式開發階段為何，Azure 都提供相容的雲端解決方案，以符合您的需求。 您可以放心且輕鬆地在部署 Java 應用程式中深入瞭解這些供應專案。
Java 應用程式的完整可移植性：在任何地方順暢地部署
無論您為 Java 應用程式挑選哪一項 Azure 服務，都保證應用程式的彈性。 因為您擁有 Java 程式代碼及其已編譯的輸出，因此您可以自由地部署應用程式，無論是在本機開發機器、建置伺服器、內部部署環境，或您選擇的任何雲端平臺上。 您的應用程式可移植性掌握在手中。
當然，當有很多選擇時，你面臨著兩難境地。
困境 – 針對 Java 應用程式使用服務 A 或 B
如果您流覽 Azure 的供應專案，可能會遇到選取最適合用來執行 Java 應用程式的 Azure 服務兩難境地。 這個選擇非常重要，因為它會影響您的資源規劃、預算、項目時程表，以及最終您的應用程式上市時間。 此決定不僅會影響初始部署成本，也會影響正在進行的維護費用。
過去，組織通常會覺得必須選擇兩個平臺、技術，或競爭其軟體應用程式的解決方案。 例如，組織必須決定用於 Java 企業應用程式的 WebLogic 或 WebSphere、用於容器管理的 Docker Swarm 或 Kubernetes，或容器與用於部署的虛擬機（VM）。 此決策程序稱為「A 或 B 思維」，與 A/B 測試明顯不同，這是比較兩個網頁或應用程式版本的方法，以判斷哪一個效能更好。 相反地，此內容中的 A 或 B 思維是針對應用程式部署選擇一個平台或技術。 它來自傳統的內部部署做法，其中決策通常受限於封裝的軟體傳遞模型、大量預先投資基礎結構和軟體授權，以及建置和部署任何應用程式平臺所需的冗長潛在客戶時間。
將這種心態帶入 Azure 可能會導致建立單一平臺所花費的時間過長，以嘗試容納所有應用程式，並可能導致延遲和效率低下。 不過，Azure 提供更有利的方法，鼓勵從這種限制性的心態轉向採用兩個世界最佳模式的思維，最終獲得更好的投資報酬率（ROI）。
當您轉換至 Azure 時，雲端環境提供彈性的範例，可讓您根據需求布建和取消布建資源，而不需要在一個服務之間選擇。 這種彈性將迎來 A+B 方法，這是一種策略，藉由鼓勵更廣泛的、更具包容性的思維方式，從傳統的 A 或 B 思維中分裂開來。 Azure 可藉由簡化且符合成本效益來混合多個服務的優點，並採用 A+B 思維來促進此轉變。 這種方法強調選取最符合您應用程式特定需求的服務原則，基本上主張為手邊的工作選擇正確的工具。
轉型為 A+B 思維可讓組織擴大其決策流程和技術策略，並採用這種思維所承受的新可能性和機會。 本文說明 A+B 思維的原則，讓您能夠明智地選取最符合應用程式需求的 Azure 服務。 無論是 Azure Container Apps（ACA）、Azure App 服務、Azure Kubernetes Service 或 虛擬機器，A+B 思維都可讓您從裝載應用程式的 Azure 服務陣列中評估及選擇緯度。 這種哲學是普遍適用的，超越語言和架構界限。 雖然 Java 應用程式是這裡的焦點，但 A+B 思維同樣相關，而且對於任何程式設計語言開發的應用程式都相當有用。
藉由採用 A+B 思維，您不限於單一預先決定的服務。 相反地，您有權以最符合應用程式獨特需求的一種方式來結合服務。 這種方法不僅能增強彈性和延展性，還能將成本和營運效率優化。 這種方法可確保您的技術策略與您在操作的雲端環境一樣動態且可調整。
為什麼不需要考慮服務 A 或 B
選擇適合您應用程式的雲端服務不必是服務 A 或服務 B 之間的二進位決策，這要歸功於雲端供應專案的彈性和廣度，尤其是 Azure。 下列各節將細分為什麼不需要堅持傳統的「一個或另一個」選擇，以及採用更流暢的方法如何有利於您的作業。
從舊習慣到新的彈性
傳統上，部署IT系統牽涉到在硬體和軟體方面的大量前期投資，以及冗長的設定時間。 此環境使它成為邏輯，以仔細選取一個平臺，並優化其周圍的一切，以節省成本和資源。 不過，雲端環境，包括 Azure，引進了隨選和彈性特性的範例轉變。 您只需支付您所使用的費用，並調整資源以符合您的需求變得直接，而不需要初始資本支出的負擔。
移轉至雲端
移至雲端，特別是移至 Azure，對基礎結構和平台責任的管理方式帶來重大變更。 先前由貴組織肩負的繁重工作，現在會轉移到Microsoft，如下圖所示。 這項變更可簡化作業，並減少管理應用程式所需的工作。 您不受管理多個平臺的限制約束所約束，讓您能夠選擇每個作業的最佳工具，而不必擔心額外的成本和複雜度。
下圖顯示客戶與雲端提供者之間的共同責任模型：
選擇最適合每個需求
在這個以雲端為中心的新世界中，決策流程會更進一步選擇適合正確作業的工具，而不是嘗試將所有需求納入一個預先決定的服務。 無論是在 Azure Kubernetes Service 和適用於 Spring Boot 應用程式的 Azure Container Apps 或任何其他服務之間選擇，焦點都會轉向最符合每個特定應用程式的需求。
微服務的崛起
採用微服務可進一步支援這種彈性的方法。 根據設計， 微服務 鼓勵針對每個服務使用最適合的技術，促進自然與 A+B 思維一致的技術多樣性。 這種方法是使用不同服務的優點來建置更強固、更有效率且可調整的應用程序架構。
採用 A+B 的優點
採用 A+B 思維可提供數個主要優點。 它可提升靈活度和彈性，讓您為作業的每個層面選擇最適當的工具和服務。 這種方法不僅能提升資源和成本效益，還能縮短產品上市時間。 最後，這種方法會更緊密地配合您的業務需求和目標，讓您的技術選擇更加緊密地提升營運能力。
總而言之，雲端和 Azure 特別提供部署和管理應用程式的新方式。 藉由遠離嚴格的 A 或 B 選擇並採用 A+B 思維，您可以做出更符合應用程式特定需求的決策，進而提升效率、靈活度和節省成本。
轉換至 A+B 思維的實際指引
下列清單列舉了一些重要原則，您可以用來作為轉換至 A+B 思維並繼續進行的指導方針：
從使用案例到解決方案，而不是另一種方式。 通常，許多軟體小組會先決定技術，然後再嘗試強制調整使用案例和設計。 在許多情況下，這種方法在成本、開發時間、資源和作業費用方面會產生顯著的額外負荷。 在跳入解決方案之前，先清楚瞭解您的使用案例和需求，無論是功能性還是非功能性。
瞭解您的商務目標、業務的性質和競爭，以及您需要向生產環境推出新功能的頻率。 您應該一律設計解決方案，以符合您的商務目標和目標。
瞭解安全性和合規性需求。 在雲端時代，所有專案都是透過因特網存取的，安全性至關重要且不可談判。 此外，視您服務的產業而定，您的應用程式可能需要符合特定合規性需求。 您必須設計解決方案來抵禦進階安全性攻擊，並符合您的合規性需求。
瞭解您的預算和時程表。 清楚瞭解您的預算，以取得初始開發、進行中的作業，以及未來的版本。 此外，請瞭解您的時程表。 延遲專案的成本，無論是額外的費用和負面影響，往往低估。 設計您的解決方案以符合您的預算和時程表。
請思考適用的雲端原生。 雲端原生架構和技術是設計、建構及操作工作負載的方法，這些工作負載建置在雲端，可充分利用雲端運算模型。 透過雲端原生，您可以以更快的速度建置應用程式並將其部署至生產環境。 雲端也提供可能無法在內部部署的功能，例如彈性、全球規模、進階分析、AI 和機器學習 （ML） 功能。 盡可能根據雲端原生技術設計您的解決方案。
思考DevOps文化特性。 DevOps 不只是工具或程式，它是一種軟體開發實務，可促進開發與作業之間的共同作業，進而更快且更可靠的軟體傳遞。 DevOps 通常稱為文化特性，可連接人員、流程和技術，以提供持續的價值。
選擇符合您商務和非功能需求的解決方案，也就是：
- 實作速度最快。
- 在技能、建置、部署和作業所涉及的成本方面，符合成本效益。
- 易於操作。
- 與自動化完全相容。
- 依設計支援DevOps。
這些原則可協助您將焦點放在何處-建置符合業務目標的解決方案，而不是強制將解決方案調整為預先決定的平臺。
例外狀況
和任何其他項目一樣，A+B 也有例外狀況。 下列清單並不詳盡，但會提供您一些可能遇到的例外狀況方向指引：
企業策略。 例如，有些企業會使用全企業採用容器來建置和部署應用程式，因為它們可能具有多種程序設計語言，而且想要以統一的方式建置和部署所有應用程式。
執行離行太遠。 在進行 A+B 分析之前，您可能已選擇解決方案。 如果您已經深入執行解決方案，請繼續進行，但針對下一個應用程式，請使用 A+B 思維的原則，為您的使用案例選擇正確的解決方案。
大規模的數據中心移轉。 為了加速其雲端旅程，企業通常會使用稱為「隨即轉移」的策略，使用 Azure Migrate 之類的工具將伺服器（裝載其應用程式）大量遷移至 Azure。 有些人會使用這種方法將數據中心移轉至 Azure，並以有效率且符合成本效益的方式將其關機。 在此案例中，建議您在移轉至 Azure 之後，使用 A+B 思維將應用程式現代化。
主要考量
我們提供您思考的架構，以及您可用來為應用程式選擇 Azure 中正確目的地的原則。 這不是一個適合所有人的大小。 它不是 A 或 B，而是 A + B。
下圖摘要說明為任何應用程式選擇 Azure 服務的主要考慮：
如何為您的 Java 應用程式選擇正確的 Azure 服務
為了簡化 Azure 上 Java 應用程式眾多技術選項中的選取程式，我們建立了簡單的判定樹，協助開發人員、客戶和系統整合者達到最佳 Azure 服務。
除了從技術觀點考慮非功能性需求的實用指引之外，要考慮的初始問題是您是否需要控制基礎結構。 如果您不這麼做，受控服務是最佳、最建議的路由。 應用程式的性質 -- 無論是 Spring 或 App Server 型 -- 會進一步引導決策：Spring 應用程式與 Azure Container Apps 一致，同時 Azure App 服務 適用於 Tomcat 或 JBoss EAP 應用程式。
對於需要基礎結構控制的人，選擇取決於多重雲端技術喜好設定：Azure 虛擬機器 提供簡單的轉換，而針對與 Tanzu 整合的使用者，IaaS 市集供應專案的 Tanzu 是理想的選擇。 投資 Kubernetes 的客戶可以選擇 Azure Kubernetes Service 和 Azure Red Hat OpenShift。 此決策架構旨在藉由將客戶需求與 Azure 最適合的解決方案配對，來簡化選擇。
Microsoft與許多合作夥伴共同作業，包括下列領域的合作夥伴：
- 領先的 Java 生態系統合作夥伴，例如 Oracle、Broadcom、Red Hat、IBM 和 OpenAI。
- 密鑰資料庫和工具組織，例如 MySQL、PostgreSQL、MongoDB Labs、DataStax、Redis Labs、Confluent 和 Elastic。
- 可觀察性專家，例如 New Relic、Dynatrace、AppDynamics、Grafana Labs 和 Datadog。
- 開發工具，例如 IntelliJ、Maven 和 Gradle。
我們的合併投資可打造更順暢的開發人員體驗，確保與資料庫、快取、傳訊和目錄等基本服務緊密整合，並提供完整的可觀察性工具。 透過自動化、負載平衡和自動調整，我們的目標是將基礎結構管理的負擔從您的肩膀上移開。 此支援可讓您專注於透過程式碼建立商業價值，並確信基礎系統是健全且可調整的。 基於這些原因，我們建議使用特定的 Azure 服務來裝載和執行 Java 應用程式類型。
將 Java 應用程式部署為來源或二進位檔
針對 Azure 上的 Java 應用程式，無論是直接從原始程式碼部署或作為編譯的二進位檔（JAR、WAR 或 EAR 檔案），部署都是因為 Azure 的全方位服務供應專案特別針對這些用途而設計而簡化。 Java 應用程式的固有可移植性表示 Azure 可以提供各式各樣的服務，以符合您獨特的部署策略和作業需求。 此彈性可確保無論您的 Java 應用程式細節為何，都有一個完全符合您需求的 Azure 服務。
請考慮下列三個範例，其中示範 Azure 如何迎合不同的 Java 應用程式部署案例：
Spring Applications。 對於使用 Spring 應用程式的開發人員，我們建議使用 Azure Container Apps，其與 IntelliJ、VS Code、Maven 和 Gradle 等熱門開發工具整合，以及 Azure DevOps、GitHub Actions 和 Jenkins 等自動化工具。 也支援 Application Insights、New Relic、Dynatrace、App Dynamics、Grafana、Log Analytics、Elastic 和 Splunk 等可觀察性工具。 安全性是重中之重，其整合 金鑰保存庫 處理秘密和 TLS/SSL 憑證、透過受控識別支援服務的「無密碼」驗證，以及 Azure 角色型存取控制 （RBAC），確保雲端中 Spring 應用程式的安全、簡化的部署程式。
JBoss EAP 上的 Java 應用程式。 同樣地，針對使用 JBoss EAP 的 Java 應用程式，由於 Microsoft azure 小組與 Red Hat JBoss EAP 小組之間的共同作業，因此有量身打造的體驗。 這種合作關係導致了對 Azure App 服務的增強支援，提供一組專為 JBoss EAP 應用程式設計的豐富功能。 此支援可讓您使用 Microsoft 和 Red Hat 的結合專業知識，確保 Java 應用程式在 Azure 上順暢、安全且有效率地執行。
WebLogic 上的企業 Java 應用程式。 在 Oracle WebLogic 上執行的傳統企業 Java 應用程式也有 Azure 的專用路徑。 Microsoft Azure 與 Oracle WebLogic 小組之間的共同作業為 Azure 虛擬機器 上的優化部署鋪平了道路。 此合作關係延伸至與基本 IaaS 功能整合，例如虛擬機、記憶體、網路和負載平衡器，為 Azure 上的企業 Java 應用程式提供堅實的基礎。 這項協調工作可確保應用程式受益於 WebLogic 的健全性，以及 Azure 基礎結構的延展性和彈性。
這些案例強調 Azure 致力於為 Java 應用程式提供彈性、安全且有效率的部署環境，並迎合各種架構和架構。 Azure 也為其他 Java 應用程式提供特製化服務，例如在 Tomcat 或 WebSphere 上執行的 Java 應用程式，確保有適用於每種 Java 應用程式的 Azure 服務。
開發人員和操作員可以使用這些量身打造的 Azure 服務，輕鬆自動化和保護其 Java 應用程式，以順暢且具生產力的雲端部署體驗。 不過，選擇替代部署選項可能需要您自行處理這些基本開發人員和操作員體驗的建置和維護。
下圖顯示部署為來源或二進位檔之每個 Java 應用程式類型的建議 Azure 服務：
若要深入瞭解此圖表中所參考的服務，請使用下表中的連結：
將 Java 應用程式部署為容器
在部署 Java 應用程式方面，容器化代表一種尖端方法，可增強跨企業容器建立、管理和治理的自動化。 挑戰在於安全地可靠地建置容器，這是快速傳遞高品質容器化軟體應用程式的關鍵步驟。 此程式可以從頭開始或使用現有的容器系統，整合可編譯及儲存程式代碼和二進位檔的工具，以簡化容器更新和管理。 這類整合對於適應持續整合/持續部署 （CI/CD） 管線至關重要，提供容器形式的 Java 應用程式彈性部署方法。
Azure 服務不僅能緩和容器化應用程式的傳遞，還能提供從來源或二進位檔部署的清楚路徑。 這種雙重方法可將對開發人員的影響降到最低，並減輕基礎結構或平臺操作員的負載。 鑒於 Java 固有的可移植性，Azure 的廣泛容器服務選擇可確保您找到與部署策略和需求的完美相符專案。
請考慮下列兩個範例，其中示範 Azure 如何迎合容器化 Java 應用程式部署案例：
Spring Applications。 Azure Container Apps 是容器化 Spring 應用程式的絕佳選擇。 它支援多個部署類型，包括來源、二進位檔或容器映像。 這種彈性可讓您輕鬆地在部署方法之間轉移。 您可以從容器開始，但稍後決定部署為來源或二進位檔。 這個選項是有利的，因為它規避了容器持續建置和維護的需求，這可能會很麻煩、重複且需要大量時間。
Tomcat 上的 Java 應用程式。 Azure App 服務 適用於容器化 Java 應用程式，其設計目的是在 Tomcat 上執行。 它容納各種部署類型，例如二進位檔或容器映像。 如同 Azure Container Apps，此服務提供在部署策略之間替代的彈性。 您可以從容器部署開始，並維護稍後切換至部署二進位檔的選項（WAR 和 JAR）。 這種多功能性可確保您可以針對特定案例選擇最有效率的部署方法，簡化開發和部署程式。
這些範例突顯出 Azure 承諾透過傳統方法或現代化容器化，為部署 Java 應用程式提供多功能、有效率且方便開發人員的環境。
下圖顯示部署為容器之每個 Java 應用程式類型的建議 Azure 服務：
若要深入瞭解此圖表中所參考的服務，請使用下表中的連結：
摘要
在流覽 Java 應用程式的部署時，Azure 支援細微的 A+B 方法，提供一系列專為符合每個應用程式需求量身打造的服務。 Microsoft與 Java 生態系統領導者的共同作業導致一套 Azure 服務，每個服務都建議用於部署為來源、二進位檔或容器的特定 Java 應用程式類型，簡化部署程式，並確保最佳效能。 這著重於將部署策略與最適當的 Azure 服務比對，Microsoft承諾讓您彈性地選擇適合作業的工具。 Java 應用程式的固有可移植性是一個關鍵優勢，可跨內部部署系統和不同的雲端提供者順暢地轉換，以提高作業效率與靈活性。 藉由宣導此更廣泛、更具包容性的選取程式，Microsoft不僅簡化了 Java 應用程式的雲端旅程，還能將延展性、安全性、可觀察性和成本效益最大化。 歸根結底，Microsoft的指引可讓開發人員和企業使用 Azure 的生態系統，確保每個 Java 應用程式都能在最適合其需求的雲端環境中茁壯成長。