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

本文要点

• 应用程序现代化（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