超融合？云网融合？关于融合的一些思考

作者： 扎波特的网线钳 2021-06-10 20:17:04

云计算

超融合 Business Convergence 通常是在很多MBA课程里面都会谈到的一个话题，也就是我们常说的数字化转型，利用信息技术将企业研发设计、生产制造、经营管理、市场营销、风险控制等各个业务条线进行融合。

[[405083]]

本文转载自微信公众号「zartbot」，作者扎波特的网线钳。转载本文请联系zartbot公众号。

似乎到处都在谈融合，前几年超融合、如今云网融合，却没有从最根本的地方去思考什么是融合.

昨天看到一页ppt虽然在讲其它的融合，但是这个总结非常好：

接下来我们将从这几个话题中逐渐展开来谈谈数字化转型中的融合应该怎么做. 整个的融合必定是自顶而下的，以业务为中心的视角。

业务融合

Business Convergence 通常是在很多MBA课程里面都会谈到的一个话题，也就是我们常说的数字化转型，利用信息技术将企业研发设计、生产制造、经营管理、市场营销、风险控制等各个业务条线进行融合。比较有代表性的是一些新型的供应链管理、网络营销、数字化风控等系统的出现。

服务融合

然后就是从业务融合出发，需要提供一套可行的服务架构支撑业务条线，也就是我们看到的中台架构出现的原因，本质是中台的出现是业务的需求，但是中台是否合理，其实反过来是从业务上看是否需要服务融合，因此很多企业大中台发展了很多年却成了整个企业发展的瓶颈，这就是很多管理者盲目中台赋能导致的。当然从技术上也有这样的趋势，微服务的出现，Service-Mesh的架构，本质上都是服务融合产生的结果。

基础设施融合

紧接着就是基础设施的融合，从SDN到超融合所谓的SD-Storage，到最近IaC(Infra as Code)，然后演进到Software-Defined infrastructure. 但这一点上却出现了一个巨大的鸿沟，服务器(计算或者应用)和网络的融合，超融合的成功本来可以理解为计算和存储都发生在服务器上，是一个团队内部的事情。而网络和服务器的融合则是一个非常痛苦的过程，很多做智能网卡、DPU的公司销售额并不好，而有智能网卡的云也在面临着各种内卷.业务融合需求、服务融合需求都很好的契合了，但是也能让MPLS这样的老司机快翻车了…问题在哪?

ACI的成功在于TOR Overlay很好的找到了一个主机和网络的分割点。而HostOverlay以后，智能网卡的控制权归谁?云上VPC的控制权归谁?这就是组织架构上带来的问题，更加加剧了网络和应用两个团队中间的矛盾，甚至开始互相对立起来。例如网络团队需要在云上构建NFV部署SDWAN时，网络团队通常需要向计算团队申请资源，毕竟云上的账号和计费归计算团队，因此计算的团队通常会选择云提供的SDWAN方案，而网络的团队则会选择和私有云网络架构同构的解决方案。多云互联出现问题时，计算团队又需要网络团队协助，相互之间的矛盾逐渐多起来，特别是遇到事故时的相互指责也会多起来。

其实本质上就是在管理域上现有的智能网卡、SDWAN方案并没有提供一个很好的分界点来使两个团队融合，或者构建第三个桥梁团队的可能性。

而这些问题就需要在协议上进行融合了。

协议融合

两个团队的融合通常来自于相互间的协议和接口的标准化。JSON、gRPC这一系列的协议在应用层完成了很好的API整合，但是网络呢?虽然也有yang/netconf Openflow这些东西，最终SDX还是没有很好的和应用融合。本质上网络的团队都在3层以下思考问题，应用的团队都在7层以上思考问题。各自都有各自的Domain Specific Language，让应用写P4写BGP的TLV扩展，让做网络的去写C去搞Service-Mesh，这些都属于某种Scale-up的做法，但是否存在一种Scale-out的做法呢?这就是协议的融合，也就是我说的，各自退一步在Layer-4上构建传输网络。

最典型的就是现在大火的各种猪食和在线会议业务，通常应用会组建自己的团队来做RTN和CDN，这就是演变的趋势，管理上逐渐会产生一个小规模的以应用为中心的SecOps和NetOps小团队去配合应用的DevOps，这样的一个小团队便是应用和网络的融合点，但是同时这样的团队需要一个抓手，那么就是相应的协议栈上需要给他们进行赋能。

目标自然就定在了传输层上，各个云都在成立所谓的高性能网络的部门，但是从未有人想过这个上层需求背后是需要一个更加独立的团队来做，而传输协议上是Swift? 是NDP? 是HPCC? 是RoCE?是QUIC?还是SRv6? 这些对于应用而言，我TM只懂怎么调用Socket啊…

所以一切的事情只能发生在Socket上, 这也是我在设计Ruta时优先考虑到的问题，如果控制面用BGP,网络资源无法抽象暴露给应用，并以应用友好的方式调度，因此控制面迁就应用的熟悉度采用了ETCD。另一方面是数据面上，让应用知道除了默认网关以外，也可以通过在payload中加入一些Socket数组(也就是Segment List)的方式来构建，让应用迁就网络做出一些改变去计算路径和控制流量，学习Segment Routing。

但是同时网络也需要考虑应用的视角，尽量能够以应用可理解的方式进行编码，而不是复杂的uSID、gSID编码方式。

软硬件融合

最后一步也是基础设施融合的关键，毕竟Software Defined Infra的核心迟早会触及到软硬件融合。P4能够在业界获得一系列关注到最后Barefoot成功上岸的原因就是，P4本质上是一个介于Verilog和C之间的一个DSL. 也是在软件和硬件之间取得一个很好的平衡点。但是问题也来了，你见过哪个搞应用的会去签了NDA才能用gcc?活生生的把自己作死吧…

吐槽归吐槽，但是可编程硬件本身的需求还是会越来越大，不一定是FPGA，也不一定是P4 MAU，有很多的解法，最终还是要考虑到一个同构的问题，在边缘和云如何实现底层本的同构，这才是融合的关键。