作者简介：张云锋，十年网络相关行业从业经验，好奇瞅瞅公众号博主
从百家争鸣到战国七雄
随着 SASE 在 Gartnter 炒作周期曲线中升至顶峰，SASE 进入了百家争鸣时代。百家争鸣，听着极具学术浪漫主义色彩，但随之而来的是：变革数量剧增，国家数量骤减，百国春秋迅速过渡到战国七雄。
说的更直白一些：顶峰之后是幻像破灭，只有熬得过破灭期，才有机会进入稳步成长期。百家争鸣只是思变时代的理论碰撞，战国七雄则是变法时代的军事交锋。未雨需绸缪，最好开始考虑以更加务实的姿态来落地。那就回到现实，亲历过国内 SD-WAN 市场的朋友可能会倾向认同：
1）这个市场的门槛太低，玩家太多，但凡有个 PPT，都敢声称自己在做 SD-WAN，结果导致很多在做 SD-WAN 的反而不敢说自己在做 SD-WAN。
2）当前拼杀的一大方向是为客户降本，通过降本为客户创造价值，这笔账比较容易算清楚，但降本意味着做低了自己的收入，革了自己的命，这活干起来多少有点痛苦。
3）那就赶紧找找增效这条路，通过“我为客户增效”的方面来弥补一下“我为客户降本”时割掉的肉，这个增效可以是什么呢？两个层面：
- 在 SD-WAN 本领域内寻求增效：产品服务化是个趋势。诸如设备类单产品，降本有余（例如降低网管成本），增效不足（例如十个研发优化不及一条线路来得有效）。客户关心的是最终效果，而不是单点技术的先进性，把设备，资源，服务综合在一起，对供应商而言，有更大的盈利空间，对客户而言，有更大的便利性。当前主流设备商和中小服务商各说各话的局面，让一些稍具体量、用过“好东西”的客户，在做选择时也挺尴尬 —— 每个供应商都能合我一部分心意，但鲜有一个供应商可以满足所有。
- 在 SD-WAN 相关领域寻求增效：云网安不分家，一个天然直觉就是将云网融合，将网安一体，再蹭一下边缘计算这个大 IP，那就成了那个相对时髦一些的词了：SASE（Secure Access Service Edge），一种将网络与安全原生结合的综合云服务。网络和安全各有一条演进路径，今年安全厂商的演进明显快了好多，又给整热了一个 SSE（Security Service Edge），直呼同行牛逼。
作者倾向于认为，SDN，SD-WAN、SASE、SD-Branch，看看脉络即可。每个机构都在造新词，每个厂商都在造解读，这是他们的工作，若是非要较真沉浸进去，容易烟花缭乱，迷失自我。我等俗人都还都活在现实世界，多少需要留些心力看看怎么改变世界，顺便看看怎么改善生活。所以，本文谈及的 SASE，可能非彼 SASE，很可能没那么高档，甚至对 SASE 这个词也没那么迷恋，只是发现目前为止，这个词在表达云网安融合时，相对最为达意，那就拿来用一用。且在百国春秋的痛苦现实中煎熬久了，容易让人萌生一个有点刺耳的念头：这个市场可能容不下百国征伐，战国七雄才是历史趋势。毕竟，拿 SD-WAN 取代 IPSec VPN 简化运维是一回事，跟随大势持续投入持续演进就是另外一回事了。本文的目的就在于从网络出发，分析一下可能的生态群落与生存之道。必须承认，所有的预测都是跳大神，区别在于舞姿是否优美。作者可以做的是：跳得尽可能卖力一些，尽可能有章法一些，欢迎同行交流探讨。
云服务析构
让我们从百家争鸣时代开始梳理脉络。系统调研了一下，百家在描述 SASE 时，一般都会前置一段描绘自己擅长领域的定语，不过最后的主语基本都会趋于统一：云服务。就从意见一致的部分出发，先来析构一下云服务类产品 [1]。
云服务 = 资源 系统 服务
要素一：服务
最终的产品形态是服务，这是一种比软件还具软性的载体，意味着极大的灵活性与开放性。举个最土鳖的例子，在拿 SD-WAN 做多分支互联时，技术派总是喜欢往高大上的方向去说，诸如 ZTP 特性可以避免专业 IT 人员去分支上门，从而降低运维成本，但现实是，如果客户就是要你提供上门服务时怎么办，好好教育一下客户吗？其实并不矛盾，ZTP 是个系统功能，按需上门是个支撑服务，系统归系统，服务归服务。
总体而言，服务与要做的生意，即与目标市场强相关。选定的生意决定了服务的定义，进而决定了业务界面和业务流程。
1）业务界面：哪些是我要去做的，哪些是我不会去做的。做的话，是什么服务等级；不做的话，是真的不做还是找合作伙伴来补位。大部分是对外的，需要结合自己的市场体系和客户群体来梳理。
2）业务流程：需要设计怎样的业务流程，去支撑所承诺的服务范围和服务等级。大部分是对内的，需要直面自己的组织架构和组织能力。一项新业务要孵化落地，往往需要串接起相当多的工种，尤其在早期，他们常常在系统之外，甚至在组织之外，这里更多考验的是生态理解和资源整合的能力。
要素二：资源
服务是无形的，但总需要一些实体的东西来支撑，比如捏个脚也得需要买个脚盆毛巾什么的吧。资源和服务是服务类产品的必需，只不过，有的生意，资源很薄，服务很重；有的生意，资源很重，服务很薄。市面上有大量的资源供应商，在客户侧的竞争逻辑就是性价比。然而，资源本身的同质化已经极其严重，要提升性价比，只能在服务的厚度上做文章，即从卖资源过渡到卖资源服务，变相映衬了产品服务化这个大趋势。
要素三：系统
需要一套 IT 系统，拉通资源和服务，进而整合组织的人、财、物。值得一提的是，如果跳出技术视角，就会发现系统其实不是必需。比如，捏个脚需要 IT 系统吗？只不过随着产业革命滚滚向前，同业竞争的壁垒越来越高，它就慢慢显得是必需的了 —— 捏脚上了 O2O 之后可以大幅降低交易成本，如果坚持不用 IT 系统，就会慢慢失去竞争力。可能正是因为 IT 系统变得越来越厚，慢慢就让人们，尤其是技术出身的人，忘却了系统的本来目的，容易偏离成为“为了做一套牛逼的系统而做系统”。奔着牛逼去做系统，不太可能把业务做好；奔着业务去做系统，更有机会把系统做牛逼。
云服务的核心竞争项一：要素整合
云服务的业务界面是服务，重运营；运营火拼到一定程度，需要系统对资源和服务做深度整合，而不是基于三方厂家的通用方案去对线。
为了说明这个论断，让我们来回顾一下运营商和云厂商在云时代的对线情况。运营商的存量客户，不可谓不多，运营商的运营经验，不可谓不足，但在云业务方面，确实落下很多，这不是中国运营商的问题，国外同行早已躺平走上转售之路。认为其中一个很重要的原因：运营商的资源能力和服务能力很强，但其核心系统大多来自设备商；设备商的产业视角和系统能力很强，但其缺乏具体的业务场景，于是就容易演化成类似局面：N 个运营商基于各自的资源积累、客户群体和用户场景，向 M 个设备商提出了 O 个需求；设备商的主要产品是设备，带有制造业属性，意味着必须规模出量才有价值；于是，设备商灵机一动，开发了 P 款产品去实现了 X 个功能；当然，这 X 个功能只有经过各种“有技术含量的拼接”才能大致实现原始的客户诉求。这里会有什么问题：
1）直接的问题是，这个“场景-需求-分析-综合-实现-交付-使用”的链条太长了，且基于历史原因，每个运营商的资源禀赋、客户场景多少有些不同，几乎很少有人能全部看懂；设备商用 P 款产品去实现 X 个功能也是无奈之举，最终导致用户界面容易成为下图，即，我可是相当专业的，你最好去先考个证之后再来使用。相比之下，成势的公有云几乎清一色全是互联网出身，资源、系统和服务三要素都是新长的，是一种深度整合的关系。某种程度上，指望运营商拿着 M 个设备商的 P 款装备，经过五花八门的培训之后，去和自研武器贴近前线快速响应的云厂商火拼，确实有些强人所难。举个不太恰当的比方，前者有点像 1962 年的三哥，纵使前期有存量实占优势，有美苏两霸的扶持，终究也是难以抵挡在骨子里独立自主、快速响应的 TG 反击。
2）更深一层的问题是，要素分离的协作模式，在管道运维层面可以运作，在服务运营层面很难发力。传统系统的目标是优先满足掏钱方的需求，但云服务系统的核心目标变了，最先需要满足的是“掏钱方的掏钱方需要什么”。别忘了系统的实际生产者离最终的用户场景还隔着 N 个运营商呢，纵使有心也天然无力，干着急使得他们容易过分去卷掏钱方的运维需求，也就容易让系统长成上图模样。
3）再深一层的问题是，要素分离的协作模式，可能会带来商业模式问题。运营商的最终产品形态是服务，而设备商的最终产品形态是设备；服务如何挣钱离我太远，我关心不到，我关心的是设备比重如何大一些，这一点与运营商的根本诉求其实是有出入的。
轻装上阵，深度整合，逐步生长的优势明显，随着云厂商的业务越长越大，云厂商对资源（运营商的大本营）和设备（设备商的大本营）的涉足，也是越来越深。例如，近期 Google 和 Facebook 宣布新建海缆，代号 Apricot，这是 Google 在 2021 年宣布建设的第二条海缆，建成后将补充到 Google Cloud 的海缆版图 [2]。
完备的基础设施，丰度的服务，海量的用户，持续的产研投入，公有云正在试图吞噬一切，某种程度并不夸张。
云服务的核心竞争项二：服务丰度
前老板常说一句话，大意是：“我们店里要卖龙虾和青菜，客人进店是因为想吃龙虾；现在有这么多店在卖龙虾，龙虾可能就挣不到钱；不过吃龙虾总有腻歪的时候，到时候就搭配点青菜挣点钱”。觉得其中一个含义应该就是，做生意不能太直男，每个产品（趋势是产品服务化，服务产品化，所以下文不再刻意区分产品或服务）的定位是不一样的，有些产品负责引流，有些产品负责盈利，有些产品为的是布局。每个服务的定位也是如此，当服务的品类足够丰富，可以相互协同时：
1）拥有了一定的战略纵深，不至于总是被动应对市场做应激反应；
2）产生产品组合价值，即组成一个更大的解决方案，解决客户更大更全更深的问题。且看公有云就是如此，公有云从来不会只提供几个品类的服务，而是：横向涵盖了计算、存储、网络，数据，即所谓的 DICT 全品类；纵向涵盖了 IaaS、PaaS、SaaS 全层次；绝对地理涵盖了全球覆盖；相对地理涵盖了端、边、云全层级。如果你非要拆开每个公有云服务去看一看，相信有相当一部分也是不怎么挣钱的。但综合效果就是：资源，系统，服务，运营商样样都具备，甚至初始客户资源也是远超云厂商，但他们没能长出足够多可以相互协同的服务组合来，导致运营商只能解决客户问题的一部分，没法做到像公有云那样整体和彻底。这种跟随时代长起来的战略纵深，才是公有云更为可怕的地方，稍后说明。
网络析构
目前来看，SASE 有两条相对明确的演进路径：
1）网络主场从 SD-WAN 开始演进；2）安全主场从 SSE 开始演进 [3]，最后趋于统一。
2021 年安全主场的 SASE 演进比较抢眼，网络公司有点落后了。那我们网络主场该怎么办？在想任何办法之前，先把网络析构一番。网络是什么？似乎又是一个最熟悉的陌生人，每天都在说但又很难给出定义。抽象的解释：网络是由若干节点和连接这些节点的链路构成，表示诸多对象及其相互联系。这类定义似乎与我们的直接工作有些远，没法直接用。不过稍作分析，可能也还是会有一些启发：
1）网络不是设备（点）；2）网络不是线路（线）；3）网络是连接的组合（面）。
设备和线路构成了连接，连接的逻辑关系构成了网 [4]。那么就还有一个问题值得探究：这个逻辑关系又是什么？在这个语境下，答案已经比较明显：就像画图一样，任何一笔线条都不是孤立的、瞎画的，它反映的是造物主的意志，也就是客户场景化的业务诉求。这个推导决定了网络产品会有一些看似矛盾的特点：
1）很重要：如果没有一张网去表达逻辑关系，各生产要素就没法交互，也就没法支撑任何业务。
2）很透明：客户的焦点至始至终没在网络，而在于其想表达的逻辑关系。客户不会去考虑每画一笔意味着什么，这对他而言完全是两个抽象维度的事。在客户的抽象维度里，默认的是每一笔线条可以按他需要的方式工作，他只会在这根线条不工作时表现出惊讶和愤怒 —— 所以，网络的高光时刻基本都是背锅时刻，也就不难理解了。
更加直白一些：做设备不是做网络，做线路不是做网络，网络是业务场景在另一个维度的抽象，它在本质上反倒更接近于服务，而且最好是一种内生服务。所以如果要真正做好网络，还是必须要往懂得自己的产品组合（包括那些不是网络的产品），懂得客户的业务场景去靠，即客户想要表达一种怎样的逻辑关系，他为什么要表达这样的逻辑关系，我能否组合出他要的这种逻辑关系，我有没有更好的逻辑关系。
云网络的崛起
析构完网络，接下来就可以导出三类以网络为大本营的玩家：云厂商、运营商、设备商。以下逐个分析。
首先是云厂商，让我们回到云服务的定义：云服务是指通过互联网按需向客户提供的广泛服务，这些服务旨在提供简便、经济实惠的应用程序和资源访问，而不需要自购基础设施或硬件 [5]。这里，至少蕴含了两层含义：
第一层含义，公有云是网络领域最大的伙伴和/或对手。为了理解这个论断，让我们先来思考一个问题：如何突破已经成型的网络效应？
上图是网络效应的示意图：当网络效应成型时，对于存量玩家而言，为新用户提供服务的边际成本极低，获取边际收益的机会极多；对应到现实生活，就是早期安装电话需要大笔安装费，后期安装电话几乎免费。在这种竞争格局下，新进玩家可以如何突破市场？
公有云正在给出一个答案。如上图，电话时代的网络，点是电话机和交换局，属于运营商；而公有云是随着互联网生长起来的，互联网时代当然也肥了运营商，但它在网络领域，给出了另外一个效应：网络中的点变了 —— 智能终端和应用服务，取代了电话机和交换局。
公有云成功占领了应用服务（外加他们大多是互联网厂商，还占领了大量的智能终端），既然点被拔除了，线的归属自然也变了，既然线的归属变了，网（面）的归属当然也跟着变了。这里说的归属是指逻辑归属，物理归属可能还是属于运营商，也就出现了运营商所痛恨的哑管道（dump pipe）这个词。所以：
- 电话时代的网络属于运营商，互联网时代的网络在一定程度上属于云厂商，这是对他们各自抓住时代机遇的褒奖，与我们乐意与否、屁股在哪无关。
- 网络业务已经可以大致分成两大类，一类是运营商市场为主的底层承载网，它们是包括骨干网在内的基础网络，承载着国计民生；另一类是企业市场为主的应用网，以租用和 overlay 结合为主，承载着直接业务，强调灵活与弹性，云化的特征越来越明显。
第二层含义，网络再次成为了一种既重要又透明的存在：网络（互联网）明明是获取云服务的前提，但在早期，它并不掌握在云厂商手里，需要低调，只见云计算产品（例如ECS等计算服务）和云存储产品（例如百度网盘等存储服务），从未听过独立的云网络产品（独立产品是指可以独立使用，VPC无法独立使用），“明明是三个人的电影，我却始终不能有姓名”。不过，这种局面可能正被打破。
从幕后走向台前，逐渐显性的云网络
网络是云服务的根基，躲在公有云其它产品幕后发育，看上去其动机是在自保防御，没想和运营商做直接竞争。然而，随着时间的累积，幕布慢慢被拉起，情况有些不同 [6]：
- 公有云积累了海量用户 —— 你总不能限制它发展业务吧，所以这个动作是天然无罪的；
- 云机房间的骨干网络逐具规模，原先它主要在解决云间互联问题 —— 你总不能限制它改善业务吧，所以这个动作也是天然无罪的；
- 后来全球加速（GA）之类产品也来了，虽然运营商的那条线，又被分流了一部分，但运营商还是得忍着，毕竟自己以前没有 GA 这类产品 —— 你总不能限制它创新业务吧，所以这个动作也是天然无罪的；
- 公有云又在通过机房下沉逐步改善接入问题 —— 你总不能限制它拥抱边缘吧，所以这个动作也是天然无罪的。
每个动作都是那么自然，结果就出现了一个自然的逻辑：如果用户数足够多了，接入资源足够丰富了，骨干网络足够强大了，那么还有什么理由不推纯网络服务呢？墨菲定律生效了，在 2021 年的 re:Invent 大会，AWS 推出了 SiteLink 服务 [7]。这是一个什么样的服务：
- 以前（左下图）：AWS 在推它的 Direct Connect 服务，即云专线时，在全球积累了几百个 POP，用于将客户侧的数据中心或者企业站点就近接入到 AWS 的云上 VPC，以构建混合云方案。这是一个被大量使用的基础服务。
- 现在（右下图）：客户在那了，资源也在那了，闲着也是闲着，不如变变现，以后对那些不上云的客户，我也提供一些“力所能及”的服务吧。举个例子，如果某企业在纽约、东京、巴黎都有站点，需要企业组网，以往需要找运营商，现在找 AWS 也是可以的 —— AWS 不再要求该企业必须用 AWS 的云上资源也会为其服务。
解除这个限制看上去没啥，但却可能是具有里程碑意义的：以往公有云的资源，至少在名义上，还是在围绕云上的计算或存储服务来构建的，SiteLink 可能是真正意义上的第一个露出獠牙的纯云网络服务。
云网络崛起的启示
以上，不难看出，云网络的崛起，可能不是云厂商刻意为之，而是随着云服务发育起来的，但客观结果就是公有云突破了运营商的网络效应，其中一个很大的启示：强大且持续的技术投入已是云服务的必须 [8]。
客户为什么要买公有云的带宽？因为客户的应用在云上。为什么客户的应用在云上而不在运营商的机房？因为云上的资源可以按需选择、随时开通、按量计费、比较灵活、更为合身。有趣的是，如果你足够理性，云上的资源其实是：买来了一堆服务器，又做了一层虚拟化，不但将部分可用于售卖的资源用于了管理，还投入了更多的研发成本，理论上成本不是会更高吗？的确如此，总成本是更高了，但技术的价值在于可以将资源切得更碎，以更低的成本地服务更多的用户，包括以前难以服务的中长尾 —— 他们可能不是利润主力，但一定是利润的发源地；更为重要的是，这笔技术投入让原本冷冰冰的设备不再是简单的资源堆叠，而是拥有了空前的自动化能力，能支撑起前所未有的服务品类丰度。这些都需要强大且持续的技术投入，都不是传统运营商所擅长的。眼睁睁看着自己原本积累了大量客户，原本自己有更大机会去服务这些客户的 IT 系统，但客户慢慢都跑到了公有云那边；要是纯 IT 系统跑了就算了，让人更为难受的是，客户的 IT 资源跑了，意味着应用也搬走了；客户的应用搬走了，意味着网络也要跟着搬走了；而当网络都在发生搬迁时，就要足够警惕了 —— 网络效应是个自然规律，很难破除，相信运营商比谁都要了解。
云服务对于设备商的启示
一个有点意外的故事
再到设备商，设备商的技术能力其实不弱，为什么在和云厂商竞争时，也感不适。让我们从一个有点好笑的故事开始 [9]，毕竟故事读起来最轻松。公有云刚开始萌芽时，设备商应该也是没做好准备的，毕竟谁也没见过云计算到底长啥样，能不能行得通。他俩最早的接触应该是在云机房内部，如图所示，云机房内的东西向流量占了绝对的主流，这对当时的设备商而言是个新情况。
此时，大概率是两相看不对眼。设备商可能在想，你这是什么奇葩需求，不知道能蹦跶多久；云厂商可能在想，你这是什么奇葩疙瘩，怎么这么不好使。不过，不好使也得忍着，因为当下找不到更好的替代了。设备商也抓紧时间喘息，纷纷成立互联网业务部，或者开设新的产品规格。此时设备商大概率是高兴的：相互之间卷了这么久，终于迎来大增量了。可以趁着云这一波，开辟新的市场空间。然而，话分两头，在另一边，经过这么久的接触，云厂商应该也是摸清了设备商的“德性”了 —— 他们把那个铁疙瘩看得比什么都重，近乎痴迷。他们可能也尝试着“拆解”一下这个铁疙瘩，结果还真发现，卧槽，这铁疙瘩还真特么挺复杂，但是，但是，但是，此处值得三个但是，很多复杂的东西跟我的业务毫无关系啊，我用了你不到你 20% 的功能，让我掏 100% 的钱也就算了，但每次让你改点东西还要让我等那么久，我是真没兴趣听你唠叨那么多陈年旧事啊。
时间也正好到了波澜壮阔的 SDN 时代，轰轰烈烈的讨伐浪潮开始了，这里既有法国大革命式的革命派，也有英国光荣革命式的改良派。总之，脚趾头都能想到，云厂商当然是义无反顾地加入到了革命阵营中，设备商原先想的好事就泡汤了一大半：公有云的生意不好做，而且他们还不停砸场子。譬如，这类有点打脸的大网红 XGW 也相继被推出来高调宣传了 [10]。
要是只砸几款设备的场子也就算了，大不了少做你的一些生意呗。更过分的是，各种各样的“反设备商联盟”被挑头成立，譬如越来越壮大的 SONiC 生态 [11]，这类“邪教”，有点星火燎原之势，层出不穷。
SDN 爆发时，你嚷着要白盒交换机；SD-WAN 热门时，你嚷着要白盒网关；SD-Branch 起风时，你嚷着要更为下沉的自研 AP [12]。小伙子啊，你这哪里为的是自给自足啊，完全是在釜底抽薪，断人食路啊。
一个有点启示的故事
回到本节问题：云服务之于设备商的威胁和机会。这个问题很难说清，倒是更有兴趣说一个可能有点启示的故事。因为，厂商多年厮杀，互相干不掉对方，三足鼎立的僵持局面，历史上不是没有过。打破僵持局面的，不是其中某个厂商忽然崛起，而是随着一个带着“服务思维”的新玩家进入，市场格局彻底崩塌 [13]。2000 年初的杀毒软件市场，国内主要玩家是瑞星，江明和金山，经过多年厮杀，三方僵持不下。2008 年，360 开始进军这个“古老的”市场。360 进入市场之后，开始免费送了，不是免费试用，而是永久免费。这一招够狠，免费的总比收费的要更讨人喜欢，于是一夜之间稀里哗啦，整个杀毒软件市场大崩盘。大家纷纷装上了免费的杀毒软件，再也没人想着花钱买了。
360 为什么要这么干？铁定不是因为受到雷锋感召，而是周鸿祎是妥妥的互联网背景，采用了梁宁所说的三级火箭模式：当免费的 360 杀毒装进千家万户以后，360 又迅速的推出了 360 安全浏览器、360 安全网址导航等产品。接着，通过 360 安全浏览器，网址导航，以及 360 安全卫士的软件分发平台，360 从企业侧获得了广告推广等收入，完成了整个商业闭环。你可以说，生态被破坏了，或者小流氓被大流氓收拾了，但结果确实是：免费的 60 分要比收费的 90 分，更加讨人欢喜。嘴上的口阀，与双脚的投票，常常是不一致的，这也正是市场的魅力。感性不重要，生存才是王道。
总结来说，三级火箭模式的大意如下：第一级火箭，是高频的头部流量；第二级火箭，是沉淀某类用户的商业场景；第三级火箭，是高利润的商业变现。
所以，三级火箭模式的本质，是通过高频的应用去聚拢业务，从而再在相对低频的场景下去实现变现。更加值得堤防的是，三级火箭模式对于一级火箭的领头羊来说，是一种非常残酷的竞争模式。在杀毒软件市场，360 一进来就以免费的方式进行清场，原先的三巨头瑞星、江民和金山只能一脸懵逼，不知道怎么应对了 —— 毕竟自己赚钱的地方，对方根本就没想和你比赚钱。更加撩拨情感的是，对手抢走的流量，是作为其一级火箭的燃料白白烧掉的，即，毁灭一个行业成就自己。
三级火箭与服务丰度
深究起来，三级火箭更像是个形象的总结比喻，也非全新打法，如果新设计云服务，可以从中得到哪些启示。
- 三级火箭是一种特定领域的总体战模式，一种通过战略机制来调度一切可用资源来进行的灭国级战争模式，可能会让习惯各守一方相对偏封闭的设备商趋于被动。再详细一些，设备商的主力市场，是整个人类社会的基础设施，还不至于像一款杀毒软件那样浮于表面 —— 现在哪怕出现一个新玩家说要给运营商送网元，运营商也未必敢用。但这不妨碍三级火箭理论会让设备商在企业市场趋于被动，因为设备商的焦点还在设备，这的确是一个新玩家很难甚至不可能在短期内超越的领域，犹如马奇诺防线，但三级火箭模式它不会强攻，而是针对具体的战略目的绕了过去。它有多大的可能绕过去？取决于他构建起的集团军的组合度，即服务的丰度 —— 例如，当对手的服务组合，占了整个客户解决方案的 90% 时，固守设备一侧可能就会相当被动了。变，得涉足自己并不擅长的领域；不变，哪怕不被替换，也会比管道化还管道化，这也是为什么之前说云服务的丰度是个更为可怕的东西。云服务本质上都在想着怎么往更为接近客户场景的方向走，虽然设备商有着大量的技术积累，但当前更多的是功能的堆叠，离场景化的协同还有着一定距离。再往上，至少需要去了解资源，了解服务，这些都不在学习区（纯技术区），而更像是两个极端：要么是恐慌区，要么是鄙视链。
- 设备商的思维习惯是直的，互联网的思维习惯是弯的。面对一个问题，设备商更倾向于去强攻解决问题，相对不太会迂回，这可能是长期和硬件打交道养成的致胜经验。无所谓对错，一切都是在各自环境的进化选择。所以，在面临新情况需要相互借鉴时，得放得下身段去借鉴。毕竟，放下身段又不是放下信仰，给自己设了太多条条框框去战场，得问问对手会不会守着那些条条框框来和你对线。
- 可能还会有一个更加深层次的 —— 因为上一条原因，设备商更为擅长的其实是管理效率，这非常有利于大兵团攻坚战，而乔帮主当时也留了另一句：需要提升运营效率而非管理效率。这句话用在这里可能会有些片面，因为任何公司都存在运营而不是说只有云服务才存在运营，这里想表达意思是，在创新领域，大兵团作战的难度要远远超过小团队突围的难度 [14]。这不禁让人想起《创新者的窘境》中总结的领先企业走向衰落的五大因素： 1）现有客户控制了企业资源分配的模式，导致企业难以主动去做一些新的突破； 2）一些新兴出现的小市场，无法解决大企业的增长需求，导致错失； 3）新技术的最终用户和应用领域无法预知，失败往往是通往成功的必经之路； 4）组织为维护现有模式的核心能力，既定流程和价值观，无法应对市场的破坏性变化； 5）不满足主流市场的新技术，被舍弃后，结果在新兴市场大放异彩。它警醒我们的似乎是类似的逻辑。
这个时代已经不是你努力工作，努力不犯错就可以活下来。技术没变，生意没变，但模式变了，用户的体验就会随之改变，用户的体验变了，用户的选择也就会随之改变。这种无声无息的变化，往往使你猝不及防。
从网络演进到数字化转型
最后，让我们回到最初的问题：网络演进该怎么办。发现标题中“数字化转型”这个词太大了，有点吓人，所以先把它的逼格拉下来。
可以认为此处说的数字化转型，是个三方面的过程：
- 数字化：通过对人、物、环境、过程等对象进行数字化，产生数据。根据 IDC 的预测，到 2023 年，会有 70% 的企业需要处理物联网数据；到 2024 年，会有 380 亿物联网设备在数字化这个世界。
- 智能化：以数据为生产要素，通过 AI/ML 为各个垂直行业创造经济价值和社会价值，这也正是数字化的最终目标。
- 网络化：数字化和智能化之间，存在着结构性矛盾。绝大部分的数字化，发生在广袤的边缘；而绝大多数的算力，又集中在计算中心。所以，需要通过网络化，实现数据和算力的匹配流动。
网络必然有用，但想要有大用，得有大场景，以上就是一个足够大的场景。现场的感知器和执行器会越来越多，越来越趋于边缘，甚至会将数据源散布在全球；活跃在现场及近场的智能设备和机器人也会越来越多，为它们提供实时智能及回源处理的边缘算力也得越来越多；在云侧，混合云多云的趋势已然确立，而非单云捆绑；员工越来越机动，尤其是疫情更是加速改变了整个社会对工作场所的认知；伙伴的数量、地域及接入方式也会越来越多元，如此等等。要将这么多散布各地的突破了传统安全边界的生产要素系统地连接起来，达到以机器通信为主的网络性能，这不是一般的企业 IT 可以轻松搞定的，甚至不是几家供应商可以轻松搞定的。所以，将这类数字化转型的云网安平台，以云服务的方式赋能企业，支撑其完成下一次产业革命，有着巨大的社会价值。
现实中，鲜见阴谋，多为阳谋。更何况想要打破网络效应，不是一件想谋就能谋的事，需要时代级的机遇才行。云网络的崛起，并非几家厂商的主观意志，而是以信息技术为核心的第三次产业革命的客观趋势。有幸不知不觉经历了这段历史，最近的下一个时代级的变数，可能就在于以智能为核心的新的产业革命。它必定会到来，只是时间问题，其间需要的能力整合，必定更为综合复杂，各类零散的资源、系统和服务，需要摸索着成为整体方案中的一部分，而不是各自为战做一堆大而全但没人用的玩具。诚挚欢迎同行交流探讨，谋合作，共进步。
参考资料（下拉查看更多）
[1] SASE服务含义析构
[2]https://cloud.google.com/blog/products/infrastructure/new-apricot-subsea-cable-brings-more-connectivity-to-asia
[3] What Is SSE, https://www.paloaltonetworks.com/cyberpedia/what-is-security-service-edge-sse
[4] 最熟悉的陌生人：从业者视角回看网
[5] https://www.citrix.com/solutions/digital-workspace/what-is-a-cloud-service.html
[6] 从服务到云服务，网络做了些什么
[7] https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-direct-connect-sitelink/
[8] 二道贩子怎么卖带宽：云服务之于运营商
[9] 二道贩子怎么卖铁：云服务之于设备商
[10] https://developer.aliyun.com/article/780471
[11] https://www.sdnlab.com/24392.html
[12] https://www.sdnlab.com/25518.html
[13] https://cloud.tencent.com/developer/article/1428973
[14] https://www.jiemian.com/article/4950289.html
