云原生架构有以下四个特质：
①
基于微服务：
每个服务间相互独立，彼此松耦合。
这意味着它们能够单独地开发运维，根据功能选择不同的编程语言或者数据库。
②
基于容器：
将微服务各自部署到硬件或云环境上，以容器姿势运行。
③ DevOps
：
整合软件开发与
IT
运维，加速软件的开发、测试、部署和运维。
④
持续交付：
流程自动化，基于敏捷开发和
DevOps
工具改善代码质量，增加新功能，脱离了时间地点的限制，同时不影响终端用户的使用，实现持续交付。
那么云原生技术会对您的
PLM
系统产生什么影响？
云原生
PLM
又能够为您提供什么呢？
过去的
25
年里，
我参与过全球众多大规模、高难度的
PLM
实施，在现场看到所有客户无一例外地遭遇了五大挑战：
①
硬件依赖
传统的
PLM
系统仅支持特定品牌、型号、硬件和数据库版本上的部署——客户只能使用
PLM
供应商指定的硬件。
您的
PLM
软件版本决定了您可以使用的服务器或者操作系统，也决定了数据库甚至第三方软件的版本。
这种限制阻碍了客户公司的快速扩展，为提高性能或支持公司基础架构而更改第三方软硬件也变得困难起来。由于迁移
PLM
系统的复杂性，
IT
部门常常受困于旧的硬件和旧的操作系统，管理困难。
然而云原生应用不限部署环境，支持任何公共云、私有云或本地的部署。
PLM
系统中的不同服务可以部署在不同的硬件上，这为改良协作、缩短响应时间和增强分析能力提供了全新的机会。
每项服务还可以使用不同的数据库，采取最高效的技术来支持系统中的特定功能或性能需求。
②
需求响应
当今，通过对标准的
PLM
系统定制来满足企业产品生命周期管理需求已经成为常态。
应用不是“一卡通”制，我们不能拿制造飞机的系统去设计芯片。
因此，所有的
PLM
系统都需要通过
一定程度的二次开发来实现
，进一步支持业务。
业务需求日新月异，
PLM
系统也应该进行相应的迭代来促进业务发展。
定制单体的
PLM
系统成本高，耗时久。
尽管每年一两次的功能增强并不能真正推动终端用户的业务，但他们中的大多数人仍然安于现状，止步于此。
而对于使用微服务、容器、
DevOps
和持续交付的云原生应用，只要终端用户需要，它可以每周甚至每天进行部署改进。
微服务支持程序的独立开发和测试，而
DevOps
和容器又可以部署和监控系统以实现持续的改进。
③
系统升级
传统
PLM
系统的升级更新耗资巨大。
需要重构所有代码，再将数据转移到到另一个数据库，购买和安装新硬件，并且要重新测试整个系统。
除了升级复杂，在实际迁移过程中，
PLM
系统还需要脱机几天。
我已经看到太多升级比重启还要昂贵的例子。系统升级费用之高，风险之大，留给业务的价值已经很难去界定。用户别无他法，只能尽量拖延下一次迁移的时间，有公司因此长达十年不作
PLM
系统的迁移。
这种等待不仅意味着公司无缘供应商发布的新功能，还意味着他们的硬件和操作系统失去保障，风险上升。
然而在云原生应用中，每个微服务不限时间独立升级。
无需重启服务器，无需迁移数据，无需更改硬件，为客户节省出大量成本和精力，并在规避风险的同时保证工作的持续进行，让用户享受最新的功能。
④
系统性能
性能问题老生常谈，我在很多传统的
PLM
系统上都遇到过，不同行业和实施类型有各自的性能问题，它们的相同点是：
问题可能会迟到，但不会不到。
性能问题最常见的原因在于关系数据库的使用限制、硬件限制和核心设计方面，未能按预期执行第三方软件也是原因之一。
部分问题可以通过性能调整来解决，但更多时候，如果想要从根本上解决问题，只能去升级硬件或重新设计功能。
云原生技术专为庞大的数据密集型系统设计，如社交媒体和电商，因为他们的终端用户不愿意等待。因此，性能管理是云原生应用的核心。
基于云原生应用，系统资源可以独立分配到每个微服务上，且服务不间断地受监控。
如果一个微服务出现性能问题，系统将自动重新分配资源以提高性能。
此外，由于不同的服务提供的功能都大不相同，关系数据库并非万能。在基于微服务的系统中，您可以根据功能需求选择不同的数据库。例如，同一个
PLM
系统中，您可以使用图形数据库来处理复杂关系，时序数据库来管理密集数据，所以选择
NOSQL
数据库或者关系数据库都是基于服务所需的功能。
