上海数讯CIO钱誉
在2011年以后，整个数据中心行业越来越像房地产了，数据中心这种业务可复制性比较强，竞争激烈。
到2013年的时候，有一些新的技术出来，包括OpenStack的爆发式增长，于是2014年开始决定去做云计算这个事情。
所以从使用者来看的话，是一件非常痛苦的事情，当时我们就决定把两个平台统一，在Web上做一个完整的、基于用户自己界面的平台。
我们发现一个问题，K8s不是一个PaaS平台，只是解决了一个docker管理的问题。
如果是小环境的话，用不用都无所谓，不一定非要搞SDN，包括OpenStack也一样，如果业务环境不是过于复杂的话，其实跑传统的VLAN，只要控制量，没有广播风暴，没有任何问题。
一旦出现业务迁移或trouble shooting的时候，后端运维人员是崩溃的，没法调。
以前写个PBR，写个静态路由，最多是挂几个交换机路由。
在云网络环境里完全不是这样，可能一个租户下面无数虚拟机，里面跑了无数不同的应用方式，所有流的走向又是乱七八糟的，这种情况下，如果用传统的方式，基本就不用做了，因为看不到头。
所以要采用SDN的方式。
也不是说Openflow不行，用流表的方式也能做，但那就比较折腾了。
当时2015年OpenContrail时代的时候，K8s刚开放，我们提出要采用基于容器的方式，因为虚拟机的方式对运维、扩容、迁移有弊端的话，后面业务是很难有保证的。
那个时候OpenStack也比较早期，基本上都是自己统一部署，和Juniper networks联合开发的时候，把OpenContrail放在一起部署。
在云计算中我们已经使用了SDN技术，非传统VLAN的方式，那么用户上云的时候怎么接呢，不可能再开个VLAN做个什么映射，比较困难。
包括OpenStack和OpenShift，开源社区的版本都是单节点，到真正地应用到场景的话，最起码要保证多节点，社区版的东西要落到生产环境，包括和TF对接，还是有很多二次开发要做。
为什么虚拟机要去访问容器？
在我们看来极其不合理，但在金融行业或电商行业，某些业务可以跑虚拟机，某些已经买了商业软件，或者有些用户自己有开发能力，已经把一部分东西放到容器里了。
我们最后试错下来，在最近解决了VNF和CNF在OpenStack虚拟机层面的互通问题，要用到管理网去做互通。
到现在5.1版本的时候，整个Portal也没有把这个拉出来作为一个选项，每次都要去翻虚拟机和容器去做对应，这个操作比较麻烦，我们也试过做二次开发，比较累。
如果有可能的话，把这两个东西放在一起，管理起来就会非常方便。
大部分用户场景里，都是用商业软件，各种品牌都有，自己本身提供image，放到虚拟机都有自己的feature，怎么和TF互通，肯定是要做二次开发的，但目前看来也就TF有可能去做，其它的比较困难。
至于你要管到公有云的虚拟机，好像不太可能。
即使是给到你，可能最后也会放弃，光是版本迭代问题就没法解决。
没人做这样的事情。
好处是有Portal，能够看到整个业务的实际情况。
OpenShift开源的OKD本身就有一些问题，另外只是把TF和OpenShift或K8s装在一起，简单应用看不出问题，但如果跑几个业务链，比如标签、应用、路由网关、业务编排等，整个流程走下去会有问题。
所以，要使用DPDK方式的话，还是要根据自己的使用场景去看一下。
进入CMP的时代，如果一个应用场景在15分钟内开不起来的话，那它就失败了，更不要说借助第三方外力。
把很多权限都开放给用户。
选择TF是因为协议相对标准，BGP VPN就能解决，我比较抵触私有协议，某些友商总想搞个大一统，最后也不太可能，还是开放式大家比较能接受。
另外，TF在OpenStack和OpenShift认证机制上不太一致。
做云计算不是开虚拟机，用不用OpenStack无所谓，KVM就解决了。
所以说云计算不是虚拟化，它有一定的业务逻辑在里面，意味着平台要能对实际落地用户的业务提供很多支持。
我相信如果有自己的业务逻辑，有一定的开发能力，基于TF能打造出属于自己的好的产品，TF可编程型比较强，通用性也比较强。
满分100的话，我打80分，剩下的20分是支持方面。
MORE
更多TF Meetup演讲实录
多云互联的现实困境与开源SDN之路丨首场TF Meetup演讲实录
关注微信：TF中文社区
Tungsten Fabric技术群招募中
欢
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/198275.html