工业APP最普遍的分类一般为：产品研发类、生产管理类、信息管理类、嵌入式。在此基础上，笔者考虑增加一些现代制造业的新应用，新的分类按照现代制造的全生命周期维度，具体如下：

图1:工业APP的分类

这样的新分类是广义工业APP，讨论工业APP是否要考虑容器化或微服务化，需要明确我们讨论的主体针对的是这些应用。 

那么，工业APP为什么需要考虑应用的容器化或微服务化？

从IT的技术角度看，伸缩性要求越高的应用，越需要考虑容器化技术。一般规律讲，消费类制造的应用对伸缩性的要求，要大过工业产品制造的应用。

传统的单体应用软件，很难采用多种编程语言，非常不灵活。 IT系统运维的工作量也非常大。对于问题定位、隔离，以及做补丁，复杂性都非常高。许多企业包括一些央企制造企业，应用开发和系统运维是完全分开的，甚至是两个法人实体分别承担，这样的应用架构和组织架构，无法落地DevOps，给IT系统运维带来巨大挑战。

有些制造企业开设新工厂的节奏比较快，一年增加一个新工厂的企业越来越多。新工厂的IT部署周期，传统方法的应用部署往往需要6个月，甚至9个月，企业希望压缩IT的部署周期，容器化技术也能够带来方便。应用容器化之后会更加轻便；而如果再进一步，应用实现微服务化了，那么问题的隔离、测试、灰度发布、部署等就会更加方便。

创新孵化器或者创新加速器逐渐被大的制造企业引入，包括车库(Garage)文化的引入。而Garage中的一个重要组成部分就是IT系统支撑平台，为创新者提供自由伸缩、快速部署、成本经济的IT环境。这样的平台环境还应该能够提供丰富的IT服务能力。容器技术和微服务技术将更加方便快捷。 

图2:工业APP的孵化过程

一个全新的工业APP，往往很难一下子把价值点说清楚；即使貌似说清楚了，要落笔形成文档或者规范也非常有挑战。这些都必然要求敏捷开发的开发模式，快速实现MVP (Minimal Value Project)，继而不断迭代。

而在一个创新项目的萌发期，团队往往由几个兴趣相投的小伙伴组成，进行脑激荡，这个过程中，软件资产的复用性就显得相当重要。有些想法，即使被否定，也应该留下痕迹，也就是可以留下一些软件资产，复用或备将来回溯。另外，小组与小组之间的协同，也相当重要。微服务架构更好地支撑这种协同工作的要求。

图3:微服务提供大支撑

这意味着工业APP的开发，可以借助于微服务的架构，实现微小创新和迭代完善的循环。这对于复杂多变的工业环境，意义重大。

制造业要走向高端，工业产品的服务化，是一个必然趋势。不少解决方案提供商把这一领域归属在互联产品（Connected Products），也叫产品后市场。

例如，汽车制造、电梯制造、高铁制造、飞机制造等这类产品，共同特点是生产出来的交通工具都已经相对智能化了，也就是智能产品。由于传感器的泛在和物联网的普及，对智能产品的运行保障就有了更大的想象空间。这里将会产生更多的工业APP。而这些工业APP的一个显著特点是，一个应用往往需要调用上下游的数据服务或者API服务，因而，平台就必须具备开放API的能力。这样的应用，无一例外的都采用容器技术，甚至微服务技术。

大量的汽车制造、电梯制造的制造商，都在进行业务模式的转型尝试。早期的物联网成功案例中，有许多都是从电梯公司开始的，如THYSSENKRUPP与微软的合作、Kone与IBM等公司的合作，它们都在面向物业提供深入的电梯服务，也跟诸多工业互联网平台有着广泛的合作。这些，都带来对传统制造的技术开发的流程及组织的变革要求。敏捷开发在这些行业的接受度显然高很多。敏捷开发与微服务架构不能划等号，但是，微服务架构是敏捷开发方法下的大多数人的选择。现在，新一代的车联网平台就是在提升用户体验上发力。这些工业APP，也都选择容器技术，甚至微服务架构。

可以清楚地看到，工程机械、农业机械、交通、石油石化、电力电网等，这些企业的资产运行，也正在走向制造业服务化。而平台本身和平台上的工业APP，都需要容器化，甚至微服务的技术框架。

某公司对全球1000多位CXO的一份研究报告表明，企业面临的挑战前三位是：以客户为中心，生态及超生态的优化升级，企业创新。由于企业之间的组织联系，空前的紧密，这使得企业的传统价值链和生态系统，都面临着整体上的优化升级。传统市场中的价值创造是线性的，而新生态系统中的价值创造，则是基于互联和互惠。

图4:价值链的转换

互联就是要通过APP Store或者API服务的方式，使得参与方互联互通。参与方既是服务的提供者，又是服务的消费者，他们之间应该互惠互利，才能使得生态系统健康持续发展。许多汽车制造厂商已经着手思考UBI (User Based Insurance)，该应用是在一个超生态系统架构下的创新。这种应用一定需要具备面对快速变化的市场的快速迭代能力。类似的应用还有车队管理。笔者正在参与一家央企的“产业生态云”平台项目。平台要求提升企业的运行和运营能力，这样的平台上的应用也必须是微服务架构的。

而工程机械、农业机械的数字孪生，能够清晰、准确地描述设备的健康状态，从而为二手市场、分时租赁（即共享经济）等提供支撑。这些都使得微服务架构，正处于爆发的前夜。

私有云与公有云并存，但争抢空间，成为当下的讨论重点，比如，舆情信息、GIS信息、气象信息等，大多采用公有云服务，但与特定行业结合的应用，既可以跑在私有云上，也可以跑在公有云上，什么样的部署更合理，没有定论，还处于百花齐放的阶段。许多热力图也大多由公有云提供服务，比如，城市车辆热力图、人流热力图等。以车联网为例，大部分的车企构建车联网就是选择BATH为公有云部分，而车企也建私有云。这二者的分工界面还在博弈中。

有一个现象值得关注，像Google和AWS等传统大型公有云提供商，近期也在准备通过并购或者自主研发私有云平台技术了。最近，像亚马逊已经高调宣布进入私有云市场，变化非常显著。

从大的趋势讲，工业APP一定是混合云（Hybrid Cloud）架构，即一部分应用可能继续在传统的环境中生产运行，一部分应用需要云化。出于许多因素的考量，制造企业构建自己的私有云时，仍然会需要有一部分应用运行于公有云或者调用公有云的丰富的服务。只要做出了工业APP要上云的决定，在初级阶段就是运行于虚拟机之上，下一阶再往上走就是容器化平台，而更高进阶就是微服务架构了。工业APP云化正在顺应这样的潮流。