应用程序现代化的挑战和机遇

本文要点

• 应用程序现代化（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还是需要时间的。

图片来源：Jakarta EE 2020年开发者调查

专有应用服务器对于企业业务来说意味着高成本。在企业基础设施层和开发层的应用服务器专家离开后，寻找IT人员来维护这些系统的成本越来越高。系统、应用服务器和JDK版本没有更新，给审计和治理带来了挑战。使用旧J2EE框架技术(如Struts、EJB、JAX-RPC等)构建的Java应用程序很难升级，并且积累了大量技术债务。应用程序还使用了自己开发的底层服务或自定义框架。

2. 遗留的Java

大多数企业工作负载仍然在使用Java 8、Java 7和Java 6，并且正在迁移到Java 11/14。客户需要我们的帮助，将他们的应用程序迁移到Java11和Java14，这样就可以使用新版Java提供的容器化钩子。旧版本的Java给平台升级带来了麻烦，并且从内存使用的角度来看，通常难以进行容器化。旧版本的Java还是安全漏洞的来源。

图片来源：Jakarta EE 2020年开发者调查

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项目。

图片来源：Stack Overflow Trends

在为现有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博客中广泛地讨论了这两个主题。

原文链接：

The Opportunity in App Modernization