SD-WAN的生前身后名
1 前言
本文是在通篇梳理完 ETSI GS MEC 002 V2.1.1 的基礎(chǔ)上，從邊緣計算來回看SD-WAN：看看SD-WAN可以如何“了卻君王天下事，贏得生前身后名”。
作者孵化過基于SD-WAN的云網(wǎng)產(chǎn)品，有一些基本的行業(yè)背景和產(chǎn)品經(jīng)驗。不過本文的問題偏大，僅憑自身經(jīng)驗還是有點心虛，所以預先做了一些功課，嘗試站在巨人的肩膀上，即在ETSI MEC用例協(xié)議的基礎(chǔ)上，再來“理論學習結(jié)合實際感受”，相對更為踏實一些。
ETSI MEC協(xié)議導讀是個系列，較干較枯燥，不適合平臺風格，如對協(xié)議有興趣，可移步個人公眾號，歡迎相關(guān)同行交流碰撞。
2 前世
2019年，帶頭大哥Gartner官宣SDN社死(見下圖)，悼詞有些悲壯：SDN is Dead; Long Live SDN. 大意是：“SDN掛了，但他的精神永遠活在我們心中，阿門”。
SDN為什么給社死了?悼詞寫得很明白：并不是SDN不好，而是SDN已經(jīng)深入人心了。該用SDN的，都已經(jīng)用上了;用不上SDN的，再跟他們?nèi)リ叮彩菫觚敋ど险颐?mdash;—白費勁。既然接下來沒啥直接的新市場可以去拱拱了，那帶頭大哥再不宣布它社死，豈不是容易被居心叵測的小人利用，坑害無辜的創(chuàng)業(yè)者和投資者繼續(xù)掉坑么。
所以，SDN的社死，并非技術(shù)理念原因，而是產(chǎn)品形態(tài)原因。
離用戶遠：SDN的主要產(chǎn)品形態(tài)是DCI，以及基于DCI的所謂彈性云連接(還有一塊是DCN，不過這塊離普通用戶就更遠了，故略)。這是一種什么樣的產(chǎn)品形態(tài)呢，如果拿自來水管做一下類比，這至少是在市政水管級別：通過SDN改造的市政水管，其底層還是需要依賴挖溝埋管的，革命性的創(chuàng)新在于，通過在市政水管的轉(zhuǎn)接點上加裝支持軟件定義的設(shè)備，就可以快速調(diào)整水流大小和水流走向等。基礎(chǔ)設(shè)施這么一“快”，直接的結(jié)果就是可以支持對管線資源的靈活復用，再往上就可以進一步衍生出諸如保底突發(fā)、95計費、流量包等多種運營層面的新業(yè)務(wù)了。但是，話說回來，它的本質(zhì)還是以干線為主的資源大管道，所以直接用戶主要是大企業(yè)、大運營商之類。所以，有大網(wǎng)資產(chǎn)需要去降本增效的，都已經(jīng)用上SDN了，而且用的還挺爽;那些還沒用上的“貌似客戶”，其實是不太需要，或者說如果有零星需要，可以從已經(jīng)用上SDN的運營商那里租一份來用一用。
離應(yīng)用遠：SDN不但離用戶遠，離應(yīng)用也遠。在大管道上，無論是識別應(yīng)用的粒度，還是操控應(yīng)用的粒度，都有些力不從心。
3 今生
帶頭大哥在官宣SDN社死的同時，鼎力支持SD-WAN再升一級，甚至在2020年，更是讓其跨界到網(wǎng)絡(luò)安全領(lǐng)域，宣稱它是在未來兩年會被采納的高價值領(lǐng)域(high benefit and less than two years to adopt category)，這個評價甚至高于IPS和WAF(moderate benefit and less than two years to adopt category)。
繼承SDN精神的SD-WAN，可以擺脫SDN類產(chǎn)品的機房限制，飛入尋常百姓家，離用戶更近，離應(yīng)用更近。
SD-WAN憑什么比SDN更接近用戶，更接近應(yīng)用?一個直接的答案就在于SD-WAN的CPE。
正是由于CPE的存在，才能讓SD-WAN發(fā)揮出核心優(yōu)勢，至少是PPT上的核心優(yōu)勢。假設(shè)某家企業(yè)在硅谷新設(shè)了辦公室，需要將其接入企業(yè)網(wǎng)。如果該企業(yè)網(wǎng)是基于SD-WAN構(gòu)建的，那么對客戶而言，需要做的就是：在收到CPE之后，上電插線，然后企業(yè)網(wǎng)就建立起來了，就是這么神奇。
在產(chǎn)品界面上，CPE是廠商的關(guān)鍵服務(wù)觸點之一(另一個是自服務(wù)門戶頁面)，所以必須閃耀出ZTP的光芒。
在網(wǎng)絡(luò)運維上，CPE也清晰地標定了責任邊界：CPE往下，客戶負責;CPE往上，供應(yīng)商負責。
警告：以上只是原理，拿SD-WAN做企業(yè)組網(wǎng)，真正要做些什么，請參考 《SD-WAN行業(yè)理解：從廣域網(wǎng)云化看SD-WAN》 第5.1章，此處不再贅述。
4 身后
SD-WAN也不用高興的太早，從以上2019-2020的Gartner兩圖對比中，可以看到帶頭大哥已經(jīng)在給SD-WAN安排身后事了，就是圖中那個迅速崛起的SASE，一下子從Innovation Trigger竄升到Peak of Inflated Expectations。
SASE可以繼續(xù)離用戶更近，離應(yīng)用更近，更貼心，更安全，基本滿足了當下對未來企業(yè)網(wǎng)的所有幻想。
這里直接偷懶，如需了解SD-WAN向SASE的演進邏輯，可以參考：
從廣域網(wǎng)云化推演SASE：面向物聯(lián)網(wǎng)和邊緣計算的SD-WAN演進
5 病灶
年紀輕輕的，早早被安排了身后事，總該是被帶頭大哥看到了一些問題。以下結(jié)合摸爬的經(jīng)驗，來找找可能的病灶。
對于疾病，進化論有個挺有意思的觀點：疾病是生物進化的產(chǎn)物。即，進化只是讓利益和風險在特定的環(huán)境下達到了某種適應(yīng)和平衡。任何一種平衡，都會隨著物種自身的發(fā)展被打破(這么說來有點悲觀)，所以很多疾病的根源，其實正是上一次進化時留下來的優(yōu)勢(比如肥胖和糖尿病)。CPE之于SD-WAN，可能正是如此，它在幫助SD-WAN取代SDN的同時，也成為了一個隱隱發(fā)作的病灶，一些比較典型的問題：
1)選什么盒子?MIPS、ARM、x86?一款還是幾款?
選一款吧，選高了，銷售說價格太離譜，沒法賣;選低了，銷售說我還有好些客戶可是有大帶寬需求的，你還要不要賺錢了。
那就試試選多款吧，好，產(chǎn)品經(jīng)理把硬件成本的帳算清了，那么研發(fā)成本呢?研發(fā)成本真的能估得準嗎?研發(fā)團隊有設(shè)備研發(fā)經(jīng)驗嗎?做企業(yè)級設(shè)備和做互聯(lián)網(wǎng)應(yīng)用的玩法好像還不太一樣吧。另外，銷售聽得懂研發(fā)將會面臨的痛苦嗎?是話術(shù)上的“我懂”還是真的聽得懂?此外，多款選型還會進一步帶來包括采購、庫管、配置等一系列方面的管理成本。
2)一些老牌設(shè)備廠商可能沒有第一個問題(因為本來就是新瓶裝老酒，所以很多時候根本沒得選，哇哈哈)，但第二個問題會相對更加普遍。SD-WAN面向的是2B市場吧，2B市場總要做PoC測試的吧。測試會帶來哪些問題呢?
老牌設(shè)備廠商通過存量和品牌，相對容易占領(lǐng)高端市場，但行業(yè)的頭部企業(yè)畢竟有限，背后的廣義資方，是否甘于局限于高端市場，還是要去試一試中長尾呢?
如果要試一試中長尾，那就會出現(xiàn)大量的測試，這些中長尾大多可是不會接受付費測試的。噩夢就要開始了：寄盒子。庫管部門出貨 -> 交付部門配置 -> 物流部門發(fā)貨 -> 客戶簽收 -> 交付部門約客戶上線 -> 測試保障 -> 算你產(chǎn)品牛逼，50%轉(zhuǎn)商，那50%還是需要聯(lián)系客戶寄回 -> 庫管部門收貨 -> 檢查測試 -> 庫管部門入庫。這還是一個偏簡單的正常流程，還沒涉及一系列的工單流轉(zhuǎn)環(huán)節(jié)，各地倉庫的水位維持，以及一些“常見的意外事件”，例如，客戶在方案階段給的信息有誤。
運營團隊能支撐嗎?市場部門可是已經(jīng)官(吹)宣(牛)了各項服務(wù)的標準時限了。如果能支撐，是能支撐活著，還是能支撐業(yè)務(wù)跨越式增長?
3)SDN時代遺留下的客戶要不要拓展?其中一些其實是涉及到辦公室等場景的。如果要把他們升級到SD-WAN產(chǎn)品，那么以往的通過專線接入的云連接站點等怎么建模，要不要CPE?如果不要CPE吧，網(wǎng)絡(luò)架構(gòu)會有些“不美”;如果要CPE吧，那是要去機房放盒子呢還是買機房資源做虛擬化呢?要買的話誰買?運維界面又是怎么樣的?
以上每個問題的抉擇，都會涉及到具體落地，而一旦落地，又會涉及到是不是會背上越來越重的歷史包袱(總不能說今天支持了，幾個月后就說不干了吧)，有點讓人頭大。
6 機理
繼續(xù)推薦Y模型：如果要解決一個具象化的問題，需要再深挖一層在更基礎(chǔ)的層面去解決它。讓我們從客戶視角切換回廠商視角。
以下是主流SD-WAN產(chǎn)品的典型系統(tǒng)架構(gòu)。
- Subscriber Web Potal：基于Web的自服務(wù)門戶，一般會與供應(yīng)商的BSS/OSS系統(tǒng)打通，形成聯(lián)動。
- Service Orchestrator：編排器，負責將用戶在自服務(wù)門戶上輸入的業(yè)務(wù)意圖，編排成一系列的網(wǎng)絡(luò)服務(wù)。服務(wù)編排器與自服務(wù)門戶之間的接口，就是通常所說的北向接口。
- SD-WAN Controller：控制器，負責將各種網(wǎng)絡(luò)服務(wù)，進一步翻譯成網(wǎng)絡(luò)設(shè)備可懂的設(shè)備語言。控制器與網(wǎng)絡(luò)設(shè)備之間的接口，就是通常所說的南向接口。
- SD-WAN Edge：網(wǎng)絡(luò)邊緣設(shè)備，即俗稱的CPE，執(zhí)行具體網(wǎng)絡(luò)策略的設(shè)備。在有些設(shè)備商的方案中，會有專門的強大一些的CPE，可以放到POP端做局端設(shè)備。
以下是主流SD-WAN產(chǎn)品的典型網(wǎng)絡(luò)架構(gòu)。
- 接入側(cè)：CPE-POP之間的網(wǎng)絡(luò)部分，屬于供應(yīng)商的弱管控范圍，底層承載的質(zhì)量通常不可控。
- 骨干側(cè)：POP-POP之間的網(wǎng)絡(luò)部分，屬于供應(yīng)商的強管控范圍，底層承載的質(zhì)量通常可控(例如Aryaka的全球二層骨干網(wǎng))。當然，理論而言，骨干側(cè)并不是必須的，不過如果考慮的大背景是廣域網(wǎng)云化，有骨干資源的供應(yīng)商，會有極大優(yōu)勢。
- 端到端隧道：CPE-CPE之間的邏輯連接，通常這是overlay隧道?；驹砣缦拢涸谝粚PE之間，基于用戶在自服務(wù)門戶上輸入的業(yè)務(wù)意圖(例如連接兩個分支站點)，通過編排器和控制器的編排翻譯，向目標CPE下發(fā)設(shè)備配置，建立起支撐客戶業(yè)務(wù)意圖的一條條端到端隧道。
直接為客戶提供服務(wù)的，正是這一條條的端到端隧道。所有的花活，也就開始在這上面展開來玩。
最簡單的的花樣：確有一些廠家就是把這條隧道當作SDN業(yè)務(wù)的補充來做的，也就是，本質(zhì)上就是在售賣這一條條端到端隧道;只不過與傳統(tǒng)的SDN業(yè)務(wù)相比，由于接入側(cè)可以不必受限于專線，可以大大縮短交付周期，降低整體成本，至少可以做成應(yīng)急或災(zāi)備。按作者了解，很多人對SD-WAN存在誤解，最容易的誤解，就是把SD-WAN限定到了這個層次。
復雜的花樣，就要取決于各自的技術(shù)功底了，底層支撐的技術(shù)能力越多，可以玩出的花樣就越多，當然前提還是要與目標場景相契合，即與自己的目標市場相接軌。絕對不要去羨慕巨頭設(shè)備商五花八門的功能，更不要去直接抄作業(yè);人家可能正在為自己的肥胖而苦惱，正在尋思著該怎么瘦身呢。
為什么這么說?讓我們再來分析一下以上架構(gòu)中CPE的作用：
- 引流：即把流量送到指定位置，例如最佳的POP點，或者直接到對端的CPE。只要能完成引流，其實就不必局限于某種特定的實現(xiàn)方式。
- 分流：在越接近源頭的地方分流，整網(wǎng)的效率越高，用戶體驗越好;分流的語義越接近應(yīng)用，越準確，就能做更多的高級處理，整網(wǎng)的效率也會越高，用戶體驗也會越好。應(yīng)用識別和應(yīng)用分流這方面，國內(nèi)基本已有龍頭了，第三次推薦Panabit。
- 傳輸安全：即對目標流量進行加密，當前的主流CPE形態(tài)，大多在使用諸如IPSec之類協(xié)議，IPSec天然就支持感興趣流(這名字可起得真好)，所以傳輸安全可以和引流一齊完成，但從功能邏輯上來講，還是需要將他們區(qū)分開的。
- 基礎(chǔ)安全：基礎(chǔ)防火墻等，例如基于五元組的傳統(tǒng)ACL方案。個人覺得直接原因是CPE帶來了一個新的網(wǎng)絡(luò)邊界，所以CPE至少要保證自己不會成為豬隊友。
- 安全能力：指高級安全能力，例如IPS、UTM、NGFW、WAF等等。
- 基礎(chǔ)調(diào)度：例如在不同物理線路、不同隧道之間的優(yōu)先級、QoS和搶占等。個人覺得這主要是因為，與SDN類產(chǎn)品不同，SD-WAN產(chǎn)品本身不強調(diào)underlay的承載，那么在這樣的情況下，怎么去伺候好應(yīng)用呢?那就至少需要在underlay的線路層面，以及overlay的隧道層面，都能去支持去玩點花樣。
- 優(yōu)化能力：包括多徑包復制、FEC，緩存、壓縮、去重、協(xié)議優(yōu)化或代理等，因為不同背景的廠商，劃分出來的基礎(chǔ)能力和高級能力會不大一樣，所以這里干脆放在一類。不過發(fā)現(xiàn)了沒，這些功能已經(jīng)與CDN功能越來越趨同了。
7 處方
然后就可以從病灶到發(fā)病機理到處方了。每個人體質(zhì)不同，癥狀各異，相似又不相同的藥也是多種多樣。所以，談處方時，更為關(guān)鍵的就是處方邏輯，了解處方邏輯之后，各自的藥基本不會相同。所以這一章，只能算藥引，藥需要自己去抓。讓我們再來做一些推導，分析思路如下，僅供參考。
1)首先確認一下是否認可：“SD-WAN的本質(zhì)是廣域網(wǎng)的云化，它的靈魂是應(yīng)用和場景”。如有需要，可以參考：《SD-WAN行業(yè)理解：從廣域網(wǎng)云化看SD-WAN》，此處不再贅述。
2)“應(yīng)用和場景”，天然會有個特點：千差萬別，不能一概而論。如此，就會推導出對產(chǎn)品架構(gòu)的較高要求：產(chǎn)品架構(gòu)需要足夠靈活，需要允許解決方案人員，將“差異化的行業(yè)需求”，用“相對穩(wěn)定的產(chǎn)品”，在“靈活的產(chǎn)品架構(gòu)”的支持下來搭建。寫下這句時，總覺得有些耳熟，再一想，這不正也是5G核心網(wǎng)SBA的演進邏輯么。
3)既然“本質(zhì)是廣域網(wǎng)的云化”，那么很大一方面，是要考慮怎么把產(chǎn)品做出云的客戶價值：敏捷、彈性、按量付費。其中，敏捷在一定程度上，是后兩者的基礎(chǔ)，先聚焦到敏捷。
4)敏捷是云的“客戶價值”，所以要重點關(guān)注產(chǎn)品的服務(wù)觸點。
5)之前提了，SD-WAN類產(chǎn)品的服務(wù)觸點主要有兩個：
- Portal：即自服務(wù)界面。有些客戶是大爺，不會來用portal自服務(wù)，但還是要將portal提供給大爺?shù)墓芗业?此外，此處potal應(yīng)是廣義的，即需要考慮調(diào)用API集成。Potal是基于Web的，天然具備了云的客戶價值，不是瓶頸(不全對，設(shè)備商的視角就容易有問題，不過先略過)。
- CPE：通過以上的「病灶」分析可得，CPE正是個大瓶頸。
6)如此，癥結(jié)可以歸結(jié)為：產(chǎn)品的本質(zhì)要求CPE必須靈活，但在當下主流產(chǎn)品的系統(tǒng)模型里，CPE承擔著太多功能，非常不靈活，是一種令人又愛又恨的存在。CPE又為什么要承擔著如此重負，是因為跟我們選擇的業(yè)務(wù)方向有關(guān)，即受限于業(yè)務(wù)模型。
7)所以，處方就可以歸結(jié)為：理解自己業(yè)務(wù)模型的本質(zhì)，為每個業(yè)務(wù)模型設(shè)計獨立的邏輯CPE功能;如果確有需要支撐多種場景，那就梳理出所有需要支持的業(yè)務(wù)模型，求助架構(gòu)師如何綜合出適合自己的產(chǎn)品架構(gòu)。即，在充分析構(gòu)的基礎(chǔ)上再考慮怎么綜合(另一句潛臺詞是：如果受限于能力綜合不了的，建議暫時先放棄，從自己最能干得成的事開始一件一件干，精瘦地活著好過虛胖著餓死)，畢竟偏統(tǒng)一的通用架構(gòu)，一般都是長出來的;而且當相關(guān)各方世界觀一致時，長出來的架構(gòu)基本都大差不差。
只不過，那個時候，CPE還叫不叫CPE，SD-WAN還叫不叫SD-WAN，都是未知數(shù)。不過，只要能對社會有用，能產(chǎn)生價值，誰還在乎名字呢。
讓我們再來驗證一下。SD-WAN可以分為名義市場和無形市場，之前多在分析名義市場，今天嘗試通過AWS來管中窺全貌。AWS有沒有在做SD-WAN?有，有人會覺得就是“Transit Gateway + 合作伙伴的SD-WAN Edge”。如果再把抽象層面拔高一些，AWS的Lambda@Edge有沒有在用SD-WAN?AWS的Greengrass有沒有在用SD-WAN?AWS的Outposts有沒有在用SD-WAN?AWS的Wavelength有沒有在用SD-WAN?我想，這些產(chǎn)品的整體架構(gòu)，應(yīng)該都是符合以上SD-WAN的典型產(chǎn)品架構(gòu)，以及SD-WAN的典型網(wǎng)絡(luò)架的吧。更加極端的例子是，發(fā)現(xiàn)某家機器人公司，竟然建有一張SD-WAN網(wǎng)絡(luò)，然后把它叫做機器人的神經(jīng)網(wǎng)絡(luò)(Nerve Network)。覺得它們都可以歸結(jié)為隱含市場，只不過它們在各自服務(wù)的獨立場景，是遠遠超過“40-60億美元”這個名義市場的，所以是不屑于說自己在做SD-WAN的。這里還有一個有意思的問題：為什么在大家都做的企業(yè)組網(wǎng)這個方向，AWS的選擇是“Transit Gateway + 合作伙伴的CPE”這條路子?是AWS沒這方面的實力嗎?可拉倒吧，個人覺得這正是AWS產(chǎn)品規(guī)劃的厲害之處，在這一個業(yè)務(wù)方向選擇“Transit Gateway + 合作伙伴的CPE”進行落地的原因，很可能在于：
- 企業(yè)組網(wǎng)這個業(yè)務(wù)方向?qū)?B的云計算而言，是必不可少的，是必須得支持的，所以得做;
- 企業(yè)組網(wǎng)里的Transit Gateway，產(chǎn)品形態(tài)可以符合云的本質(zhì)，并且可以集成到更龐大的云產(chǎn)品體系里去，所以得自己做;
- 企業(yè)組網(wǎng)里的CPE，產(chǎn)品形態(tài)無法符合云的本質(zhì)，也不能納入到更大的云產(chǎn)品體系里去，不符合AWS作為一家云廠商的定位，這部分趕緊外包出去，又剛好有人要排隊進來做這份“苦活”，何樂而不為呢?
所以，如果我們帶著“先析構(gòu)后綜合長架構(gòu)”的思路再去審視一遍CPE的話：
- CPE必須保留的功能也就是引流能力;
- 第二批次的功能是分流、基礎(chǔ)調(diào)度、傳輸安全和基礎(chǔ)安全;
- 最后批次的功能再是優(yōu)化能力和安全能力。
即，極端情況下，除引流能力外，CPE的其它功能都可以按場景選取分配。
即，在產(chǎn)品層面，如果要把產(chǎn)品做輕，做的像云，CPE所承擔的邏輯功能，必須要能做輕。越輕，越無感，業(yè)務(wù)越靈活。
顯然，直接來講，那就是直接在選定應(yīng)用場景，把不需要的功能剝離。這方面，最直接的例子是各個廠家越來越多的App。不過，雖然看上去大家都是App，但不同App在各自的產(chǎn)品架構(gòu)里，扮演的角色可能也并不相同，有些更像是一個接入端，有些都開始重得有點像個物理CPE了。其實這方面怎么做都可以，就是最好真的知道自己在做什么，發(fā)展到下一個階段時可以復用哪些，等等。
另外，那就是反其道而行，往重量級走，把CPE做大做厚實，然后塞到POP里去，通過復用來實現(xiàn)“輕量化”。這種情況下，最基本得引流，就得通過端或者某種特定的方式來完成。
所以，邏輯上的CPE，會被兩頭分拆：
- 往端一頭，例如側(cè)重強管控的SASE端，主要承擔的是引流、傳輸安全、基礎(chǔ)安全能力等。
- 往云一頭，或者說往邊一頭，會轉(zhuǎn)移到在近場/中心的更強大的“帶計算的網(wǎng)絡(luò)設(shè)備”，或者“帶網(wǎng)絡(luò)的計算設(shè)備”，總之是云網(wǎng)融合設(shè)備。在客戶側(cè)盒子大爆炸的大背景下，再塞一個不尷不尬的盒子，可能不是長久之計;這個盒子的形態(tài)演進，應(yīng)該需要符合一個更大的基礎(chǔ)設(shè)施變革邏輯才行。
SASE是SD-WAN的直接身后事，不過目測SASE也是有著名義市場和無形市場的特點的，同樣，大概率也是無形市場可能會更為波瀾壯闊。在通篇梳理完ETSI MEC的用例協(xié)議后，MEC這個方向可能會是一種更大的融合背景。稍后會從MEC用例視角出發(fā)，進一步梳理這個邏輯，回看一下SD-WAN所珍視的技術(shù)積累，諸如分流能力，基礎(chǔ)調(diào)度能力，優(yōu)化能力，可能會被怎樣繼承并發(fā)揚光大，贏得“生前身后名”。
“做SD-WAN”的思路，最好過渡到“用SD-WAN”，即看看需要用到SD-WAN的更大舞臺。
8 藥引
業(yè)務(wù)需求是利潤需求，架構(gòu)需求是支撐需求，絕大部分的創(chuàng)業(yè)公司都沒有太大的戰(zhàn)略縱深。所以，一個理想的藥引，是最好能在存續(xù)現(xiàn)有SD-WAN業(yè)務(wù)的同時，逐步將產(chǎn)品架構(gòu)轉(zhuǎn)型至未來形態(tài)，從而既能在當下養(yǎng)活自己，也能在未來擁有更大可能。
如果順著廣域網(wǎng)云化的邏輯，應(yīng)用加速可能是個更好的切入點。當時更多是在生態(tài)和市場的角度推導的。現(xiàn)在，就在以上分析的基礎(chǔ)上，再從產(chǎn)品的業(yè)務(wù)模型角度，看一看相關(guān)邏輯。
上圖中上下兩半部分，分別對應(yīng)著企業(yè)組網(wǎng)和應(yīng)用加速的極簡業(yè)務(wù)模型。它們有什么區(qū)別：
明面上，客戶可見的業(yè)務(wù)元素變少了：
- 企業(yè)組網(wǎng)：分支站點A，分支站點A CPE，分支站點Z，分支站點Z CPE(必須區(qū)分CPE A、Z的原因是規(guī)格和形態(tài)都可能不同);
- 應(yīng)用加速：分支站點A，分支站點A CPE，應(yīng)用Z。
邏輯上，隱含的業(yè)務(wù)元素縮簡就更多了。企業(yè)組網(wǎng)里的內(nèi)網(wǎng)規(guī)劃、接入模式、連接策略、線路策略，遺留系統(tǒng)支持，等等，在應(yīng)用加速場景里，基本都可以被排除或被低代價地限定掉。
結(jié)果就是，在當前的生態(tài)成熟度和技術(shù)成熟度下，企業(yè)組網(wǎng)因為不可避免會觸及到客戶內(nèi)網(wǎng)，注定了是個非標品，而應(yīng)用加速相對更容易做成標品。標品有什么作用：
- 低切入復雜度：企業(yè)組網(wǎng)只是“聽著”簡單而已，做著可不簡單，會遇到大量的現(xiàn)實問題;標品就更容易去切入，注意是說切入，而不是說就受限于此。
- 全方位的低復制成本(前提是匹配的架構(gòu)支撐)，更接近云的形態(tài)。
落地時，隱去的“分支站點Z CPE”又有什么作用：
- 原先暴露給客戶的選擇題，轉(zhuǎn)變?yōu)榭梢宰约鹤鞔鸬男〕}。
- 更早地實地了解一下POP里的邏輯CPE(如果需要有的話;但這也是符合SASE方向的)，需要滿足什么樣的具體需求，它們與傳統(tǒng)的物理CPE必定是不一樣的。
- 敏捷是更大的主旋律，越在基礎(chǔ)層面做到敏捷，對上層業(yè)務(wù)的潛在促進作用就越大，即，在產(chǎn)品系統(tǒng)層面敏捷方向上的丁點進步，還是有可能會衍生出運營層面更多更大的創(chuàng)新的，這類創(chuàng)新可能需要在系統(tǒng)就緒后，碰撞自SA團隊、BD團隊等。
此外，還有一點是值得稍稍寬心的：如果站在更大的云化背景下，企業(yè)內(nèi)網(wǎng)正在被逐步掏空，即，原先需要組內(nèi)網(wǎng)的內(nèi)容，正在逐步轉(zhuǎn)變?yōu)樾枰患铀俚膬?nèi)容。
所以，應(yīng)用加速，可能是個廣域網(wǎng)云化更好的切入點。
最后，也得承認，可能確實不是所有企業(yè)都適合去做應(yīng)用加速，以上只是作為產(chǎn)品分析的示例。
留道開放題：在應(yīng)用加速方向，能不能進一步做出下圖這樣的業(yè)務(wù)模型呢?它的好處很誘人：客戶不再需要任何CPE，可以極為敏捷。如果可以實現(xiàn)，可能會有哪些限制?企業(yè)組網(wǎng)是否也能適用?
作者簡介：張云鋒，云網(wǎng)融合相關(guān)行業(yè)從業(yè)人員
