本文要點
- 應用程序現代化（modernization，m11n）是一個活躍的領域，需要新的工具和技術來促進技術債務重構。
- 基本的處理組合，比如以開發者爲中心的遷移模式文檔和示例應用程序，大幅緩解了向雲端遷移的痛苦。
- 創新者正在採用自動化或半自動化的應用程序現代化，而隨着工具的成熟，將會跨越技術採用曲線的早期採用者和早期大衆階段。
- 遺留應用程序是多樣化的，應用程序現代化的機會可以被分爲六個領域。對於企業來說，應該選擇具有最大影響力和機會的領域。
現狀
應用現代化現在是一個類似DevOps、SRE或雲原生的流行詞。這個詞對不同的人來說具有不同的含義。如果問一個平臺工程師，他會把現代化解釋爲虛擬機從私有云向公共雲的遷移。
如果問一個開發人員，他會把現代化稱爲遺留應用程序的容器化，而軟件架構師會將現代化定義爲將應用程序重構爲12 factor或15 factor類型的微服務。
所有主要的企業供應商都急於幫助企業現代化IaaS、CaaS和PaaS工作負載。那麼該如何分解這些市場機會？
以下這幾種市場條件會觸發應用程序的重構和向雲原生遷移。
1. 遺留的中間件
很大一部分客戶應用程序是運行在私有應用程序服務器上的非雲原生應用程序，而且沒有使用微服務框架。這些應用程序可能是大型的Struts單體應用程序，後端邏輯運行在WebSphere或WebLogic上。
Jakarta EE開發者調查顯示，85%用戶使用的是3年多前的編程模型，差不多50%使用7年前的模型。遺留服務器上的單體應用程序降低了新功能的發佈速度，並顯著增加了交付時間。
一個應用程序重啓需要1到5分鐘，被綁死在舊JavaEE框架和服務器庫上，這些讓開發者感到厭倦。雖然應用程序重啓和內存佔用問題現在已經基本得到解決，但是，將現有應用程序遷移到最新的Eclipse Glassfish或OpenLiberty還是需要時間的。
專有應用服務器對於企業業務來說意味着高成本。在企業基礎設施層和開發層的應用服務器專家離開後，尋找IT人員來維護這些系統的成本越來越高。系統、應用服務器和JDK版本沒有更新，給審計和治理帶來了挑戰。使用舊J2EE框架技術(如Struts、EJB、JAX-RPC等)構建的Java應用程序很難升級，並且積累了大量技術債務。應用程序還使用了自己開發的底層服務或自定義框架。
2. 遺留的Java
大多數企業工作負載仍然在使用Java 8、Java 7和Java 6，並且正在遷移到Java 11/14。客戶需要我們的幫助，將他們的應用程序遷移到Java11和Java14，這樣就可以使用新版Java提供的容器化鉤子。舊版本的Java給平臺升級帶來了麻煩，並且從內存使用的角度來看，通常難以進行容器化。舊版本的Java還是安全漏洞的來源。
3. 遺留的Spring
Spring框架和Spring Boot是排名第一的Java微服務框架。因爲缺乏CI/CD實踐和應用程序架構治理，導致應用程序仍在使用舊版本的Spring Framework(版本5以下)和Spring Boot(版本2以下)。企業在升級Spring版本方面需要獲得幫助。Spring Boot 2.1.x將於2020年11月1日退役，而Spring 1.x早在2019年8月1日就退役了，所以這對於企業來說就是一個問題。重視安全問題的企業希望儘快升級到Spring和Spring Boot的新版本。舊版本的Spring和Spring Boot導致企業無法使用最新的框架，如spring-cloud和其他有助於加速微服務開發的下游Spring項目。
在爲現有Spring應用程序自動化升級框架和Spring Boot組件方面存在着機會。開發人員不需要閱讀繁雜的升級指南，只需要運行一個Spring Linter就可以升級框架組件。
4. 從單體到微服務，再從微服務到模塊化單體
Jetbrains和Jakarta EE最近發佈的開發者調查證實，微服務已經是雲端實現Java系統的領先架構，但仍然還有企業在使用單體應用程序。領域驅動設計和建模技術，如SWIFT、Wardley Maps、Bounded Context Canvas，爲創建微服務提供了技術和業務方面的啓發。但微服務的複雜性和向更簡單的部署架構(如模塊化單體)轉變的意願導致這種趨勢出現了反彈，具體可以參看這篇文章“遷移到微服務，再回退回來”。
開發庫和框架可以通過事件風暴或拆解單體生成用戶故事來填補空白。從事件風暴中生成用戶故事是一項藝術工作，需要大量的引導，因爲DDD已經“破碎”了。將業務能力劃分爲子業務能力很困難，實現微服務需要專家的判斷。有助於理解現有應用程序運行時元數據的可觀察性工具和框架與分析器相結合，從理論上說，這些工具和框架可以提供拆解單體所需的信息。vFunction就是解決這個問題的一個工具。
圖片來源：JetBrains開發者調查和Jakarta EE 2020年開發者調查
結合使用分析工具、CI/CD指標和SLO度量，我們可以通過分析諸如變更故障率之類的指標來指導微服務的合理化。這個過程需要推動者來推動，比如像“這需要做成微服務嗎”之類的研討會。
5. Java EE、Jarkarta EE和Eclipse MicroProfile的分化
Eclipse和Oracle無法就javax包名稱空間和商標的條款達成一致。因此，所有Java EE應用程序現在都必須遷移到Jakarta EE。應用服務器供應商正在爭先恐後地將Jakarta EE支持添加到他們的應用程序服務器中。Jakarta EE要起飛了。使用了javax命名空間的應用程序代碼可以不做修改直接運行在TomEE、OpenLiberty和其他應用程序服務器上，這些服務器使用了Eclipse轉換器，進行了字節碼重寫，將Jarkarta EE 8引用轉成Jarkarta EE 9，並打上了插件補丁，基於ASM字節碼轉換來處理邊界情況。另一種選擇是使用像tomcat-Jakarta EE-migration這樣的工具，使用Jakarta EE API重寫應用程序。
對於保守的企業，從Java EE到Jakarta EE的遷移需要進行迴歸測試，並在新的供應商應用程序服務器上部署，還要進行一大堆字節碼重寫或代碼重寫，以解決Oracle造成的混亂。企業可以在其他方面投入，而不必擔心新版本Jakarta EE的功能兼容性和迴歸問題。這爲該領域的其他工具和產品提供了機會。
圖片來源：從Java EE到Jakarta EE
Eclipse MicroProfile的發展速度比Jakarta EE快。在不到兩年的時間裏，發佈了6個主要MicroProfile版本和16個組件版本，而JavaEE/Jakarta EE卻以跨標準組織達成共識的速度發展。似乎標準領域的大多數創新首先會出現在上游的MicroProfile，然後再流到Jakarta EE。在可預見的未來，Eclipse MicroProfile將是獨立的，並構建在Jakarta EE之上。Eclipse MicroProfile聯合領導和EE4J PMC成員Kevin Sutter在“MicroProfile和Jakarta EE的下一步是什麼”這篇文章中表達了自己的看法。
在Jakarta EE允許MicroProfile項目進行快速的創新之前，MicroProfile將保持自己的路線，它有別於EE4J項目。
圖片來源：MicroProfile和Jakarta EE的下一步
Jakarta EE和Eclipse MicroProfile框架之間的API分化需要進行簡化。
6. 從虛擬機到容器(V2C)和Kubernetes(V2K)
Kubernetes是一個可以自動從虛擬機創建出容器的工具，不僅僅是系統容器，還包括應用程序級別的容器。Kubernetes可以發現、分析和重新打包已有的應用程序，從而利於雲計算的彈性、容錯、密度和升級補丁能力。Kubernetes能夠理解應用程序和特定的編程語言框架，從而容器化並構建出符合OCI標準的鏡像。Kubernetes就像是一隻神奇的獨角獸。
現在有很多用來從S2I、Cloud Native Buildpack構建鏡像的工具，還有一些Maven插件（如jib）以及Maven/Gradle的task和goal（如build-image），不過這些都需要一定程度的人工干預。基於基礎設施驅動的自下而上的現代化方式傾向於在不需要開發人員干預的情況下處理工作負載，最理想的情況是不修改代碼，並把風險降到最低。平臺工程師們希望VM2Containers（V2C）或VM2Kubernetes（V2K）產品能夠滿足基礎設施團隊的需求，在儘可能不讓開發人員干預的情況下處理最多的工作負載。谷歌的Anthos Migrate和Docker已經爲解決這個問題做出了巨大的努力。最近，亞馬遜也加入了這個行列，並帶來了大量的工具，比如AWSapp2container、docker2aws和co-pilot，幫助進行應用程序的容器化，從而將它們部署到ECS和EKS上。
挖掘價值
供應商如何利用這些優勢，創建出一套產品來滿足應用程序現代化開發人員目前未被滿足的需求和所面臨的挑戰？哪些產品能夠讓開發人員更快地將應用程序遷移到雲原生架構和微服務架構，並減輕上述的那些痛苦？
1. 實踐指南
應用程序現代化實踐指南“App Modernization Recipes”和“AWS架構完善”聚集了過去多年遷移應用程序的經驗，可以作爲開發人員的參考。模式文檔可以幫助雲架構師在遷移時使用結構良好的方法進行應用程序現代化，並提供可靠的應用程序遷移實踐，讓開發人員不至於總是徘徊在StackOverflow網站上，並提高大型系統集成商遷移的效率。由專業作者和應用程序現代化團隊的領域專家共同編寫的應用程序遷移指南將提升遷移的質量和數量，讓普通開發人員可以輕鬆地將應用程序遷移到雲端，而無需進行大量諮詢。一些對遺留組件框架的遷移進行分類的高質量實踐指南也可以作爲遷移工具的一部分。
2. 超級（重寫）linter
打包成linter或命令行可執行文件的命令行工具，包含了重寫引擎和DSL，用於進行代碼轉換。重寫工具就是一個超級linter，自動將遺留應用程序重新平臺化，並減少技術債務。linter使用JavaParser庫來解析Java源文件，並直接修改源文件，包括Java、XML和YAML代碼。修改是直接對抽象語法樹進行的，因此從語法上看，結果始終是正確的，並進行了序列化處理，目的是將遷移工作自動化，並讓應用程序處於可編譯狀態。open rewrite就是一個開始實現這個概念的工具。
3. 對抗性互操作性
超大規模的雲提供商利用這種技術來提供特定於某些領域或產品的API(比如Cassandra或mongo)，但底層實現由原生產品提供。例如，Azure Cosmos DB爲MongoDB提供了一個API，兼容MongoDB有線協議。新框架可以通過這種方式向現有框架發起挑戰。例如，Quarkus通過spring-di擴展的方式爲Spring依賴注入提供了一個兼容層。Quarkus Spring API兼容Spring DI、Spring Web和Spring Data JPA。更多的Spring API正在計劃當中，比如Spring Security和Spring Config。更多內容可以參閱Quarkus Spring開發者文檔。
總結
一份來自Stripe的問卷調查顯示，開發人員平均每週花費13.5小時來償還技術債務。維護在生產環境中運行的應用程序以及將它們遷移到雲端，這兩大壓力壓在了開發團隊和平臺團隊身上。應用程序現代化需要通過文檔、產品和框架來擴展和提高效率。現在是時候了，供應商們應該加快步伐，企業也應該在遷移和轉換服務上加大投入，以便加速將部分或全部應用程序工作負載遷移到雲端。專注於將工作負載遷移到雲端的企業將通過提高開發人員生產效率、減少技術債務和利用雲計算成本效率和靈活性來解決他們所面臨的競爭威脅。
作者簡介
Rohit Kelapure是將應用程序遷移到雲端和任務關鍵型系統現代化方面的專家。Rohit爲應用現代化制定了GTM、營銷和產品戰略。Rohit正在不斷改進產品和系統，以支持銷售、交付和開源社區，交付有價值的成果。Rohit活躍在雲計算、Kubernetes、單體重構和應用程序現代化戰略等博客上。Rohit最近參與的網絡研討會涉及各種各樣的主題，如中間件現代化、大型機遷移以及將單體應用程序遷移到現代雲的工具和方法。Rohit是Spring和Java EE技術方面的專家，並在他的WebSphere和All Things Cloud博客中廣泛地討論了這兩個主題。
原文鏈接：