几乎所有在过去十年内采用任何主要编程语言进行编写的自定义开发的应用都可以进行平台重构。作为源代码的所有者，开发人员可以在代码中查找和更改阻止应用在云环境中正常运行的反模式。
无论所面临的情形是要求执行很少的操作，还是要求实现全面的云原生，都应从了解以下两件事开始来了解平台重构：
|
1
|
云有不同的级别，并且要遵循 12 因素应用设计原则，如下面的成熟度模型所示。 | |
|
2
|
为每个应用或一组相似的应用选择合适的策略对于获得成功至关重要。 |
什么是平台重构？
平台重构涉及以下内容：在遵循最少 12 因素的情况下，将应用从其现有平台升级到在云中运行，同时保留现有的功能。此外，它通常还将涉及从垂直扩展技术升级为水平可扩展的数据存储即服务，轻量级开源软件服务器，以及其他云服务。虽然这种级别的工作只能获得云计算的基本优势，但对于某些应用来说，这已经非常不错，因为并非所有应用都需要具备云原生的全部优势。
“Tanzu 提高了我们的能力，使我们能够快速交付...在以前的操作方法中，我们通过 Chef 配置所有内容。我们还要构建服务器。我们曾经构建系统的方法非常棘手，将功能投入生产可能需要花费几周的时间。现在，通过结合使用这个工具集和 CI/CD 功能，Tanzu 确实加快了这一流程。我们可以在 5 分钟内推送一些内容...对我们而言，这是一个巨大的改进。”
Philip Glebow
IT 架构总监, 产品架构师 Gap Inc/GapTech
为什么平台重构很重要
| ◼ |
降低 CapEx 和 OpEx自 2004 年以来，远离许可、运维和管理成本高昂的成熟应用服务器已经成为一致的市场趋势。现在，可以在云中实现容器化的轻量级服务器已经成为标准，特别是在 Java 中，Apache Tomcat 已经在这一领域占据了多年主导地位。 |
|
| ◼ |
提高可扩展性、提供商可移植性垂直可扩展性在本质上就有局限性。云平台可以在几秒钟内动态地进行水平扩展或收缩，甚至还可以自动扩展。诸如 Cloud Foundry 的开源平台能够在一个群集中运行 250,000 个容器。为什么要局限于一个基础架构即服务 (IaaS) 提供商？现代平台上的应用可以跨防火墙内部或外部的不同 IaaS 提供商进行移植。 |
|
| ◼ |
优化硬件资源使用情况和成本容器化和虚拟化应用增加了硬件或 IaaS 上的部署密度，可确保最大限度地利用系统资源，以及在空闲时进行回收或重新分配。 |
|
| ◼ |
改善软件许可和交付模式云平台是几乎所有行业巨头、主要基金会和许多企业用户的主要研发投资领域。这些平台通过实用程序和订阅定价颠覆了传统的软件许可模式。此外，云平台还减少了在云中运行所需的局部解决方案数量。 |
|
| ◼ |
提高了开发人员的工作效率，且不会失去运维控制除了跨任何编程语言、功能强大且简单一致的开发人员工具以外，许多云平台还借助可延展性模型提供开箱即用的基础服务作为核心平台元素。如果开发人员可以自行即时调配使用平台范围访问控制和审计跟踪的环境，那么对于可以设置使用参数的运营团队来说，这是有好处的。然后，可使用应用商店集合云服务以供开发人员使用。 |
|
| ◼ |
能够使用常见管理和监控工具实现 DevOps现代云提供无代理运行状况管理，可流式传输关键应用、服务和平台指标近乎实时的集成式视图。开发人员和运营人员可以共同了解云环境中的相同系统运行状况和可用性数据。 |
|
您正在考虑平台重构吗？
下面是一些需要注意的事项。
在过去十年中，商业成品软件起初并不是专为云而设计的，并且无法由原始供应商以外的任何人进行平台重构。尽管云显然是如今开发的大多数应用的最终目标，但并不是每个应用一开始都需要云原生架构。应用越是业务关键型或规模越大，云原生架构就越有意义。相反，有许多交付价值的非业务关键型应用仅仅通过平台重构就能获益。那么如何选择合适的策略？
要采用以自动化为中心的持续交付软件，企业需要改变其构建和交付软件的方式。回答以下问题的团队可帮助提供针对云进行平台重构的理由：
| ◼ |
业务驱动因素您的自定义应用对业务的重要程度如何？应用可以承受什么级别的风险？其变更频率如何？是否具备领域专家？ |
|
| ◼ |
经济驱动因素应用值得进行多少硬件和软件投资？鉴于预期结果，多长的平台重构工作时间比较合适？在收入和成本控制方面有哪些预期的优势或影响？ |
|
| ◼ |
技术驱动因素它是合适的代码库，还是充斥着违反 12 因素的内容？它是否使用合适的框架和运行时？它的工作负载是什么类型？ |
|
| ◼ |
企业变革您的企业是否已准备好消除职能壁垒，并组建可以构建和运维其服务的自给自足的团队？您的变更管理流程是否能够接受少量或无人工介入的部署管道？ |
|
平台重构应用
|
传统企业应用
|
|---|---|
| 自动扩展。 实现大规模基础架构自动化，消除了由于人为错误造成的停机。计算机自动化无需面对此类挑战，可以在任何规模的部署中始终如一地应用同一组规则。 | 手动扩展。 手动基础架构包括人工运营人员，他们负责手动构建和管理服务器、网络及存储配置。 |
| 规模合适的容量。 如果在部署时基于应用的日常需求动态分配和重新分配资源，平台重构应用可以从中获益。 | 过多的容量。 传统 IT 会为应用设计专用的自定义基础架构解决方案，这延迟了应用的部署。由于基于最坏情况估算容量，解决方案通常容量过大，也几乎没有能力继续扩展以满足需求。 |
| 提高了安全性。 平台重构应用可以在零停机的情况下在应用、应用运行时、文件系统和嵌入式操作系统级别进行修复。回滚简单快速。 | 计划内停机。 响应 CVE 和应用修补程序需要协调和计划停机时间，通常安排在运营时间过后。做出变更后通常难以回滚。 |
| 不可变的基础架构。 通过确保每次采用相同的可靠方法构建不同的不可变环境，大大减少了由于环境差异造成的应用故障。 | 独特的环境。 由于复杂性程度较高，运营人员无法快速地大规模正确诊断问题，也无法轻松地大规模正确实施。手动构建的自动化方法可能会将人为错误硬编码到基础架构中。 |
| 容器管理。 Docker、RunC 和 Garden Linux 容器中的应用由受 Google 启发的 BOSH 和 Tanzu Elastic Runtime 完全管理，能够容纳超过 25 万个容器或实例。在应用实例、进程、虚拟机和可用区层发生的故障可以自行修复。 | 本地操作系统。 应用直接在硬件的操作系统上运行或虚拟化。服务器预计有状态并保持其配置。高可用性通常位于应用运行时级别。 |
| 自动 DNS、端口、路由、扩展。 在云中，团队可以避免任何微管理，因为云提供商会管理端口分配、路由、扩展等任务。 | 手动配置。 所有配置均手动完成：DNS、路由、扩展、端口分配等。 |
在 VMware，我们帮助企业评估和执行应用平台重构，甚至为客户在平台上运行所产生的应用。各行各业从大型企业到初创公司都信任我们的软件、服务和经验，相信我们可以带领他们踏上云之旅，无论是部署之前，部署期间，还是部署之后。
| ◼ |
与 VMware 合作确定要进行平台重构的目标应用，以符合企业所需的工作和优势之间的权衡。 |
|
| ◼ |
借鉴 Tanzu Labs，使用敏捷方法，在交付价值之前，它只需在 10 周的冲刺期内反复获取结果，而传统方法需要在发布产品前进行几个月的产品组合分析。 |
|
| ◼ |
快速找到 12 因素的最小可行数量，这必须在应用可以在云中运行之前完成。 |
|
| ◼ |
与 VMware 合作确定一体化方法中可以提取的部分，从而逐步迁移并确保价值流向企业，因为进行平台重构的应用需要获得云原生设计的全部优势。 |
|
| ◼ |
使用 Tanzu 部署和管理您的应用，这是我们的云原生平台，可以缩短价值实现时间。 |
| 美国利宝互助保险公司成功实现了平台重构，在与 VMware 互动的 10 周中，重构了 10 个具有不同复杂性的逻辑应用。该企业还通过引入自动化测试提高了应用质量。 |
| 该公司已从JBoss转换到Spring Boot / Spring Cloud Config Server，并将12个因子应用程序集装箱化。 该企业消除了应用服务器设置，通过动态配置增加了正常运行时间，并通过蓝绿色部署提高了可扩展性和24/7的可用性，所有这些仅占12个因素中的大约一半。 |
| 该公司不再使用JBoss平台8-12个简单应用程序，以便他们能够学习如何执行平台重构和后续重构，以开发适用于现代模型和共享知识的方法。 |
