去年发布了《软件定义战争》战略技术报告。这个报告考虑到阅读受众，故意用大白话来讲，讲地比较浅。鉴于本公众号砖栏其实更早就提出了相同的概念，所以由我这个砖家来抛砖引玉来给大家解读下，应该可能也许是合适的。

由于篇幅限制，这个报告本身我就不多讲了。只会把里面一些地方再深化扩展下。所以，你现在在读的这篇文章，会从更技术和哲学的角度，来分析总结这篇报告。里面肯定会有很多错误观点，请诸位谨慎阅读。

可以想象，要在国防部D0d这种硬件为主的巨无霸官僚国企，推行本文介绍的这种理念，肯定会有很多挑战——十几年前亚马逊搞EC2弹性云计算服务的创举，被媒体称之为“aws把自己的肠子guts抠出来暴露给外部用户”——国防部这种官僚机构要学亚马逊生抠亚（马逊）肠，把自己肠子活生生地抠出来，肯定比民企亚马逊要难很多。

国防部跟一般的云服务厂商不同，需要集成许多老旧的装备。更何况，国防部把自己肠子挖出来后，还要基于暴露出来的软件定义战争云服务开发作战云，相当于生抠自己的鸭肠然后烫火锅给自己吃，就更加难上加难了。

在读本文之后，可以读一下兄弟我之前机翻的一些相关的云、蜂群Playbook、JAIC、杀伤链、采办和本体的文章，就可以更深刻地理解本文和软件定义战争了。

本文主要观点概括：

软件定义战争要基于云原生的第三平台构建。

国防部曾经在第一平台时代技术引领时代，现在在第三平台时代却大大落后了。

软件是任何业务的核心，战争也不例外。软件是国防部未来最致命的武器。

国防部是工业时代的硬件为中心的组织，需要转型为数字时代的软件为中心的组织。

这个转型只需要抄互联网公司作业就可以了，但是关键是国防部硬件为中心的脑子要调整过来。

软件是闭合杀伤链的更快速、更有效、更便宜、更可扩展、更准确的方式。

现有的装备是基于第二平台思维设计的，无法融入第三平台。

AI能力要能够大规模应用到战术边缘和作战云不同位置，为未来战争赋能，就需要深刻理解第三平台的成熟玩法。

未来的装备要实现云原生化，包括装备本身、作战云等。

软件定义战争包括：软件定义战争云原生基础设施、软件定义的终端节点、软件定义战争服务编排、软件定义战争应用。

可抛弃性思维，是理解云原生应用开发和云原生的软件定义战场的关键。

云原生战场由云原生的终端节点、云原生基础设施、云原生服务编排、云原生应用组成。

未来战术边缘的终端节点的四性：无人自主、可编排、无状态、可消耗（可抛弃）。

软件定义装备、软件定义战争、软件定义战术等概念有点乱现在。水有点浑。大家要看到本质，不要被绕晕了。

AI算法的原力很强，但是要和服务网格、微服务、容器编排、软件工厂、cATO、CI/CD流水线、云原生、IoT Telemetry遥测、数字孪生、零信任安全、混沌工程等紧密配合，才能释放出其巨大的能量。

软件定义战争和云原生思维模式比较奇葩比较反直觉，需要不同部门的人思维先云原生化，脑子转个180度的弯。不转个180度或者转了360度，就晚了，就完了。

由于软件数据AI三位一体，所以JAIC要实现算法战，首先软件要先云原生化作为前提。

本体是AI赋能战术边缘和单域指控、多域指控的前提。

现在的国防部，距离军事物联网还很遥远。连最基本的物连接都还没做到。

1.软件定义战争的运行逻辑

考虑到两位作者曾先后当过联合人工智能中心JAIC的主任，这篇文章我猜啊，本质上是讲算法战要在国防部真正落地的挑战和解决方案。

比较好玩的是，这篇文章在开头还特意声明，不是要论证软件比硬件重要，而是说软件更好赋能硬件，求生欲满满。

在这篇文章的结尾的最后一段话看上去挺心酸的，说他们哥俩已经尽力了来帮助国防部能够从硬件为中心orient调整到软件为中心的方向上，还希望未来这项工作能够继续。（看这段话的意思是，他们俩想法很好，但是也遇到了很大的阻力。OODA最难的是第二个o也就是orient调整，看来国防部自己天天ooda，连自己也调整不过来了）

从这几点就可以看出，不管是之前的算法战，还是软件定义战争，最大的难度并不在于已经在民用领域非常成熟的技术应用，而更多在于硅谷vs国防部两种截然不同的亚文化如何做文化接合。（以后会给大家介绍基于后马克思主义的杀伤链接合理论。不是体系缝合，是更广义的接合！）

软件定义战争一文提出，需要借鉴软件定义数据中心这一第三平台的设计和开发理念，来设计一个大规模的AI赋能的军事物联网平台：

架构设计要扩展：像只能垂直扩展性能的计算机一样，F-22和航母都难以水平扩展，死贵，像宠物一样要很多人伺候，而且维护成本超高，加点功能还特费劲。国防部应该生产大量的便宜的、可抛弃的、易于生产和维护的容易水平扩展的终端节点武器平台，就像数据中心中的牛一样。

消除单点故障：航母，jstars，第三代主战坦克，在A2/AD区域里都是鲜嫩多汁的HVT高价值目标，都是类似大型机一样的单点故障，挂了就全完了。弹道导弹1000万美元，就10艘航母每艘百亿美元；主战坦克千万美元，反坦克导弹5万美元；联合星就那么几架，也很贵。解决方案是无人自主可消耗蜂群化，要从scale up到scale out，从宠物到牛群。

虚拟化：系统缺少API接口，接入数字化的杀伤链工作流和人工智能困难。系统无法跑多种不同的软件技术栈，导致后期一旦软件技术栈过时，硬件也就浪费了。终端节点要能够暴露双向的API。能运行多个软件技术栈，比如卫星，可以让卫星能具备更多的能力，发挥更多价值。

低成本商用硬件和无状态端点：终端节点要设计成无状态，便于频繁升级人工智能算法的更新补丁，以及在敌方发起零日攻击时直接刷操作系统最快速度修复安全漏洞。有状态的数据和配置等，都可以放在云端去同步即可。CI/CD方式部署需要持续更新的AI算法到不同AOR责任区。要像升级windows和手机操作系统补丁一样，不断给装备OTA升级。

遥测能力：送外卖的都可以知道外卖到哪里了。打仗更应该如此。所以每个终端节点都要加装传感器，并具备Telemetry遥测功能。一旦能联网，自动把遥测数据发到云上。

仿真、测试和确认：作战仿真和兵棋推演，一旦上了规模，就很难。真实装备很少接到仿真上面，因为网络和涉密信息问题。可以通过仿真对象数量多但低保真或者仿真对象数量少但高保真来解决这个问题。解决后就可以对真实装备接到LVC里面进行测试和确认，同时还可以在仿真时进行混沌工程。可以通过生成对抗网络和数字孪生来生成和测试评估不同的战役规划和应急规划，甚至可以生成对手的规划。

混沌工程：一是对作战软件系统进行混沌工程测试，二是用混沌工程对仿真环境里的作战计划进行随机扰动，加上不受控的一些变化。两者都是为了让作战系统和作战计划更为韧性，反脆弱。

边缘侧自主和自动化：未来大规模的不够自主和自动化的低成本数量多的终端节点需要非常多人力进行支持，无法大规模扩展。所以要对无人系统通过AI在不同层级进行自主和自动化，减少人力。

生产环境和开发环境集成一体化：通过容器化加速软件到实际的终端节点的部署的速度。AI软件需要经常更新，收集到的环境据越多，AI表现就越好。收集数据、重新训练、重新部署的循环速度要加快。

这篇文章，把国防部的硬件为中心的硬件装备看做外壳，而外壳内有套一个软件的核。创建一个互联网规模的高可用的软件进行作战规划、决策、指控、情报分析、后勤、火控等等，不同的新旧的硬件装备连到这个软件平面上。然后不同军种的新旧终端节点武器平台，都定义好接口后，离开各个军种的各自的独立的基础设施，接到这个软件平台上，在上面开发各种业务应用。

这个思路，就跟下面这张图不太一样了。下面这个架构好像就更实际一点，直接把各个军种的SADJ2军种联合全域指控接到更大的一个软件平面上。

2.基本概念介绍

为了更深刻地理解软件定义战争，你接下来任务很艰巨，需要搞清楚这10个概念：

第三平台

宠物vs牛

刍狗

可抛弃性

商品机商品可抛弃性

虚拟化

端到端的编排

云原生 cloud native

CICD和监控

混沌工程

（这几个概念，很少有书或者文章能够彻底讲明白。都是一带而过。不过我作为严肃的民科民哲，肯定不能这样子治学。所以按照老规矩，我会先从技术史、哲学、制度经济学等角度，让你彻底搞明白这几个相互关联的重要概念。）

一旦你把这几个概念彻底理解之后，就很容易理解软件定义战争，软件定义战术，软件定义网络、软件定义蜂群，软件定义装备等各种buzz words了。

2.1第三平台

为了理解本文的其余部分，我们需要先了解IDC（全球著名的信息技术、电信行业咨询和服务提供商）定义的计算机技术的三次代际转变。

从计算机诞生到今天，IDC认为数字技术经历了如下图所示三代平台：

以大型机（Mainframe）为代表的第一代平台

以小型机（Mini或者Minicomputer）和PC（Personal Computer，也叫微型机）为代表的第二代平台

以云计算为基础的第三代平台

在以大型机模式为代表的第一平台年代，硬件以大型机（Mainframe）为主导。商用计算机的大量应用始于20世纪60年代，其中最具代表性的是IBM的大型机系列，包括700/7000系列、System/360、System/370、System/390和System Z。

在大型机年代，有两个最有名的项目。其中一个是50年代为了防止苏联的核突袭，IBM（硬件）、MIT林肯实验室（架构设计和集成）、Burroughs （有线通信网络）、兰德SDC（软件）等联合为美国空军建设的雷达防空预警和导弹防御指控系统SAGE（半自动地面环境）。这个项目是50年代最大的计算机项目。另一个系统是1960年IBM为美国航空开发的世界上第一套在线订票系统SABRE（半自动业务研究环境）。这两个系统名字都类似，都叫半自动xx环境，并不是什么巧合。原因在于都是IBM参与的项目，都是基于IBM的大型机，并且SABRE吸取了SAGE的很多项目经验。

网景创始人Marc Andreessen在2011年写的非软件公司变成软件公司的三部曲的软件蚕食世界理论，知道的人很多。但是从我的角度看来，软件蚕食世界，早在计算机诞生初期，就由美国军方开始了。除了牛逼的SAGE系统，NC数控技术是美国空军和MIT联合在50-60年代搞出来的，为了更高效切割飞机金属结构板材，也是用了IBM的计算机做NC数控。更别提DARPA前身为了美苏核大战，无心插柳搞出了互联网的前身。冯诺依曼和维纳都为军方做项目，推动了计算机的冯诺依曼体系架构和控制论的建立。DARPA前身的两位大佬利克莱德的人机共生、范内瓦的memex，更是大大超前软件当时的发展。可惜好景不长，这个势头没有持续下去，国防部还是走的硬件为中心之路。

从第一平台来看，当时美国军方在计算机技术方面是完全领先于民用行业的。结果后来完全没想到啊没想到，到了第三平台的时候，美国各个军种由于理念滞后而不是能力不行，却全面落后于弱小的民用的基于第三平台创业的Startup公司。难怪有些人把现在的国防部称之为恐龙了。恐龙在英语里，指的是曾经牛逼过但是现在已经不适应环境过时的人或物。这里面的生物进化学和软硬件适应性方面的经验教训，值得我们深思。

第二平台年代以客服端-服务器模式为代表，硬件主要是小型机和PC服务器。大型机太大太贵了，IBM为SAGE开发的大型机AN/FSQ-32重250吨，一般中小公司买不起更用不起。到了70-90年代，小型机和PC机就发展起来了。应用主要采用客户端-服务器模式，应用领域有ERP、MES、CRM和电子邮件、刘慈欣水电站计算机监控、交通信号控制、Excel/Lotus/文字处理/Photoshop，还有其他所有行业。有个搞交通工程的，好像就是在80年代和28所合作，好像是基于DEC小型机搞了点交通信号控制算法和系统，在当时应该也算是比较先进的了。但是这个第二平台有个致命问题，就是很多系统都是C/S架构的烟囱系统和一大堆孤立的单体的APP，开发理念主要采取瀑布模型+单体应用，很难扩展和敏捷。很多指挥控制系统，都有这个毛病，不管是军用的还是警用的还是民用的。

在以软件定义数据中心为代表的第三平台年代，硬件平台主要是基于云上的基础设施即服务（Infrastructure as a Service，IaaS）。第三平台的应用，例如Gmail、脸书、Youtube，具有全新的用户体验和商业模式。应用具有持续发布功能，用户无需安装或者升级软件，应用就能不断更新。第三平台的应用还具有极大的横向扩展能力，随着用户的数量不断上升或者数据量的不断上升，无须安装和升级软件，只需要在云上申请更多的计算、存储和网络等资源。应用开发模式也从瀑布进化到了敏捷+云原生。

从第二平台过渡到第三平台的主要硬件驱动力是软件定义数据中心技术发展导致所有计算机资源（CPU、内存、网络和存储）都可以商品化和横向动态扩展（Scale Out），软件驱动力是敏捷、云原生、容器编排、软件定义一切、敏捷、微服务、DevOps、DevSecOps、基础设施即代码、配置即代码等等一大堆新玩法。这些硬件和软件的技术创新，按照美国国防创新委员会的委屈说法，基本都发生在国防部之外的民用领域，军用领域落后民用领域20年至少。几十年时间过去了，国防部还沉浸在冷战胜利的美梦之中，结果一不小心外面的世界已经发生了翻天覆地的变化。

第三代平台的代表公司是谷歌、脸书和亚马逊、微软等，他们为了自己的业务创造或者使用了云平台。更多的新生代公司，从诞生伊始就将业务部署在云平台上，其中最知名的例子是网飞Netflix。Netflix将其业务部署在云平台上，同时为了保证自己的服务不因单个节点故障而中断，还在生产环境中通过混沌工程来不停地制造机器故障，验证基于云的平台仍然可以稳定地提供服务。

相比于第二代平台，第三代平台带来的数字化变革的意义更加深远。第三代平台以云服务的方式，提供底层基础设施，极大降低了数字化行业知识和消费化软件体验的技术门槛，使得创业公司致力于改善用户体验，通过用户反馈数据快速沉淀行业知识，重新审视行业隐含规则而挑战原有行业领导者。

Havas Media的高级副总裁Tom Goodwin的一段关于创业公司颠覆传统公司模式的观点曾在网络上流传——Uber作为世界上最大的出租车公司没有一辆汽车，Facebook作为世界上最大的媒体公司自己并不创造内容，阿里巴巴作为世界上最有价值的零售公司自己没有任何库存，爱彼迎（Airbnb）是世界上最大的住宿提供商却没有任何地产。

这些公司在几十甚至十几年内积累的用户数据，比行业主导者几百年积累的数据还多，这给行业的主导者带来了巨大的竞争压力。

民用企业这种基于第三平台通过数据积累进行商业模式创新的理念，和美军现在的决策中心战之间有什么隐秘联系，这里就不展开了。总之，从美国空军前参谋长David GoldFein提出空军要学习优步基于第三平台通过决策驱动指挥控制出租车的数字化创新模式，稍许可以看出些其中的端倪。

下一个围绕智能机器构建的作战网将有史以来第一次逆转人类与机器的比例。而不再需要大量的人来操作一台机器，一个人将能够单手指挥大量的机器。这在以前从未发生过，它将需要一种从根本上更动态、更灵活、更有弹性的指控方式，可以将传感器与射手配对，将决策与行动配对，在任何一种作战场景下每天无数次地满足军事力量的需求。这种指挥和控制方式可能不太像今天美国军方的做法，而更像是优步(Uber)或Lyft等拼车服务。——Brose 《杀伤链》

对于军用领域，第三平台有三层含义。

一层是装备用到的硬件，比如F-35上用到的计算机硬件（包括机下部分的计算机硬件），从ALIS的第二平台的专用硬件痛苦升级到第三平台的例子，再到ODIN；陆军的CPCE指控系统也是如此。

第二层意思是，装备本身，也要从类似第二平台进化到第三平台。第二平台的装备，比如航母、联合星、主战坦克等，都是长生命周期、昂贵的类似大型机或小型机的作战平台，而未来战争，会基于短生命周期、更便宜的无人自主的作战平台和武器。软件定义战争一文间接地指出了这一点，但是没有明说，只是说了可编排可抛弃自主endpoint。我把这个称之为第三平台，或者作战云原生化的装备，或者说适应作战云原生环境的新一代装备。

第三层意思是，空军前参谋长Goldfein指出的，要像Uber通过第三平台为乘客提供随叫随到的出租车服务一样，军队也要通过作战云编排传感器和射手之间的服务，为战斗人员提供更好的杀伤链服务。

2.2宠物vs牛

为了更好的理解第三平台，接下来我们需要学习几个重要概念：宠物vs牛、刍狗、可抛弃性、商品。

我们先来看宠物vs牛。

宠物vs牛（pets versus cattle）的类比，是云计算、云原生以及DevOps行业里面大家都熟悉的。它是快20年前由当时的微软工程师Bill Baker提出来的。由于通俗易懂，在CERN的Tim Bell等人的传播下，传遍了整个计算机行业。

对于第二平台或者第三平台的软硬件来说，宠物就是一台或多台服务器，被视为不可缺少的或唯一的系统，绝对不能宕机。我们网上看到的对着机柜烧香磕头或者请道士或法师做法的机柜里的服务器，应该就是宠物。它们通常是手动构建、管理和定期“手动喂食”的。宠物的例子有：大型机、独立服务器、HA高可用负载均衡/防火墙、主/从结构的数据库集群等。

与之对应的，牛就是使用自动化工具构建的两个以上服务器的集群，先天为故障而设计的。其中如果有一台甚至多台服务器出现故障，也不会影响正常运行。在发生故障时，不需要人为干预。牛的例子包括Web服务器集群、分布式数据库（如Cassandra集群、HBase、Cosmos DB），Kafka集群、MQTT Broker集群、MQ集群等。

Baker讲的宠物vs牛的比喻是在云计算的背景下，他强调了牛的一次性和宠物的独特性。这比扩展性伸缩性要重要得多。关键在于你对服务器的态度。如果服务器（无论是裸金属服务器、虚拟机还是容器）可以在任何时候销毁和替换，那么它就是牛。但是，一台服务器（或作为单个单元出现的一对服务器）对于你来说是不可或缺的，那么它就是宠物。

在第一平台和第二平台的管理思维中，我们对待主机、小型机和刀片服务器就像对宠物一样，给每台服务器起个名字，例如邮件服务器Bob。如果Bob挂了，网管就要赶紧处理。不然等公司CEO发现收不到电子邮件，就要来找IT主管麻烦。

到了第三平台，由于云上服务器资源规模是在太大，靠这种宠物伺候的管理模式是不可持续的了。解决方案就是学习牧场管理牛群。每台邮件服务器有一个唯一编号，例如:www001 ~ www100。就像牧场主给牛身上烙个记号或者牛耳上夹一个RFID芯片一样，不会再给它们起一个带感情含义的有意义的名字。当某台服务器出现故障时，它就会被移除，然后用其他健康的服务器来提供邮件收发服务。

关注服务器的可抛弃性（disposability of servers）是宠物vs牛的比喻最重要的方面。不考虑可抛弃性去关注其他方面，或者将一些东西（例如有状态应用程序作为宠物），会分散可抛弃性这个最重要的点，并让概念更加混乱。

所以，第一平台和第二平台都是宠物，而第三平台则是服务器牧场（Server Farm, Server Ranch）里的牛群。尽管第二和第三个平台之间存在许多差异，但宠物vs牛这个隐喻突出了两者最大的不同：第三平台的服务器是可抛弃的商品，没有名字，低成本或无成本。对待服务器就像对待网络流量、电力、自来水、石油、天然气或任何其他真正的商品一样。

总结一下，宠物与牛，核心区别在于：前者要主人用心照料（treated with care），照顾久了就会产生感情，不会随便抛弃。而后者，主人只关心其效用（牛肉、耕地、牛奶、计算、存储、ISR、动能效应、非动能效应等），是可抛弃的工业化生产出来的量大的商品，完全木得感情。

2.3刍狗

宠物vs牛群的隐喻，底层其实就是老子的刍狗的概念。所以我们需要更进一步学习下老子的刍狗理论。

老子《道德经》里这句话大家肯定都听说过：“天地不仁，以万物为刍狗；圣人不仁，以百姓为刍狗。”

白话文翻译就是：天地无所偏爱，将万物像刍狗一样平等看待；圣人没有偏私，对百姓像刍狗一样平等看待。

大家知道刍就是草，所以牛吃草再“反刍”，就是把草从胃里再到嘴里咀嚼消化。

所以，刍狗（Straw Dogs），就是草扎的狗。《庄子·天运》里说，在献祭之前，刍狗被人恭恭敬敬地盛在竹筐里，盖着精美的绣巾，巫师要斋戒之后才能前来迎送，可等到献祭之后，刍狗便被丢弃不顾了，过路人踩坏了它，樵夫把它捡回去生火。

苏辙《老子解》说：刍狗在祭祀的时候被装饰起来，被人们恭恭敬敬地供奉着，难道是人们敬爱它吗？只是这个时候就该这么做而已；等到祭祀结束之后，刚刚还一身盛装的刍狗就被随意抛弃了，难道是人们讨厌它吗？只是这个时候就该这么做而已。

所以按照庄子和苏辙对老子的刍狗的解释，我们就可以发现宠物vs牛的比喻中，牛群中的牛就是刍狗，而宠物不是刍狗。（牛是反刍动物，牛吃草，通过4个胃把草变成细菌再变成肉和奶。所以牛本质是草做的。牛就是可以抛弃的disposal的刍狗。）

钱钟书说“不仁”有两种解释。

第一种解释，就是我们最熟悉的儒家概念，所谓“天地不仁”“圣人不仁”，是说天地和圣人全都没有爱心。第二种解释，中医都很熟悉，所谓“不仁”就是“麻木不仁”，指的是手脚麻痹了不能动，这在《黄帝内经·素问》里就有记载，武威汉简发现的医书里也有。

第二种解释在《老子》这一章，最能贯通上下文。所谓“天地不仁，以万物为刍狗；圣人不仁，以百姓为刍狗”，就是说天地是麻木的、没感觉的，任凭万物自成自长、自生自灭；圣人也和天地一样，任凭百姓自成自长、自生自灭。天地对待万物、圣人对待百姓，都一视同仁，并无偏私。天地包含万物却不做具体的分辨，人要效法天地和圣人的大道，就得抛却主观想法，齐同万物，没有偏私。

以这种万物为刍狗的反直觉的思维，来设计云原生应用和云原生数据中心，就是：

云厂商不仁：用廉价量大的商用服务器构建基础设施，而不用昂贵的scale up的服务器。就像祭祀时不拿活的狗祭祀，而是用草扎的狗。

部署人员不仁：用轻量级容器而不是操作系统或虚拟机这种不带有状态信息的可快速启动和销毁的刍狗，作为任何编程语言任何应用程序的运行时环境。

运维人员不仁：任何IT资源都是可抛弃的，所以有了问题，不会跳出来去帮助解决问题，比如去宠物医院给宠物看病，而是抛弃牛群里的生病的牛，找云农场里另一个健康的牛继续干活。

开发人员不仁：应用程序开发不再采用单体应用，单体应用需要像宠物一样运维管理，而是将其拆分为微服务应用的刍狗。

测试人员不仁：以生产环境为刍狗，故意用混沌工程破坏生产环境，找出系统中的薄弱环节。

用户不仁：我们不再关心软件牛/刍狗本身，而是关心它的效用也就是API接口，至于怎么实现的漠不关心，同时为了在软件出现问题时抛弃替换它，就必须给刍狗加上telemetry遥测功能。

老子这句话，对于未来的软件定义战争，有三层意义。这里就不展开了。

2.4可抛弃性

前面我絮絮叨叨，从第三平台开始，讲到了第三平台的服务器的宠物和牛的比喻，再到刍狗，就是为了引出可抛弃性disposability这个最重要的概念。可抛弃性，是理解的云原生和未来云原生的软件定义战争的关键。

要搞明白可抛弃性的含义，我们要了解下当今世界的更隐蔽的新奴隶制。等你理解了新奴隶制，就会明白云计算、软件定义数据中心SDDC、软件定义战争SDW、A/R可消耗/可重用无人机等，泰国雏妓性奴、印度奴工、巴西甘蔗奴隶、996社畜，本质上都是资本主义和新奴隶主义结合的产物。

传统的奴隶制度下，一个人为奴，终生为奴，子孙后代也为奴。奴隶主有义务养奴隶的小孩，以及老了的奴隶。斯托夫人《汤姆叔叔的小屋》里的汤姆叔叔、屠格涅夫《猎人笔记》笔下的俄国农奴以及沙俄时期的灰色牲口，都属于旧奴隶制度下的奴隶。

但是新奴隶制度不是这样的。购买和长期养奴隶不再划算。奴隶主通过廉价手段控制奴隶并在短期内获得奴隶创造的高利润价值后，就把他们当垃圾一样无情地抛弃掉。

新奴隶制最典型的例子是泰国的性奴隶。

泰国的人口爆炸提供了过剩的潜在奴隶，而快速的经济变革导致贫富差距拉大。一些女孩被父母卖给了掮客，或是被中介以进城打工为理由骗到城里。一旦她们远离家乡，就被卖给妓院老板，被逼签卖身契，只能通过卖身赎身。

这个行业非常暴利——只要用800—2000美元买来一个12-15岁的女孩，加上妓院运营和女孩伙食费用相当低，年利润经常高达800%。这么高的投资回报率在一个女孩身上可以持续3-6年。3-6年之后，或者在这之前生病或HIV阳性，她们就会被像垃圾一样抛弃掉。

新奴隶制度下的奴隶，变成了短期的而不是终生的可抛弃的商品，变成了向上帝证明人世间罪恶的刍狗。

所以，某种程度上，美国空军由于未来军种预算不足，采办大量可消耗可重用的用后即弃的A/R无人自主平台放在高危险的第一岛链和第二岛链作战，用后即弃，也是新奴隶主的小九九思维。

上面讲了这么多，我们终于可以进入主题了，用【可抛弃性】这一概念来理解云原生的五大支柱：

云原生12+因素设计：基础设施不可变，是为了随时抛弃掉在跑的程序，好另起炉灶；和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性，好让微服务像被逼卖身的泰国女孩一样由嘴里叼着根烟的拉皮条的安排调度随便进哪个隔离好的容器小房间接客。API接口提供可抛弃的商品的服务；同时需要telemetry遥测监控，发现故障问题就抛弃掉。

容器编排：AI算法微服务的版本要升级，或者配置文件要修改，或者某个节点故障了，都直接采取可抛弃思维，直接干掉正在干活的容器集群中的健康的或者不健康的牛/刍狗一样的容器实例，然后再起新的软件版本或配置文件的容器实例。

微服务：模块化的微服务，由于大部分都是无状态的，可以用请求响应或者事件驱动的模式，来进行编排。一旦其中一个微服务出问题，就可以立刻抛弃掉。

支撑服务：支撑服务表面上看是不可随意抛弃的，但是实际上支撑服务也是由可抛弃的组成的，确保其高的SLA服务水平。

自动化：由于系统随时都会需要扩大或缩小规模，并且随时可能会有节点需要抛弃进行版本升级或配置更新或者干掉不健康的，这些工作都必须自动化，不能像宠物一样由人来伺候。使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入项目。对牛的监控也要通过Telemetry手段进行IoT自动化的遥测。通过CI/CD持续集成持续发布，实现集成和发布的自动化。

2.5商品及商品的可抛弃性

当可抛弃性这一新奴隶制的思维模式，和工业4.0时代赋能的大规模个性化生产的商品结合后，可抛弃商品、云原生、软件定义装备等也就成为了必然。

在微观经济学中，商品是任何能够满足某一需求的产品。对商品的消费会满足人们的需求，经济学家用“效用”（utility）这一术语来表示人们从商品消费中得到的满足程度。

可抛弃的商品的例子有：

方便面、速冻食品等快消品

宝洁发明的婴儿纸尿裤

一次性纸杯、盘子、餐具、避孕套、口罩、包装甚至衣物等

泰国妓女、印度农奴、巴西甘蔗农奴之类的新奴隶

可抛弃副油箱、可抛弃火箭发动机

Martin Fowler提出的可抛弃软件设计架构

公有云上的IaaS服务、PaaS服务、SaaS服务

Serverless无服务的Lambda函数计算

持续更新的云原生应用

可抛弃的持续部署持续更新的AI算法微服务

直播平台的小姐姐们的异化了的互联网云服务化的商品化身体

A/R可抛弃、可消耗的无人机

可抛弃可优化的996打工人社畜

当然，商品的可抛弃性是基于强大的工业或社会支撑的，可以以较低成本生产大量的可抛弃的commodity商品。这个逻辑对于民品和军品都是成立的。也是云原生化的第三平台和软件定义战争这种新奴隶制成立的前提。

所以商品化的另一个含义，就是它必须要能够大量低成本生产。所以像航母、联合星、F-22这种就不属于商品，它们无法满足未来的联合全域的消耗战，生产速度实在太慢，又太贵了，舍不得随便抛弃。未来少量有人高端平台更多只能作为JADC2网络上的关键枢纽节点。

2.6虚拟化

虚拟化的本质，是将一种资源或能力以软件的形式从具体的设备中抽象出来，并作为服务提供给用户。

国防部要成为基于云服务商CPS的airbnb那样的房屋（防务）服务提供商DSP，为作战人员提供各种软件定义战争的基础服务和更上层的解决方案，就需要在最底层有一层看不进的软件定义层。也就是软件定义战争一文里说的所谓的plane os、tankos，shipos之类的比喻。它想表达的意思实际上就是像手机操作系统一样，不光要有航电操作系统face, 机器人操作系统military-ros, 无人自主skyborg，还要有更上层的装备层面的虚拟化的操作系统。

当然，这里我们要补充一点，虚拟化这些战术边缘和指控节点上的资源，具体可以分为很多专业的垂直领域，而不是简单的坦克操作系统，飞机操作系统，舰艇操作系统，卫星操作系统那么简单。还有很多需要软件定义的地方，比如数字信号处理，无线电，电磁频谱作战，战术指控，网络，广域网，集成，指控，hpm等。

软件定义无线电：无线电射频硬件能力的虚拟化

软件定义数字信号处理：基于软件定义无线电和软件定义GPU的能力，在更高层面对DSP信号处理能力的虚拟化，实现数据信号处理流水线的编排

软件定义电磁频谱作战：电磁频谱全域作战的虚拟化和最优化

软件定义pLEO卫星，及其软件定义卫星mesh网络

软件定义航电

软件定义网关

软件定义情报融合

软件定义计划

软件定义指挥所计算环境

软件定义定向能

软件定义高功率微波武器

软件定义网络，软件定义广域网

软件定义联合后勤，联合规划，

软件定义条令

软件定义无人自主蜂群战术play/playbook

软件定义JADC2 COP

......

2.7端到端的编排

目前，“编排”还没有达成最权威准确的定义，不同的组织都有各自的定义，但是都大同小异。

我们这里简单将“编排”定义为“The continuing process of selecting resources to fulfill client service demands in an optimal manner”，也就是“持续地以最优的方式选择资源来满足用户的业务需求”。

其中“持续地”一词表达的含义是，由于用户的需求和网络的环境可能是动态变化的，因此需要根据这些变化实时地调整。“最优的方式”是指编排的结果能满足用户的全部需求，且能满足编排的策略，编排的策略由资源的管理人员制定，例如，策略中可以规定编排的目标是达到最高的资源利用率。

对于软件定义战争而言，我们要将编排看做广义的编排，拓展其外延。所以软件定义战争要编排的对象有很多种：

软件定义广域网的编排

基于意图的空基/天基/陆基软件定义移动Mesh网络的SDN的NetDevOps编排

基于意图的战术边缘的终端节点内部的容器编排

OCONUS和CONUS云的容器编排

数字工程中的AI算法的ModDevOps流水线的编排

软件定义战争中的AI App和AI Bot的MLOps/DataOps流水线的编排

data mesh, data fabric的编排

决策中心战的数据流水线的编排

零信任安全策略的编排

软件工厂DevSecOps流水线的编排

端到端虚拟杀伤链的编排

......

2.8云原生

被虚拟化的资源，它原生就具备的能力，如何才能被释放出来？

我们先来看第三平台的原力如何发挥出来，再来看军用的第三平台的原力的释放。

native土生土长的，本地的。计算机行业里，native特指：

Computing designed for or built into a given system, especially denoting the language associated with a given processor, computer, or compiler, and programs written in it 【计算机】本机器码。

云原生，指的就是为了云计算这一第三平台设计和构建的，是土生土长的本地人，不会水土不服。

所以，云原生应用，指的就是专门为云计算这种第三平台的运行环境设计和构建的本地的不会水土不服的应用。而AI能力本质上也是软件，JAIC联合人工智能中心之前部署AI算法到全球各个战区的战术边缘，就遇到了水土不服环境不适应的问题。这一方面说明了AI实验室里的算法都是在Shadow IT环境开发的，另一方面说明AI要能够真正赋能软件定义战争，AI算法运行时开发测试环境、战术边缘的终端节点Endpoint、作战云三者都必须要能够实现云原生，不然必然水土不服。

由于AI算法需要不断拿不同战区的真实图像数据进行训练，并重新部署训练过的算法模型到战术边缘的终端节点和作战云；并且AI算法在战场上会遇到多种突发情况；所以需要频繁地发布部署新版本，并能够动态编排和动态伸缩，以便快速满足用户的新需求和战场环境的变化。因此就需要能够做到如下几点：

容器引擎提供不可变基础设施：对基础设施的故障出现和需求变更具有更好的弹性，无论这些故障和变更是计划内的还是计划外的。当所运行的环境经历了一些不可避免的变化时，AI软件必须能够适应这些变化。

AI算法微服务化：单体的人工智能软件做不到频繁发布新版本，太多相互依赖的模块需要耗费大量时间和复杂的协作。用更小、更松耦合、可独立部署和发布的AI微服务组件组成的软件，可以支持更敏捷的发布模型。

容器引擎提供动态编排和动态伸缩能力：AI算法在战时会遇到不确定数量的目标，会导致数据量和算力大幅波动，因此需要能够动态伸缩。同时在不同战场环境和不同目标时，需要动态调度运行不同类型的AI算法微服务。

可适应性：AI软件和它运行的环境在不断地变化。可适应性AI软件的定义是“能够适应新的条件”，这里的“条件”指的是基础设施和相关的软件模块。它们本质上是联系在一起的，随着基础设施的变化，软件也在变化，反之亦然。

云原生的软件定义战争，除了刚才2.6提到的已经被虚拟化了的终端节点作战资源，还包含如下部分。

终端节点：自主、可编排、无状态、可消耗的飞机，坦克，军舰，卫星。将各个军种的作战资源统一视为作战云原生调度的资源。这些作战资源必须是自主、可编排、无状态、适应性、可消耗和可重用的。这些作战资源就像数据中心中的牛群一样，而不是宠物一样，由作战人员运行管理。

云原生应用逻辑服务：不同作战领域以及跨作战领域的应用逻辑代码。这里的应用逻辑代码必须符合云原生应用开发的技术规范，带来的水平伸缩故障隔离敏捷升级之类的好处，这里就不展开了。大家随便找本云原生应用开发的书看看就知道了。

云原生数据服务：不同作战领域以及跨作战领域的静态数据、基于终端节点telemetry监控拿到的真实装备的可用于AI算法训练的IoT数据、云端的原始数据分析数据和决策数据等。这些数据服务分布在不同作战领域的终端节点、OCONUS战术云、CONUS企业云中。这些数据服务底层是数据库和缓存，但是只能通过接口暴露给有权限访问的不同应用逻辑。并且要按照CQRS读写分离的方式进行。

云原生交互：云原生软件是无状态的云原生应用逻辑与有状态的云原生数据的组合。服务之间的交互比服务本身更加重要。通过对单一作战领域或者多个作战领域的云原生应用逻辑服务和云原生数据服务的异步的事件驱动和同步的请求/响应两种编排方式的组合，就可以敏捷灵活地实现各种业务需求。

终端节点开发环境：开发部署各个军种的战术边缘的终端节点的云原生的模块化AI微服务软件。

应用开发环境：开发各个军种以及联合全域指控的云端的云原生应用App。在这些资源之上，统一采用云原生方式进行自动化和编排。构建可伸缩的、实时的、适应性的联合全域杀伤网。

开发与测试平台：提供AI应用开发所需的开发和测试平台，包括开发和测试AI算法用到的真实数据以及人造的合成数据，用于LVC。

2.9云原生下的CI/CD与监控

传统的IT监控，通常是网管监控系统通过SNMP协议、JMX等，对每个IT资源的众多的监测数据项进行pull拉取式的数据轮训，然后再自动触发预先配置好的告警规则，通过短信邮件电话语音等方式通知苦逼的运维人员，然后他们再进行处理修复故障。这些IT资源都是宠物，一旦出现问题，就需要修复，不然肯定影响。

而云原生时代的监控，由于监控的对象从宠物变成了牛群/刍狗/奴隶。一方面可以通过云原生实现自动配置の自我修复。如果出现故障，可以抛弃它并启动另一台服务器，自动将其重新运行到正常运行环境。所以不需要对其进行轮询监控。另一方面，由于不想像宠物一样伺候，我们部署到战术边缘的终端节点上的AI自主算法，就不想费老鼻子劲才能拿回来真实数据用于训练和评估算法，最好自动化这些事情。

与传统监控不同，云原生模式下，需要从被动拉取式监控到主动推送式监控，事件Event、指标Metrics、日志Logging将成为Telemetry监控的三大核心。

下面我们来看一个通过云原生监控拿到自主蜂群的真实数据的数字孪生，然后用于强化学习提升装备AI自主算法和蜂群Playbook的例子。

AI自主算法一旦通过DevSecOps流水线构建好后，封装成Playbook，然后就要通过自动化的手段自动部署到战术边缘的终端节点的云原生的服务网格上运行。这个自动化流程，就是从CONUS美国本土的算法工程师到OCONUS非本土的各个战区的战术边缘的真实装备上，叫做自主蜂群AI的持续发布。新的AI自主算法开发好了，要验证其效果，就要先整合到自主集群的Playbook中，然后在本地进行数字孪生仿真。然后再通过软件定义广域网把升级好的微服务容器镜像发送到CONUS非美国本土的战区的战术单位，进行实际测试验证。

这些频繁发布的AI算法微服务部署的运行环境，则是在战术边缘终端节点的不可变的基础设施之上。通过容器编排实现AI自主微服务的不同版本的管理和调度。甚至可以在运行时抛弃掉其中一个微服务的版本，切换成另一个版本来运行。

对于AI算法来说，关键在于算法的训练数据。虽然可以用一些模拟数据或者合成数据来进行训练，但是主要还是依赖于大量真实的数据集。但是要拿到大量真实的数据集，一方面很多装备都没有联网，得人工从装备里拷贝数据；另一方面，由于未来战场无人自主可消耗可抛弃的终端节点越来越多，很有可能壮士一去兮不复还。所以给装备（云上的指控软件好点）加上Telemetry监控采集装备IoT数据然后后送到后方算法工程师的能力，就非常重要。这个反向的过程就叫持续集成。（所以这个CI/CD的过程跟BP反向传播神经网络很像）

自主集群的多个Vehicle的控制微服务，作为主控微服务调度其他AI自主算法微服务，其重要指标和日志和事件信息，都会记录到Metrics and Logging微服务，然后通过通信微服务（连接到软件定义Mesh网络，可能断网，但是一旦联网，就可以后送），将其往战术边缘云发送，然后再后送到OCONUS云，直到一路后送到CONUS的企业云。在那里，算法工程师就可以通过API接口拿到真实设备上的数据，用于深度逆向强化学习来增强无人蜂群的自主能力、bug修复、评估自主算法效果等场合。当然这些模块化的自主微服务增量由于需要频繁部署到真实的装备上，所以要跟pLEO卫星上部署通信和指控微服务一样，也要用金丝雀部署方式，也就是先部署到金丝雀导弹、金丝雀卫星上。

下面，我们暂停下，思考下如何利用第三平台的能力实现AI能力大规模（large-scale）应用到软件定义战争。

scale当名词，可以用来指a device having such a series of marks 有刻度的量具。引申含义就是the relative size or extent of something 规模; 程度; 范围。

基于scale的带刻度的量具的本义，scale当动词用时，represent in proportional dimensions; reduce or increase in size according to a common scale （按比例）绘制;（按比例）缩小（或放大）。

对于scale，软件行业翻译成伸缩性，扩展性。媒介理论翻译成尺度，其实说的是同一个东西，本质是不同尺度不同的规模。

软件行业说的scale up和scale out，这里就不解释了。

未来软件定义战争的AI能力能够large-scale大规模扩展到战术边缘终端节点的能力，我想你已经得到答案了——显而易见，是通过上述的2.6~2.8这几部分软件定义战争的云原生能力赋予的。

2.10混沌工程

从前面的介绍我们可以看出，对于不熟悉云原生的国防部来说，这些搞法和之前的做法相比，都是反直觉的或者说背道而驰的：瀑布vs敏捷，宠物vs牛，高端装备vs可消耗可重用，手工安全拷贝数据vs不安全的装备联网在线IoT遥测......

这里还有一个反直觉的做法：混沌工程，也就是使用工具故意在整个系统中在随机位置引发故障，然后提升系统的恢复力。这个搞法，对于国防部来说，就更为激进了，因为很容易搞出事情来。

实际上，大家应该也能看出来，混沌工程仍然是以万物为刍狗的思维。

从SoS体系工程的角度看，大量简单系统组合在一起，就会涌现出一些期望或者不期望的结果。

对于这些不期望的结果，第三平台是通过混沌工程来发现和消除。

对于软件定义战争这个复杂体系，由于涉及到了许多AI算法，更需要采用混沌工程。一方面找出体系的不期望的涌现结果，另一方面，模拟仿真大国对抗环境下的大量终端节点受损后仍能保持弹性和韧性的情形。

基于2.8和2.9，要在软件定义战争里搞点湍流搞点小破坏，技术上也是容易实现的了。

混沌工程本质就是持续的对抗PDCA循环，是软件定义战争的磨刀石和满广志。

3.基于第三平台的软件定义战争设计模式

软件定义战争这个报告只讲了云原生这部分，本文狗尾续貂，再补充几个观点。

3.1实用主义消费思维

可抛弃的商品的实用主义思维有四层含义。一，消费者关心的不是商品本身，而是其带来的价值。二，商品对于消费者来说，是用后即弃的。三，软件和ai算法甚至架构也是可以抛弃的。四，终端节点的设计要考虑短的使用期限和抛弃性。

关于商品的效用，有一首歌作了生动的说明。

不要给我东西。

不要给我书籍，我要的是阅读的愉悦与知识的益处。

不要给我唱片，我要的是美妙动听的乐曲。

不要给我工具，我要的是用处和创造美好物品的快乐。

不要给我家具，我要的是舒适、美观和方便。

不要给我衣服，我要的是廉价的时尚。——Zara

不要给我衣服，我要的是迷人的外表。——蕾哈娜

不要给我鞋子，我要的是两脚舒服，走路轻松。——互联网卖鞋

不要给我房子，我要的是安全、温暖、干净和快乐。——airbnb

不要给我汽车，我要的是方便，安全，快捷地去任何目的地。——优步

不要给我火箭，我要的是更便宜一次送很多卫星上天。——spacex

不要给我硬件，我要的是iaas/paas/saas服务。——云计算

不要给我网络，我要的是按任务优先级在激烈竞争环境下可靠传输数据。——darpa dynamo/minc

不要给我算法，我要的是指导行动的洞见。

不要给我导弹，我要的是更快地闭合杀伤链。

不要给我核弹，我要的是战略威慑。

不要给我传感器和射手，我要的是jadc2。

不要给我abms的一大堆one，我要的是作战能力发布。

不要给我东西，我要的是想法、情绪、气氛、感觉和收益。

请，不要给我东西。

正是理解了这首歌，出现了Salesforce，优步，aiabnb，spacex，苹果手机，云计算aws，宜家。它们都不约而同地采用了第三平台思维加上商品思维，把打车，住宿，卫星发射，随身娱乐，机房，家庭装修都变成了服务。

现在，国防部也要听懂这首歌的深意，并立即采取行动（因为大大落后民用领域），成为给消费者也就是作战人员warfighters提供联合全域杀伤网服务的军事物联网服务公司，而不是拥有坦克飞机舰艇卫星赛博黑客的官僚机构。

基础设施和应用服务分离。用低成本的商用硬件搭建服务基础设施，然后应用层做编排调度和控制，保证用户服务质量。用户不关心底层是什么，他们只关心结果。

之前的那些不可随意抛弃无法规模化扩展的宠物作战平台，也会变成可抛弃可规模化的牲畜或者刍狗作战节点，成为军事物联网的一个个与韧性作战云连接的商品化服务化可编排的物联网设备。

3.2自主、无状态、可编排、可消耗的Endpoint

从一般意义上来讲，端点是战术边缘的终端节点。

这些可抛弃的商品，就是软件定义战争中提到的可消耗的商品化的Endpoint端点。这些终端节点分布在海陆空天网五大作战领域，它们可以是A/R无人机、低轨pLEO卫星星座、单兵到班排连营旅的UGV、ALE、无人水面和水下舰艇、赛博攻击武器平台等。

Endpoint是战术边缘的终端节点，运行战术边缘云，然后再与OCONUS云连接，OCONUS云再与美国本土的CONUS云连接。为了看清楚躲在CONUS本土开发的AI算法软件，如何跑到各个作战领域的全球各个战区的战术边缘的终端节点上的，我们以ABMS的图为例，说明AI算法的敏捷部署是如何与敏捷作战运用这种运动战结合。

由于敏捷作战运用ACE到处乱窜打运动战，一方面给对手增加了难度，但是同时也AI算法增加了部署和验证和算法训练数据的难度，所以AI算法也只好跟在屁股后面跟着敏捷远征到处乱窜。

战术边缘的终端移动节点的数据通过四种网络（软件定义网络、数据链、pLEO卫星星座、地面广域网）组成的动态网络与OCONUS云连接；软件工厂开发的新版本AI算法软件，先部署到某ACE Hub空军基地的固定节点，在那边进行测试验证后，再传到OCONUS节点，再从OCONUS节点传到该ACE Hub下辖的各个ACE Spoke分支下的各个终端节点。

战术边缘的Endpoint除了要满足可抛弃性之外，还要具备自主能力、可编排性以及无状态。

无人自主：无人自主能力是在竞争环境下作战的基础能力。当然，前面2.9已经讲过，无人自主的AI能力本身也是基于容器编排+微服务的。

可编排性：一方面指终端节点内部的容器编排和微服务调度的基础能力，这样就可以基于终端节点的MOSA标准通过DevSecOps软件工厂开发各种终端节点的APP，再通过容器镜像的安全跨域传输远程OTA升级到终端节点的容器运行环境内，从而实现终端节点像车联网的软件定义汽车那样的模块化敏捷开发各种车联网APP的能力。另一方面指的是各种软件定义战争的应用，需要基于终端节点的微服务进行单个作战领域进行服务编排，然后在不同作战领域之间再实现更高层的服务编排。

无状态：终端节点要设计成无状态，便于频繁升级人工智能算法的更新补丁，以及在敌方发起零日攻击时直接刷操作系统最快速度修复安全漏洞。有状态的数据和配置等，都可以放在云端去同步即可。CI/CD方式部署需要持续更新的AI算法到不同AOR责任区。要像升级windows和手机操作系统补丁一样，不断给装备OTA升级。

可消耗：可消耗的意思是，军事机器要从宠物变成用后即抛的牛或刍狗。或者反过来说，我们对待军事机器，不能再把它们当宠物养了，未来只靠宠物不适合大国对抗。牛群或刍狗将会是有益的补充。空军用可消耗来描述一类无人机，低成本，高可靠。不像有人的战斗机和轰炸机的结构，发动机和任务系统必须要使用几十年，可消耗无人机的组件没有那么贵，生命周期就几年甚至几个月。虽然一些A/R无人机具备降低被敌方防空系统定位和跟踪的能力，它们设计时就是可消耗的，不需要非常低的可探测性设计，机载多源信息融合能力，以及其他在竞争环境下生存的五代隐身战斗机的能力。这种设计思路可降低采购和保障成本，让它便宜到可以在对于有人飞机过于危险的高威胁区域作战。

3.3控制反转，掌控技术栈

既然一切都是刍狗都是牛，不再是宠物，那么责任反转也是必然的了。国防部从忙碌的铲屎官变成快乐的农场主，就要抓大放小。

控制反转的对象有：

API接口：掌控终端节点和作战云的关键内外部接口这些大头，小头是接口实现管不着也不想管。

基础设施：掌控CNCF标准接口，必须用符合CNCF标准规范的云原生平台。

软件工厂：掌握软件工厂的建设审批流程，掌握软件工厂本身的cATO授权。

网络：掌控网络的关键接口。

Telemetry：掌控各个终端节点装备要传输的重要数据的格式。

算法开发人员左移，也要远征，去战场接触AI算法运行结果。

服务等级定义：API接口的服务等级要由于国防部定。

3.4掌控服务化API接口

就像泰国那些命运悲惨的女孩一样，从宠物变为牛之后，消费者就只关心牲口能够提供的API服务，而不是服务宠物。

接口是定义系统范围的关键部分，它不仅仅是技术规范，还包括接口如何使用以及由谁使用的策略和流程。

要掌控的重要接口有：

云原生应用的API接口

云原生数据服务的API接口

云原生网络之间的接口

盟友和合作伙伴作为美军作战网络一部分的集成接口

民用领先的商业技术能力集成到作战网络的接口

AWS从EC2和S3两个公有云服务起家，经过十几年的发展，开发了上百种云服务，除了常用的计算、存储、数据库、分析、移动、安全、人工智能、物联网和企业应用服务以外，甚至连量子计算，区块链，卫星通信都有。这些服务已经覆盖AWS的全球几十个区域的上百个可用区。不同的服务由不同的两个披萨大小的敏捷开发小团队负责开发和运维。

未来的软件定义战争既然和IT行业一样，也是基于第三平台思维构建，那么就像AWS云服务化卫星服务，量子计算服务一样，也可以形成不同作战领域不同武器装备的指控、后勤、无人自主、任务规划、人员、作战等的云服务的集合。然后部署到全球不同战区的不同司令部和战术边缘。不同的软件定义战争的云服务由不同的两个披萨大小的敏捷开发小团队负责开发和运维。当然软件定义战争中，由于刚才3.2讲到的移动终端节点的要求，这些服务的部署可能都是机动的而不是都是固定位置的。

我们可以设想下，有了这些基于第三平台搭建的软件定义战争的云服务的集合，一大堆军方现役和退役的业务专家基于这些武器装备云服务的积木块，可以生成大量的解决方案参考架构，给军工企业提供不同的解决方案，满足不同作战需求。

只有这样，国防部才能真正成为云服务提供商（CSP）赋能的硬件公司，才能真正成为能快速响应外部威胁和技术进步变化的防务服务提供商（DSP，Defense Service Provider），从而实现前国防部长James Mattis所说的以相关速度为作战人员交付作战能力的使命任务。

3.5切片化的作战领域服务编排

有了服务，还需要基于服务来构建杀伤链的工作流。但是软件定义战争这篇文章这块基本上没讲。

这里，我们可以借鉴5G或6G切片网络的设计理念。

5G网络虽然很多人认为目前在商业上不太成功。但是墙内开花墙外香，作为一种新的技术理念，它可以用在未来的软件定义战争的业务应用的服务编排之上。

当然，我这里的意思并不是说要把5G直接用过去，而是说借鉴5G的切片网络服务编排的参考架构用于软件定义战争的杀伤链服务编排。编排的对象从5G物理网络和逻辑网络上的网络资源，变成了前面介绍过的软件定义战争的无人自主、可编排、无状态和可抛弃的终端节点。至于ai原生的6G切片，那个和我这里要说的反而没啥关系，请读者明辨。

之所以这么说，是因为5G网络切片和软件定义战争两者有很多相似性：

第一个相似性是都要能支持不同领域。5G网络的关键特性之一就是能支持不同的垂直产业，例如工业制造、自动驾驶、远程医疗、能源网络、多媒体业务等。这些不同产业对于网络的要求都是不同的，这些需求包括网络的带宽、时延、可靠性等。在5G网络的建设过程中需要改革现有的网络架构，使其能有效地支持不同业务的需求。而对于软件定义战争来说，它也需要支持海陆空天网不同的作战领域上的不同的业务。

第二个相似性是软件化和云化。5G网络的软件化和云化在当前已经成为一种趋势，基于SDN技术和NFV技术为5G网络提供所需的可编程性、灵活性和模块性，这些特性使得在一张物理网络上创建多张虚拟网络变得非常轻松，而且每张虚拟网络都是可编程的，是可以根据业务的需求灵活定制的。一张物理网络上虚拟出了多张不同的逻辑网络，每张逻辑网络分别应用于移动多媒体数据的传输、医疗相关数据的传输和物联网数据的传输。

这种在同一张物理网络中划分出来的逻辑网络，称之为网络切片。网络切片是一种能按需创建的端到端的逻辑网络，它们运行在同一张物理网络上，之间相互隔离且拥有各自的控制管理系统。尽管网络切片在5G网络中是一个全新的定义，但是像这种在单张网络上划分出来一张逻辑网络的方式并不是最新的，例如VPN技术就是这么做的。但是，VPN划分出来的仅仅是网络资源，而网络切片中划分出来的资源除了网络资源，还包括计算资源和存储资源。

对于软件定义战争，也需要根据不同作战领域，不同作战任务划分网络切片，比如陆军切片，海军切片，空军切片，后勤切片，情报切片，作战指控切片等。划分的资源包括终端作战节点，边缘云计算，软件工厂，数据库，。。。等各种资源。

第三个相似性是运营商和国防部都想快速响应未来的不确定的需求。之前电信网络运营商被电信设备厂商所绑架，用的都是定制的非商品化货架硬件的黑盒的通讯设备，遇到新需求，没法灵活定制，只能求电信设备厂商去开发新产品。响应慢，定制性差，灵活性低，还要看的捏捏设备厂商的脸色。

国防部也是类似的，F-35的自主后勤保障系统就是个典型的例子。现在运营商通过白盒或灰盒的货架硬件加开放软件来构建未来的商业网络。国防部通过MOSA模块化开放系统架构来掌控接口。

第四个相似性：资源异构性强，多厂商。这一点就不用说了——说多了都是泪。

3.6任务式指挥

军语里的指挥，在软件里面对应的类似概念是基于意图的xx，例如基于意图的容量规划、基于意图的网络管理、基于意图的容器调度策略、基于意图的零信任安全策略、基于意图的数据处理等。

软件定义战争也要指挥与控制分离，实现未来装备发展的任务式指挥：

软件基础设施平台认证审核归政府，开发运维归政府下属软件工厂和承包商。

软件定义网络，数据和控制分离，数据平面和控制平面的使用权和二次开发权归军方，数据平面和控制平面的开发运维权归承包商及分包商。

微服务应用, 智能武器的微服务接口归军方，接口实现归承包商和科研院所，比如导引头导引算法。

AI平台和ai算法使用权归政府，AI平台运维和算法开发归承包商。

Kubernetes声明式API，通过声明式API将容器调度的意图和实现分开了。这个设计，真的值得终端节点的API的编排调度好好学习。

基于意图的网络minc：将基于任务的通信联网的意图与具体联网实现分离。

零信任安全策略军方负责，具体安全实现承包商负责。

无人自主蜂群的play calling，战术归军方，战术实现算法归承包商和科研单位。

3.7本体赋能AI

不管是在战术边缘还是在不同梯队的指挥所，本体都会发挥AI赋能的作用。本体是AI的基础，没有基于本体的战场数据，AI就无法理解这些业务数据。

战术边缘的蜂群本体与AI的关系、数字工程的本体与AI的关系，之前已经稍微讲了点。联合全域战场的本体，以及不同层级的本体如何协调，以后再讲。

3.8AI赋能软件定义战争

要实现AI赋能未来战争，必须要做到软件数据AI三位一体。而软件定义战争克服了国防部传统的第二平台甚至第一平台的模式，可以保障软件数据AI的三位一体。之前第二平台上长出来的烟囱化的作战系统，做不到三位一体，导致的后果具体从算法战先驱JAIC创始人沙纳罕部署AI算法的吐槽可以看出。

这三者之间的关系是这样的。

软件是数据和ai的基础，数据是ai的基础。

Wirth有个著名公式，程序=算法+数据结构

而现在，AI= 数据+算法+软件

实际上的公式更为复杂，要考虑好多事情：

军事AI应用 = Endpoint终端节点+JADC2战斗网络+Telemetry遥测+数据+算法+云原生+JAIC JCF+人工+cATO

这个公式这样理解：

终端节点Endpoint：AI算法的训练数据来源以及AI算法部署的目的地之一

JADC2战斗网络：连接战术边缘，oconus和conus，传输真实训练或仿真数据，更新算法微服务容器镜像到endpoint。

Telemetry遥测：记录终端节点的实际数据：包括日志、度量值、事件

数据：训练算法用的数据主要来自各个战术边缘的真实战场，不管是光电还是电磁频谱还是。。。没有高质量训练数据，ai就抓瞎。当然合成数据也能用用。数据要从数据就绪（算法工程师要能够轻松拿到所需数据）到数据赋能AI（数据能够为算法训练做出贡献）。

算法：不用说了

云原生：AI算法微服务软件不会水土不服的关键技术支撑 JAIC JCF：提供整个国防部统一的AI算法工程师的经过安全认证过的开发平台和AI算法工程师和数据工程师常用的安全容器镜像仓库

人工：人工智能少不了人工打标签

cATO：AI算法也是软件，也要持续授权

零信任安全：不用说了

4.总结

软件定义战争这篇报告，本质上就是把云原生的第三平台的逻辑，从民用领域应用到了军用领域。

之前的装备发展逻辑是，花很长时间发展一种新的装备，再把它嵌入到作战体系中，使用几十年后，再逐渐换装淘汰旧装备。

而软件定义战争则反过来，先用第三平台搭建好空的架构，再把mosa标准化的软件定义的新旧装备系统或子系统嵌入进去，不断敏捷升级子系统的软硬件，引入成熟度更高的新技术新能力。而嵌入到第三平台体系中的系统及子系统，其成本，生命周期，维护成本，也大大不同于第二平台装备。他们不再是军方的宠物F-22、航母、高端卫星等，而是天地不仁国防部不仁军方不仁军种不仁的刍狗——模块化敏捷开发软件定义的可抛弃的无人自主的灰色牲口。

这样，装备乃至作战体系，就成了软件定义的不断敏捷升级能力的忒休斯之船。国防部才真正成为软件为中心的数字化企业。