再谈”可编程网络”


上周在一个mailer里看到某个客户指定要SONiC,而不用某家的商用操作系统. 然后我顺口跟老板回了一句SONiC是趋势.但是老板给我了一个灵魂拷问: 如果SONiC是趋势,那么商用设备公司的价值在哪…恰逢SDN被判死刑,另一方面可编程网络、开放式系统的价值在哪?一时语塞,过了几天慢慢想明白,所以才准备写出如下的一段文字.

可编程网络的反思

过去写过好几篇关于可编程网络的文章:

  • 中国广域网的演进史
  • “软件定义”的网络世界
  • “网络编程” 还是 “可编程网络”?
  • SRv6/P4/SDWAN都错了:一些看似离经叛道的苦口良药
  • 网络服务化与供给侧改革:退一步海阔天空

正如其中一篇所述,过去十多年的经历深刻的感受到了应用和网络的割裂,应用的开放融合快速发展对应着网络的寡头封闭,特别是在应用完成虚拟化然后容器化云化后,而网络还在NFV上停滞不前。终于有一天,应用开始自己搭网络了,虽然初期很笨重,大量使用Tun/Tap和Iptables,但是各个寡头在被应用侵占的时候,终于意识到这个问题,开始大谈Network as a Service(NaaS)了,也就是国内常说的网络服务化。但在这个过程中还是免不了塞自己的盒子和夹带私货的思想,还同时想继续争夺控制权。现实就是你不得不妥协,在这一场网络供给侧改革中,不是简单的给几个控制器API给应用,而是通盘的考虑如何最大化的给应用服务。

变化带来的价值

现在的互联网应用基本上一个月两三个版本都是常态,而通信行业通常一年三到四个小版本升级。更有趣的是通信人还以那种很老的思路在说:应用很难改的,代码要利旧的,于是就这样僵化的前行着。而通信行业的保守还来自另一个方面,多厂商设备的协同导致标准制定的时候相互的妥协,协议发展长期停滞不前。

正是由于这种原因,对网络可编程的诉求产生了, 先不论一开始的SDN OpenflowODL一类的东西, 本质上只是很多大规模客户厌倦了CLI的各种配置方式和运维难度,希望有一种更直接的操作转发表的机制。只是OF做的太过了,把自己整死了。这也是最近SDN被判死刑的根本原因。

但是对于转发表更加直接的操作上,SONiC很好的做了一个平衡,将控制和转发的解耦做的更加符合应用的口味,使得一些一线大厂可以根据自己的需要去定制一些自己的路由协议或者控制协议,灵活度高于P4和OF,自然接受度也广很多,特别是针对一些转发行为上的bug,这些大型OTT、CSP没有精力去等待商用公司详细的修复测试发布流程,更希望自己的代码解决自己特定的问题快速上线修复。

而从另一方面来讲,想用SONiC这样的系统去替代普通企业网园区网这些场景,似乎又属于想多了。这些才是思科和华为这一类商用企业的赛道,主要是客户的开发能力不强,运维SONiC一类的系统bug修复能力并不够,而且主营业务决定了不可能在网络运维上养一个开发团队,购买商用设备或者MSP外包是一个更好的选择。

所以作为一个架构师选择何种架构一定要根据客户的情况来选择,SONiC当然看上去酷炫,但是就像Linux要去普通的桌面电脑市场还是有很多差距,这也是MAC和Windows存在的价值。就像我前段时间在给某些客户写行情解码的开源软件时,随手可以丢个dpdk的代码出来,毕竟很多时候一个结构体一套parse数据高效很多。但是很多客户的网络运维团队很难接纳这样的代码,毕竟对于很多人搞懂指针都要他们的命的…

还有某个公司用python写了一个某著名路由协议的二进制解码还在某大行商用的,所以不用把搞SDN的这事想的特别专业,从业人员的知识体系决定了技术栈的选择,这也显示出了,网络运维人员的编程能力还跟不上可编程网络的需求

所以已有团队的知识体系结构决定了一方面招不了专业的开发人员,而一方面经济资本决定了没必要去雇佣这样的专业团队,因此只能选择商用系统了。

变化带来的机会

而这些变化,最终会沉淀下来,无论是多么火热的可编程交换机,或者是DPU。本质上它只是计算机整个体系结构上遇到了瓶颈,一方面是冯诺依曼架构带来的内存墙瓶颈, 用缓存续了一次命,用多核再续了一次,接下来不知道怎么办了。另一方面是软件本身逐渐走向Software2.0, 这个图来自于HotChip33

再谈"可编程网络"

更简单的说是我前几年在公司内部给研发介绍ML的时候讲到过的:

再谈"可编程网络"

人的智商已经不足以写出满足人类对生活需求的代码了, 因此才需要通过另外的途径去解决这样的问题。

这些问题都是一代人才有一次的机会,只是谁是最有可能抓住这次机会的人,一切尘埃落定后,可编程的基础架构就再也不需要了…

再谈”可编程网络”》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/228.html