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