为您的业务和应用程序需求选择正确的现代化方法。
IT行业正在报道很多关于企业成功迁移到云的故事，并且每天都在创建更多新的云原生应用程序。 但是，迁移到云的大多数应用程序都是那些已经非常适合云环境的应用程序。 但在过去的几十年里，企业已经投入了大量的精力来构建更多的应用程序。 2020 年的冠状病毒大流行只会增加这些现有资产对我们社会的重要性，只需最少的投资即可使这些应用程序适应新需求。
企业希望从现代应用程序中受益，以：
大幅缩短新服务和创新服务的上市时间通过与客户实时互动重新定义客户体验并最大限度地减少业务中断优化 IT 资源以降低成本和复杂性，并获得竞争优势提高安全性并保护敏感数据要选择正确的现代化方法和正确的投资回报，您需要首先了解每个应用程序的当前状态和业务需求。 适合您应用程序的正确现代化方法可能是：
将其保留在遗留架构上（不是真正的现代，但对于某些应用程序来说，这是一个有效的选择） 对现有应用程序进行现代化改造，并在可能的情况下进行重构（利用现有投资来构建新式应用程序） 从头开始构建新的替换应用程序（在某些情况下有效） 本文将简要介绍第一个和第三个选项，并更详细地讨论第二个选项， 以及运行时的实现，对运营和应用程序架构进行现代化改造以对现有应用程序进行现代化意味着什么。
您采用的现代化方法可能因每个应用程序而异，应基于以下几个因素：
应用程序的预期寿命业务需求（例如，创新、敏捷性） 应用程序的成本，无论是旨在降低成本还是投资于业务增长、技术技能和重用虽然有很多讨论指出，对在容器中运行的应用程序使用微服务架构非常有效，但这并不意味着它是所有应用程序的最佳选择， 您选择的体系结构会极大地影响您对运行时的选择。最终目标是让每个应用程序在为业务提供最佳投资回报的环境中运行。 下图显示了可用的主要现代化选项：
让我们仔细看看为什么选择每个现代化选项。
你可以选择将应用程序保留在旧体系结构上，因为它不具有战略意义，或者由于各种原因而具有有限的生命周期。 现在可能不值得投入时间和资源来对这些应用程序进行现代化改造。 保留传统体系结构可以保护您的投资，同时您可以规划其他现代化操作，例如重新架构和重写应用程序。
如果不迁移，则无需执行任何操作，尤其是在已在受支持的基础结构上时。 但是，如果对该基础结构的服务和支持终止服务，请考虑升级到受支持的级别。 升级对于保持最新状态、修复关键安全漏洞以及在遇到问题时能够获得帮助非常重要。 您还可以获得新功能和性能改进。
如果您的运行时是传统的 IBM WebSphere Application Server （v85.5 和 90.5），支持将至少持续到 2030 年，而不会脱离 J**A 8。如果需要升级到新版本，请考虑执行运行时现代化作为替代方法。 运行时现代化带来的成本节约可以提高投资回报，并在需要时实现未来的进一步现代化。 对于战略性应用程序，现代化和迁移到云有助于降低成本并提高敏捷性。 在许多情况下，最终目标是能够在现代云架构和运行时上快速更新、重用和扩展应用程序的各个组件，从而大大缩短实现价值的时间。 一步到位可能具有挑战性和风险，因此我们建议采取三个现代化步骤，每个步骤都能为企业带来价值，例如减少技术债务和运营成本以及提高敏捷性
运行时现代化（迁移到针对云和容器优化的新式运行时）、运营现代化（迁移到基于 Kubernetes 的平台）和体系结构现代化（重构为单个、可部署且可缩放的微服务）是最常见的方法，但运行时现代化和运营现代化可以按顺序或同时进行。 一般来说，选择首先实现运行时现代化可能取决于企业是否选择并推出了容器平台策略，例如 Red Hat OpenShift。 如果还没有，运行时现代化是准备容器的非常重要的第一步。
让我们仔细看看每个现代化步骤。
操作将现有应用程序从传统运行时迁移到针对云和容器优化的现代运行时。
价值 传统应用服务器非常适合您，具有高可用性和可靠性，那么为什么要进行现代化改造呢？ 传统应用服务器的问题不在于这些特性，而在于将工作负载投入生产所需的时间和成本，以及这些工作负载投入生产后的效率。
现代敏捷交付最佳实践要求在基于容器的部署中采用轻量级运行时，该部署由持续集成 （CI） 和持续交付 （CD） 管道驱动。 这些方法消除了应用程序交付中的低效率。 他们可以：
降低运营成本（轻量级运行时消耗更少的资源并具有更高的吞吐量） 减少技术债务（增强部署最新、安全且受支持的软件的能力） 传统的应用服务器运行时在设计时没有考虑到敏捷性和云，因此它们最终会限制您兑现云原生承诺的能力。 是的，您可以通过将现有应用程序和运行时放在容器中来实现运营现代化，这是迁移到云原生的有效方法，但最终，您需要迁移到专为敏捷交付现代应用程序而设计的现代运行时。
指导：对应用程序进行现代化改造，使其在 Liberty 上运行（Open Liberty，或者取决于您的应用程序 WebSphere Liberty，因为 WebSphere Liberty 提供了一些您的应用程序可能正在使用的旧版、特定于 WebSphere 的 API）。 请记住您希望通过每个应用程序实现的目标。 你可能希望通过采用容器 kubernetes 来实现运营现代化，并可能希望通过采用微服务来实现架构现代化。 您需要选择支持此历程的运行时。 现代运行时需要支持整体式应用程序、微服务和两者所需的 API（J**a EE、Jakarta EE、Eclipse MicroProfile 或 Spring Boot）。 如果选择不具备这些特征的运行时，则不会进行现代化改造，要么水平移动到另一个旧版运行时，要么重写风险更大，成本更高。 Liberty 是理想的选择，因为它支持 J**A EE、JAKARTA EE、MicroProfile 和 Spring Boot，并且能够根据特定工作负载定制运行时。 客户体验
通过对 Liberty 的运行时进行现代化改造，一家领先的美国医疗保健提供商将资源利用率优化了 75%，并将其基础架构占用空间减少了一半。
请参阅 Open Liberty 是开发和部署微服务的理想选择的六大原因（IBM Developer，2020 年 11 月），了解使用 Liberty 的好处。 当然，迁移到新的运行时并非易事，因此我们建议使用 IBM Cloud Transformation Advisor 寻求帮助。 Transformation Advisor 可以评估现有应用程序甚至部署，就需要更改的区域以及完成这些更改需要执行的操作提供指导，构建配置以帮助迁移操作，并使用基于 Kubernetes 的容器编排平台实现操作现代化。
价值 采用像 OpenShift 这样的容器编排平台可以让您摆脱专有的部署和集群方法，例如传统的 WebSphere Network Deployment 单元。 这样，您将获得许多好处：
通过标准化技术和技能来降低运营成本和复杂性。 您将获得一种在容器中部署、扩展和监控应用程序、数据库、缓存和消息传递的单一方法。 提高跨私有云和公有云的运营可移植性。 几乎所有云都支持 Kubernetes，所有主要的云平台都支持 OpenShift。 需要注意的是，Kubernetes 环境往往因云而异，因此 Kubernetes 可以在单个环境中为您提供一些优势，例如 IBM Cloud Kubernetes Service，但如果您选择多云托管的 Kubernetes 解决方案（例如 OpenShift），则可以在多个云中提供这些优势。 你可能不想部署到许多云，或者你可能认为不需要，但出于 GDPR 等监管原因，你可能不得不这样做。 指南要迁移到容器编排平台，您需要开始构建包含应用程序和配置的最佳实践容器映像，并基于提供公共库、运行时、j**a 和底层操作系统的容器映像进行构建。
如果您已经对 Liberty 运行时进行了现代化改造，那么您当前使用的运行时非常适合迁移到容器。 Transformation Advisor 工具有助于创建容器映像，并提供有关将配置从传统 Websphere 部署迁移到 Kubernetes 部署的建议。 此外，每个版本的 Liberty 都可以在 Docker Hub 中使用容器映像： UBIB上的 WebSphere Liberty 上的 Liberty 容器映像 UBIPliberty 容器映像在 UBIChuntu 上打开 Liberty 容器映像用于创建这些映像的指令、脚本和 Dockerfile 是开源的，您可以使用它们来构建自己的容器映像：
构建 Websphere Liberty 容器映像构建 Open Liberty 容器映像最后，Open Liberty Operator 促进了 Kubernetes 环境中的 Liberty 部署和管理。 此 Operator 在支持 Operator Framework 的基于 Kubernetes 的平台（包括 OpenShift）中与 WebSphere Liberty 和 Open Liberty 配合使用。 如果您选择先实现运营现代化，然后再实现运行时现代化，并且您的应用程序当前运行在传统应用程序服务器（如传统 WebSphere）上，那么您可以将应用程序和服务器部署在单个容器中，并使用 OpenShift 进行扩展。 请注意，并非所有 WebSphere ND 中可用的集群功能（例如，远程 EJB 集群）在 Kubernetes Openshift 中都不可用，因此需要注意确保应用程序正确运行和扩展。
为了帮助实现旧版 WebSphere Applications Server 的运营现代化，IBM 维护了当前支持的版本的 Docker 映像。 将传统应用服务器迁移到容器只能作为云原生的垫脚石。 传统的服务器运行时在设计时从未考虑过容器、现代 DevOps 实践或云原生最佳实践，例如 12 因素应用程序。 从长远来看，迁移到专为容器和微服务设计的运行时将为您提供更好的体验，而 Liberty 是理想的选择。 操作将单体应用程序重构为更细粒度的云原生微服务。
价值：通过迁移到基于 Kubernetes 的平台，您已经实现了运营现代化，并迁移了整体式应用程序，以便在针对容器和云优化的运行时上运行。 下一步是开始采用微服务。 这样，您将能够真正释放云原生微服务的全部优势：
通过持续集成和持续交付管道敏捷交付单个服务更新。 交付更新不再受整个整体式应用程序交付的限制。 能够独立扩展单个服务，以优化云使用和云成本的方式响应各种工作负载需求。 对引导式体系结构进行现代化改造有很多方面，但第一步是确定整体式应用程序中需要重构为微服务的功能。 一个名为 IBM Mono2Micro（测试版）的新型 AI 工具分析单体应用程序，并建议将“分区”作为划分为微服务的候选者。 您不必采取很大的方法来分解整个整体应用程序。 事实上，“扼杀模式”等策略已经成功地作为渐进式方法应用。 在将单体应用程序分解为微服务时，您不仅需要考虑如何分离业务逻辑，还需要考虑如何分离任何关联的数据。 将应用程序重构为更小的可部署单元有一些好处，这些单元可以用作迈向独立微服务的步骤，但是如果仍使用整体式数据存储来支持所有服务，则服务仍是耦合的。 随着时间的流逝，可以成功采用数据现代化“令人窒息”的数据解耦策略。 这些策略包括为新服务设置单独的数据存储、批量数据复制、双重写入和来自整体式应用程序的数据请求，以使新存储联机，并在整体式应用程序旁边运行新服务。 迁移到松散耦合的逻辑和对数据的内在需求是了解对事务的影响。 CAP 定理指出，只有一致性、可用性和分区容错这两个质量可以同时得到保证。 在传统应用程序中，使用分布式两阶段事务管理器来确保始终的一致性。 将应用程序分解为数十个或数百个微服务，每个微服务都由自己的数据存储支持，这使得分布式事务变得不切实际。 这导致了一种有利于可用性并接受最终一致性的方法。 有两种方法可以实现此目的：saga（例如，微配置文件长时间运行的操作）和命令查询职责分离 （CQRS）。 根据设计，系统状态在任何时间点都可能不一致 - 视图数据可能不会立即反映最新更新，并允许在微服务之间进行单独的“协调”活动。 对于特别具有挑战性的应用程序，以及现代化成本大于收益的应用程序，请考虑从头开始构建新的云原生应用程序。 这使你能够实现前面的现代化部分中概述的好处，例如降低基础结构成本和提高敏捷性。
选择运行时以在技能、技术和成本方面进行优化非常重要。 如果要对现有应用程序进行现代化改造并重写或编写新应用程序，则必须优化使用的运行时和 API 数量。 您选择的运行时应有利于使用支持新的云原生 API（例如 MicroProfile）、现有 API（例如 JAEE）以及您可能使用的架构样式（例如单体或微服务）的运行时。 您还应该考虑与使用该运行时相关的基础结构和许可成本。 不要假设所有新应用程序都应作为微服务实现，因为这样做的好处和成本可能与应用程序的目标不一致。
考虑不同体系结构样式的优缺点可以帮助您选择正确的运行时，以及您可能想要使用 Liberty 的原因。 如果您已经在采用 DevOps、持续集成和持续交付，则需要考虑现代化对每个阶段的影响。 本文中讨论的每种现代化类型都会影响 DevOps 工作：在具有新操作功能的新运行时上生成、测试和部署。
如果尚未采用 DevOps、持续集成或持续交付，则需要将它们纳入现代化战略。 在现代化之旅的早期采用 DevOps 有很多好处，但如果要迁移到微服务，则绝对必须采用 DevOps（例如，作为体系结构现代化或构建新应用程序的一部分）。 由于劳动密集型的手动交付流程和孤立的组织，您的微服务策略将无法成功。 无论您采用何种现代化策略，您的软件基础架构需求都在不断发展。 虽然它可能开始在传统的 WebSphere Application Server 上运行现有应用程序，但随着进展的进展，一些工作负载将迁移到 Liberty，并可能附带新的架构，例如在 Kubernetes 上运行的容器化微服务。
IBM 提供了灵活的许可选项来帮助完成这一旅程。 WebSphere Application Server 的每个单独版本都包含 Liberty 的权利。 例如，您可以选择将 WebSphere Application Server Network Deployment 权利用于旧版 WebSphere 或 Liberty。 如果要在版本之间重新平衡，还可以使用 IBM WebSphere Application Server Family Edition 和 IBM Cloud Pak for Applications 等产品。 您可以从运行 WebSphere Application Server Network Deployment 开始，然后在需要部署到 Liberty on Kubernetes 时，只需减少已部署的 WebSphere Application Server Network Deployment 服务器的数量，并使用这些权利来部署 Liberty。 本文提供了一个框架，用于为每个应用程序选择适当的现代化方法。 本文概述了如何将您的现代化之旅分解为三个步骤，每个步骤都能带来价值，以及 Transformation Advisor 和 Mono2Micro 等工具如何提供帮助
运行时现代化：迁移到针对微服务和容器优化的新式运行时，以降低基础架构成本和技术债务。 运营现代化：迁移到基于 Kubernetes 的平台，以降低运营成本和复杂性，并提高跨公有云和私有云的可移植性。 实现架构现代化：分解为单一、可部署且可扩展的微服务，以提高交付敏捷性并优化云资源的使用。 本文介绍了选择正确的运行时来支持现代化的重要性：支持整体式应用程序和微服务的运行时、两者所需的 API，以及为什么 Liberty 是理想的运行时。 本文还介绍了 Kubernetes 作为通用云基础设施的优势，以及 OpenShift 等平台如何真正实现跨公有云和私有云的自由部署。
我们希望这些信息有助于规划和执行您的现代化之旅。