本文是本人2019年9月11日受邀在“SD-WAN产业发展论坛”上所做演讲的文字整理稿。之所以接受邀请，第一是因为听说韦乐平先生将出席论坛，终于有机会与我仰慕多年的男神近距离接触，只可惜天不遂人愿，第二是最近一直在思考这个问题，众里寻他千百度，仍不知SDWAN确切为何物，希望借此机会向业界专家讨教。此次演讲仅代表我个人观点，这种闲云野鹤的状态也顺便令我免去直播带货之苦，可以把时间用在更加有趣的问题上。
作者 | 李昕
北京邮电大学副教授、SDWAN重度嗜好者
电信运营商需要什么样的SDWAN这个题目由运营商或者设备商的专家来讲可能更合适一些，这次会议的其他演讲者其实也都在间接讨论这个问题，我今天站在这里是希望通过抛砖引玉的方式和大家做一个交流，探讨一些问题背后的问题。
事实上运营商对于SDN和SD-WAN的热情并不弱于互联网公司，往前推几年，从AT&T提出Domain2.0开始，国内三大运营商都对SDN表现出巨大的热情，三大运营商的领导先后到美国去AT&T参观学习交流，回国以后就开始制定各自雄心勃勃的SDN计划。然而从后面几年的业绩来看，实际效果并没有达到预期，运营商所面临的困境其实越来越严峻。最近这两年我和很多运营商的朋友谈起SDN和SDWAN，他们关心最多的问题，已经不再是SDWAN技术，而是到底什么是SDWAN，这东西有没有一个确切的定义。我想这个问题背后的问题，其实不是SDWAN到底是什么，而是为什么SDWAN没有改变运营商的困境。
最近思科和华为一直在大力推广Segment Routing，那么SR尤其是SRv6是不是运营商的强心针，是不是可以扭转困局？我觉得首先要考虑SR部署的前提条件是什么，部署成本和运维成本是否低廉，能解决什么问题以及不能解决什么问题。现在运营商的状况很像图上的这头大象，左手攥着SDWAN，右手攥着NFV，开源控制器和设备制造商都在鼓动说你只要有了这两样东西就可以跳绳了，但是运营商经过短暂的兴奋之后发现自己这么大体量绝不可能想跳就跳。
今天我从三个方面和大家一起探讨运营商到底需要什么样的SDWAN：
第一，SDWAN到底是什么；
第二，SDWAN从哪里来；
第三，运营商要到哪里去。
SDN技术架构最大的特点是集中控制模式。但是假如说集中控制就是SDN，那么在电信领域集中控制的历史要比互联网漫长得多，为什么那么多集中控制的系统后来都被淘汰或者被互联网边缘化了？
ONF对SDN的标准化定义里面提到了几个关键词，对于互联网行业的人来说可能会觉得很新鲜，但是在运营商的朋友们眼里，这些技术实际上在电信领域长期以来一直被关注和讨论，并且不乏实际的案例，那么能否据此就把SDN或者SDWAN看成是一个历史问题的线性增强？
下面这张图是SDWAN的一个通用逻辑架构，和SDN很像，分三层，上面是控制器，控制器上面是业务编排，下面是基础网络。可是电信运营商的网管系统，也是这么一个逻辑架构，那么网管系统算不算SDWAN？
关于SDWAN的特性，有一个非常有趣的现象，国内做SDWAN的公司在介绍自己产品的时候，在产品特性方面表现出非常惊人的一致性，很多公司介绍产品特性的幻灯片，稍微夸张一点说，除了logo不一样，其实看不出来有多大差别。
但是透过这些表面上非常同质化的产品，落到具体的应用场景，又会发现巨大的差异化，从应用场景、目标客群、核心功能到营销模式，截然不同，而且覆盖的领域极为广泛，从2C的应用加速，一直到2B、大型基础网络设施的管控全部覆盖了。
这就很有意思，一个技术为什么能适配这么广的范围，这在整个通信和互联网历史上非常罕见，除了TCP/IP这种核心协议，很少有哪个技术能够覆盖这么广谱的范围，而且参与的主体也差不多把整个行业全部给卷进来了。2013年之前，国内明确说自己是在做SDWAN的互联网公司，大概两只手就能数过来，但现在，不声称自己在折腾SDWAN的网络公司一只手就能数过来。甚至是互联网服务提供商，比如ZOOM、WEBEX这样的互联网视频会议提供商，核心竞争力也包括网络调度能力。虽然音视频编解码技术上的优势仍然是重头戏，可能解决了视频会议在没有服务质量保障的互联网上面临的90%的问题，但剩下来决定谁能脱颖而出的10%的问题，是由网络能力或者说SDWAN能力决定的。
SDWAN的形态尽管如此丰富，但仍然可以大概划分为两类，一类是以网络为中心的优化，第二类以用户体验为中心的优化，前者自下而上，后者自上而下，但是这两种趋势实际都是为一个目标服务：把互联网产业链的上下游打通，完成整合。如果网络这一层不做任何改变，仍然作为基础资源和尽力而为服务者出现，不能提供差异化的网络服务，仅仅依靠应用层优化，很难满足日益苛刻的用户体验需求。
应用和业务的多样性，必然带来场景、需求、用户群体的差异化特性，而SDWAN归根结底是为应用服务的，如果是为了网络而优化网络，其实运营商的网络，尤其是骨干网已经非常稳定了，并不需要大动干戈再去优化几个百分点。这就导致SDWAN的技术形态非常多样化。
从抽象意义上来说，所有的SDWAN都可以包含一个控制器和一堆控制代理，但是实际上很多SDWAN公司压根就没有控制器，仍然赚到很多钱，反而是把大量的人力和物力投到控制器研发上的公司，似乎都比较艰辛。这样一来就没有办法用一个统一的技术架构概括什么是SDWAN，所以只好根据场景进行粗粒度的细分，通用型、叠加型、云端型、混合型、服务型等等不一而足，这已经不是在定义技术架构，而是在用事后诸葛的方式来解释和匹配不同场景下的解决方案。
即使是标准化这件本来应该很标准的事，在SDWAN领域里面也硬分叉了。虽然IETF和ITU-T针对同一个技术制定出不同标准的事情也经常发生，但是二者的差异主要是体现在细节上，大是大非的立场通常还是基本一致的。相比之下，SDWAN在不同标准化组织里面的形态实在是太不一样了，几乎不是一个物种。
这让我想起孔子说的一句老话，“君子不器”，君子不应该把自己限制在狭窄的专业领域，而应该是通才。
SDWAN倒是很符合君子的标准，怎么看都不像是一门具体的技术，因为它不符合一个具体技术应该具备的基本特征：针对具体的问题。
SDWAN到底是什么？我觉得SDWAN不是网络技术历史发展趋势的线性增强，它的核心价值是释放资源流动性，或者说释放资源跨域调度的横向流动性。从这个角度去看，就能理解为什么ONF标准定义会有这么多的误解，比如解耦被当成隔离，集中当成完全排斥分布，而抽象的到底是网络资源还是网络服务，开放接口被理解成了用白盒替代黑盒，包括白盒设备可以让运营商摆脱对设备商的依赖性，实际上现在运营商看明白了，白盒的绑架能力比黑盒厉害得多。可编程则被理解成运营商的员工都要学编程才能上岗，不会写代码的网工会失业。这些误解都有一个共同的特点，那就是站在传统网络运营的角度去看待革命性的变化，局限在一个垂直的方向上考虑网络资源流动性，也就是在一个烟囱里面考虑如何为了优化而优化，穿新鞋走老路的状况就难免要发生。但实际上，SDWAN的核心是要把整个网络转化为服务，在纵向和横向两个方向上充分释放网络资源的流动性，把跨域、跨部门调度网络资源的成本降到最低，使之从需要上级特批的个案转变为常态化的操作。
谈到跨域我们马上就想到运营商里面的烟囱式组织结构以及部门墙。运营商面临困境的这些年，烟囱基本上扮演了万能背锅侠的角色，有问题就甩给烟囱。很多人认为只要把烟筒拆了，这个问题就解决了。
真的是这样吗？我个人认为完全不是这样，烟囱式组织架构根本就不是问题的根源。如果看一下中国移动历年的业绩，你会发现在烟囱式架构最完善最发达的时候，恰好是营收和利润增长最快的那几年，这足以说明烟囱至少不是从娘胎里出来就在阻碍发展。而且这种条块分割的资源管理和运营模式，在以基础资源售卖为主营业务的时代效率是最高的，甚至是被优化到了一个极致。但是基础资源售卖业务的增长几乎完全依赖于用户数量以及每用户消费量的持续增加，互联网普及到一定的程度，就会遇到增长的魔咒。从下面这张图上很容易看出来，用户量和运营商业绩的增长瓶颈在时间上的是重合的。基础资源售卖注定是条块分割的，而被分割在不同烟囱里的资源的垂直流动性，当烟囱的高度达到极限，也就很难再产生正向的增益了。这倒不是说资源就不流动了，而是说虽然资源的流动性并没有减弱，但是这种流动性所能创造的价值，已经大部分被烟囱的建造和运维成本吞噬掉了。
尽管中国还有上亿用户没有上网，但是从下面这个图上能看出来，网络覆盖、带宽和资费已经不是这些非网民上网的主要障碍，这种情况下继续投入更多的资源可能还是很难把这些不在网用户吸引进来。
如果能够以理性客观的态度，站在资源管理的角度看烟囱，不难发现烟囱其实对资源做分类管理维护和运营的容器，问题出在现在用户希望直接得到一杯鸡尾酒，而不是先去提交一堆工单，等签字盖章的流程走完，再从每个杯子里面嘬一口，自己去混合这杯鸡尾酒。容器本身没有问题，只是用户的需求发生了变化，而能够响应这种变化的机制缺位了。可如果仅仅为了一时之快就打碎这一堆坛坛罐罐，可就真的啥也没了。
现在回到我们的终极问题，SDWAN到底是什么？我觉得SDWAN并不是要颠覆这些纵向资源管理体系，而是要在纵向体系之间建立一个横向的管道，或者在一个非常大的范围内让原来很难横向流动的资源能够在一个新的层面上自由流动。
第二个问题，SDWAN从哪里来，或者说这种网络资源横向流动的需求是如何产生的？我认为最重要的原因是互联网的重心转移了，从网络向应用转移。首先，在全球范围内网络的马太效应或者说幂律特性越来越明显。下面这三张图是2007到2016年间北美的互联网流量在AS级别的聚集度，2007年最大的151个AS也只不过聚集了不到30%的流量，但是到 2016年只要10个AS就已经聚集了超过70%的流量，聚集到这个程度以后已经很难从快速扩张中获得巨大的利润增量了。
与此同时，互联网巨头在以更快的速度崛起，现在互联网上的流量主要来自于几个大公司的应用，长尾部分所占的比重已经非常低了。
另外一方面，企业上云在2018年迎来拐点，开始成为确定性趋势，即使是传统行业的企业客户也不再怀疑这个趋势，万物云化必然倒逼云网一体，这时候互联网的核心枢纽开始从运营商的骨干网路由器转移到超大规模数据中心。数据中心天然就具备跨域、跨层和跨行业的基因，也没有太多历史包袱，但是电信运营商要完成转型、纳入以互联网应用为中心的轨道还需要经历一个漫长的过程。
虽然应用层也会针对广域网服务质量不稳定的问题进行优化，但优化所能达到的程度是有限度的，并不能满足用户对体验越来越苛刻的要求。而运营商继续依靠提升网络规模、加大资源投入的方式来提升用户体验也在面临边际效用递减的困境，于是就出现了一个网络服务的真空地带。有需求就会有市场，中间这个真空地带就催生出一个新的产业，这个产业我们就管它叫SDWAN。
我认为SDWAN背后的驱动力是互联网行业要向下整合资源。在任何一个产业里面当头部企业表现出超大规模性的时候，继续保持利润增长的必经之路就是向下整合资源，无论是汽车行业还是能源行业都遵循这一规律，不向下整合资源很容易遇到增长的瓶颈。
对于互联网行业来说，整合资源目的都是为了满足更多的需求、适配更多的场景、进一步降低采购和运营成本，这些都需要依托对资源的跨域调度，这个方面谷歌是一个非常典型的例子。
谷歌持有的网络资源量非常庞大，说它是全球最大的电信运营商并不为过，对整条产业链进行深度整合一直是谷歌的基本战略之一，包括投资网络基础设施、DNS调度和全球负载均衡、通过BGP和其他运营商对接、根据自身网络资源使用情况做超越于BGP策略之上调度灵活调度等等，最终的目的是为了优化用户体验。
这是一个完整的链条，非常系统性的工程，其中的关键技术是应用性能测量、网络性能测量、系统可靠性工程、差分服务、私有协议、自研软硬件，并且极度强调向后兼容，保持对下游网络供应商的友好性。虽然谷歌完成了全球第一个在生产环境中部署的大规模SDWAN，但SDWAN更像是对这些技术进行组合的方式之一，控制器只是其中的一个组件，而且整个系统对分布式控制非常倚重。
互联网企业的超大规模性私有化基础设施一定会催生出来自研设备以及私有化协议来提升系统效率，这也是为什么现在BBR和QUIC这种协议不需要再经过国际标准化组织就能在全球普及，谷歌的体量已经足够大了，完全可以在自己网络内部部署这种协议并且保持对原有协议体系的友好性和兼容性。而BGP则逐渐成为操控外部网络资源的工具以及低成本传递私有信令的容器。
对于互联网服务供应商来说，比如视频会议、在线教育这些对延迟、抖动敏感的应用， SDWAN越来越成为一种内生能力，规模大到一定程度，就不可能单纯依靠应用层优化或者网络资源超量供给的方式来解决网络层的问题，向下整合资源的能力就会成为核心竞争力的一部分。
互联网发展到这个阶段，已经不能再用线性发展的眼光来分析问题，因为很多基本的规则和特性都在发生根本性的变化，所以你能看到传统的通信设备制造商的利润率也在下滑，因为大部分产品线是在沿着上一个时代的技术路线做加法，不断挺高网络资源纵向流动的效率，关注的是“点”而非“线”和“面”，但是跨域调度网络资源天生就是要和“面”打交道。
SDWAN也不是传统网络技术路线的线性优化，否则不会吸引这么广泛的参与者。SDWAN甚至根本不算是一个严格意义上的网络技术，它更像是调度资源合成服务的枢纽。打个不太恰当的比方，以前市场上都是卖粮食的，用户要自己回家做饭，没几个人舍得下馆子，饭店能提供的菜品和服务也很初级。但现在生活水平提高了，用户对餐饮服务业的需求已经逐渐超过了基础农产品，供应商要保持利润的增长，就得把粮食转化成种类丰富的面点。越靠近用户体验，需求和场景的种类就越多样化，自然就会涉及到各种场景当中做跨域资源调度和合成服务的生意。
把SDWAN简单理解为网络技术是一个误区，类似的误区其实一直都存在，比如对于云计算，过去大家只看到计算没有看到云，导致腾讯和百度这样的巨头在这个领域被阿里甩在后面。到了SDN时代大部分人关注的是网络，而忽视了背后的服务价值。只盯着网络很容易陷入线性思维的惯性看待非线性的发展，下面这张图上的这些误区是盛科的张卫峰总结的，直到最近大家才认识到这些说法都是不对的，但大部分人并不知道产生误区的原因是缺乏服务视角。如果只站在网络优化的角度去看，这些说法多少都能站得住脚。
为什么大大小小的网络公司一提到SDWAN就特别喜欢画控制器的架构图，因为只有在网络这个领域里面才会这么把控制平面看得非常重，在服务层面控制只能算是达成目的手段之一，而且不是最重要的手段。电信运营商还没有适应以服务为中心的运行方式，以前运营商一直站在互联网世界的中心，其他人都围着他转，现在服务变成了中心，但是运营商自己还没有纳入以服务中心的轨道，而且国内的三大运营商全都是超大规模组织，惯性的力量使他很难完成快速的转变。
运营商怎样才能够通过整合跨部门、跨领域的资源获得新的增量？在讨论这个问题之前首先要想明白两件事情：
第一，烟囱是有价值的，问题在于烟囱的高度达到某个限度之后再增高已经不能产生新的收益了。那么在这个时候继续扩张基础资源投资，是不是不明智？我觉得这是一个理性的选择，因为这里面牵扯到需要想明白的第二件事情，运营商的核心优势是什么？我认为是基础设施属性和超大规模性，如果这两个属性丧失了，运营商就可以退出了，所以在任何情况下运营商都要保证自己在这两个属性上面占据压倒性的优势。之所以这种持续投入不能产生对等的产出，是因为原来的产品形态，专线、高级专线、基础网络是三个完全分离的层面，相互之间没有支援和协同，没有办法形成一个内生的循环增益系统。
我认为一个具备活力的体系应该是在一个利润微薄甚至趋近于零的基础网络上面做场景细分，在细分场景里面再催生出高利润的服务，由这部分利润再去回馈到基础资源，保持自己的超大规模性，再催生更多的业务场景，这是一个正向的循环。而这个正向循环在烟囱式的组织架构里面是不存在的，需要一套外部的机制来起到枢纽的作用，我们把这个枢纽称为SDWAN，显然SDWAN并不是一个具体的产品或者技术。
电信的云堤就是一个非常好的枢纽的例子，电信云堤在抗DDOS攻击方面国内第一，无人能及，包括阿里云都要采购云堤的服务。但是电信云堤的雏形刚刚形成的时候， SDWAN这样的名词还没出现，更别提ODL、ONOS这样的开源控制器。云堤完全依托中国电信网内的技术和设备，一开始全靠人肉做调度和控制，后来自己做了自动化调度系统，直到前两年才有人跟云堤的刘紫千说你们这不就是SDWAN吗。右下角这张图只是电信云堤的技术人员从SDWAN视角重新绘制了一下云堤的整个架构，其实不这么画也行。电信云堤最核心的优势不是控制器或者算法，而是中国电信基础设施的超大规模性，如果没有这个核心优势电信云堤做不起来。
但电信云堤的成功并不是那么容易被复制的，因为电信运营商做资源整合的痛点不在控制而在管理。运营商内部的部门设置、每个部门的资源管理方式和颗粒度、资源的标识和定义方式、配套的运维管理体系本来就不是为融合而设计的，完成融合缺乏很多基础条件做支撑。这就像过去的国营粮店不可能加上一个烤箱就自动转化成面包店了，没有这么简单。
尽管电信云堤非常成功，但是仅仅依托现有的技术和机制，资源整合的深度和广度还是会受到限制，资源调度的基础是资源数据的整合，但是现在各个部门采集、存储、处理数据的方式都是和融合脱节的，数据不规范、不透明的问题越来越突出，融合的程度就要被迫向数据精度和透明度最差的那个部门看齐。
解决跨域调度资源问题的另外一种方式，是引入一个新的产品填补资源拼接图谱中的空白。下面这张图是一个在三大运营商里面都已经采用过的游戏加速方案，在BRAS后面增加一个PANABIT应用分流器，把游戏流量引导到对应的网络切片，这里面PANABIT应用分流器起到了运营商的用户接入网络和专用切片之间的枢纽作用。
无论是电信云堤还是游戏加速方案，都产生了非常显著的效果，并且开始让运营商意识到跨域调度资源所能产生的是乘数乃至指数效应，而不是线性的加法效应。这些运营商的内部创新也开始让更深层次的问题有机会浮出水面。比如，用什么做统一的资源标识，这个标识怎么定义，能力服务怎么描述，怎样和原来的资管系统影射，描述怎样在各个部门之间规范，包括数据采集规范，还有硬件平台是否支持，是否需要设备制造商提供新的特性，服务场景如何挖掘，以场景为核心的运营体系怎么和原来的运营体系对接，以及怎么解决规模化和低成本的问题。这些都是非常现实的问题，也都是现在市面上的SDWAN技术无法解决甚至根本触及不到的问题。
运营商要解决这些问题，是否也需要数据中台作为支撑？前段时间阿里提出要建数据中台，于是互联网巨头们纷纷拿出自己的数据中台方案，以至于在互联网这个圈子没有中台都不好意思出来混。为什么要建中台？中台这么好为什么以前不建？我认为这背后的驱动力还是规模化驱动的跨域资源调度需求。互联网公司大到一定程度以后，在内部也需要部门之间建立起来资源横向流动的渠道，而内部资源横向流动的前提是对分散在各个烟囱式容器中的数据进行统一规范和管理，而且不是把几个库合并成一个库那么简单，关键是规范各个部门采集、处理以及共享数据的方式。没有一个统一、精确、实时的数据视图，控制器的算法再聪明，也不可能做出高效的决策。
我们再来谈谈Segment Routing（SR），我认为SR的核心是标识而不是控制器或者源路由。虽然SR看起来很简单，不过就是“MPLS+源路由”或者“IPv6+源路由”，但是在一个复杂巨系统里面，所有看起来非常简单的解决方案都已经被暗中标注了高价，只不过这个成本是隐性的。上面那张图上罗列出来的这些问题都不是SR这个技术能够解决的，但是SR要形成规模化效应又必须以这些问题已经解决为前提。
不仅仅是运营商，互联网公司也干不了毕其功于一役的一锤子买卖，做不到靠一个技术就能成功转型。即使是谷歌、阿里这样的巨头，它的私有协议也得借壳上市，比如把TCP掏空塞上自己的东西，或者在外面封装一层TCP或者UDP，或者把BGP变成SR的信令容器或者SDWAN的南向接口，他们也没有办法一步做到彻底的更新。
对于电信运营商来说，基础设施属性和超大规模性既是优势也是灵活性的约束，大象跳绳这个问题的核心矛盾不是缺一根跳绳，而是没有找到符合大象特点的运动方式、训练计划和膳食规划，所以它没办法跳起来。
或者说，如果运营商跨域调度资源问题的核心仅仅是控制和计算，我们坐在这里还有什么讨论的意义？控制和计算这两件事情在电信网络里面一直都解决的很好，根本不是问题。狭窄的网络视野导致我们一直盯着控制，控制器应该怎么做，算法应该怎么做，这两件事我觉得恰好是最不重要的事情，至少在SR里面最重要的东西是标记映射服务器，至于控制器反而没那么关键，因为控制的功能本身就已经存在于现有的设备和网管系统中，直接复用也能玩得转。
退一万步说，如果SDWAN的核心价值就是计算路径，那么在运营商的网络里面这么庞大的支撑系统在支撑什么？如果只是计算路径需要这么庞大的支撑系统吗？其实不需要，计算路径也不是这个问题的核心。当我们把SDWAN仅仅抽象到控制层面平面的时候会觉得它很简单，但是如果放到一个超大规模网络里面，这个问题就变成你能否承受得起软硬件以及支撑系统升级和运维的成本，或者你的支撑系统和运维系统能否适应这样一个新的横向资源流动。当系统变的非常庞大的时候，需要一个漫长的过程逐渐进入到正轨，否则超大规模性背后的风险会变的非常高，比如切尔诺贝利核电站、挑战者号航天飞机都非常复杂，但风险也非常高。这就是为什么在谷歌的网络部门讨论更多的是SRE，而不是SDWAN。而且谷歌最近几年的文章也不怎么提软件定义这个事情了，因为有更重要的事情要做。当你在一个本来纯粹分布式系统当中注入了集中式控制的因素以后，或者在一个垂直运行的系统当中加入横向流动性之后，系统可靠性会面临巨大的挑战，而且传统的解决方案可能都帮不上什么大忙，这时候首先要保证的是系统能够可靠运行不崩溃，而不是首先保证有一个好的控制器，能算出好的路径。
SDN曾经被短暂地视为下一代互联网技术，SDWAN会不会改变整个互联网体系架构？我觉得恰好相反，SDWAN会继续强化而不是颠覆原有的TCP/IP架构。TCP/ IP简单的核心会向着更加简单的方向去发展，大互联时代对体系架构的要求只能是更加简单、更加开放、更加包容，而不是更加优化。网络基础设施会像电力、自来水那样逐步退居幕后，存在感越来越低，但绝不会衰落。因为跨域的互联互通、资源调度是提升全社会生产效率的必由之路，这样的需求只会持续增强而不是衰弱。
私有协议和事实标准越普及，他们对于核心网络协议的稳定性要求就会变得越高。
互联网应用越复杂，一定会要求上层和底层之间的Overlay变的越简单，而不是跟着越复杂。互联网规模越大，核心简单边缘复杂这个基本规律会被持续强化。传统协议当中的一些和早期互联网特性耦合的东西，现在正在被逐步剥离掉或者被事实标准替代掉，而且是在朝着简单而不是复杂的方向发展。
电信运营商学不了互联网，也没有必要模仿互联网。网络基础设施的价值在于提供稳定的预期而不是持续创新，这是产业链的定位决定的，跟运营商有没有研发能力关系不大，没必要把研发能力想得那么神奇。而运营商的超大规模性也决定了没有任何第三方能够真正理解其内部机制、体制和运行模式，运营商的解决方案只有运营商自己能判断优劣，而且它的基础设施属性和超大规模性也决定了这一领域的创新必须具备规模化部署的可能性，一时一地的小打小闹或者灵光一现于事无补，更不可能持久。
在这样一个体量巨大的复杂系统内部，要形成一个新的内生循环增益注定是一个螺旋式上升波浪式前进的非常曲折的过程，不会一步到位。更何况即便要一步到位，也需要应用层形态、应用层和基础网络的关系能够进入确定性的终极形态，但运营商和互联网各自的形态以及相互关系都是一个共同持续演进的过程，从来不会有终极答案。所以SDWAN也是一个持续演化的过程，而不是一个终极形态。
在演讲结束之前，我想说SDWAN这件事情里面最重要的一点，其实是人。
决定胜负的关键因素是人而不是一两件新技术。
以运营商体量之大，不可能有任何一个厂家能够提供一揽子解决方案。运营商最终会选择什么样的发展和变革路线、达到什么样的目标，不是取决于采用什么样的技术，而是取决于在运营商内部有没有足够合适的人去完成转型。
所以电信运营商到底需要什么样的SDWAN这个问题其实没有答案。鞋子合不合脚，自己穿了才知道，行胜于言，干就是了。
感谢大家今天给我一个客串的机会，希望会后能够和各位有更深入的交流。
祝大家中秋节快乐！
声明：本文来自力博睿生，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
