SDN落地的障碍

　　硬件SDN的落地进展并不顺利。虽然现在慢慢有了一些更多的案例，但是离规模部署还很远。我跟Gartner的曾绍清一起探讨过原因，曾说Gartner经过调查，形成了一些他们的看法。

　　Gartner的观点认为，以下几个问题阻碍了SDN的落地：

　　●厂商的直接支持而欠缺传统渠道的支持

　　●SDN的革命性变革而使销售难度大增，传统厂商偏向销售Ethernet Fabric等容易接受的产品

　　●SDN的用户价值较难从单一产品成本分析中体现

　　●用户的开发团队开发的东西，运维团队不接受

　　我个人觉得Gartner的观点都很有道理，相对来说看得比较宏观。我根据我们的客户交流和项目实践中碰到过的一些问题，也谈谈我的看法。我的观点其实跟Gartner有不少相通之处，算是一枚硬币的两个面。我认为一个用户要想把SDN在他的网络中落地，必须同时满足这三个条件，缺一不可。而现实中，这三个条件同时满足的不多，这也导致了SDN的落地缓慢。

　　●用户必须清楚地知道自己网络中存在的问题，然后带着这些问题来寻找方案。我经常碰到一些人问我，你帮我看看SDN能用在我们网络中什么地方?这种用户是没办法让SDN落地的。SDN是用来实现用户的业务敏捷性的，不是用来全面替代传统网络的，如果你都不知道自己有什么问题，怎么引入SDN?我碰到的最终能落地的，都是明确知道自己网络中的问题，迫切想找方案来解决的。

　　●用户做决策的人必须要足够有魄力，而且能够协调开发部门(或者第三方开发)和使用部门之间的关系。某互联网大厂告诉我，他们的自研交换机项目之所以能成功，全面在自己的网络中替换商用交换机，就是因为他们的研发和运维都归一个领导管，这个领导要求运维部门必须用自己研发的交换机，有问题也在所不惜。而其它大厂之所以进展不顺，则恰好相反，研发部门和运维部门彼此独立。SDN这里也是如此，如Gartner所言，SDN的革命性变革，必然导致传统运维使用上的不适用，人都有使用自己习惯的东西的惰性，如果没有强制命令来保证运维人员使用新的工作方式，确实会比较难推。盛科就给一个互联网大厂做过一个SDN项目，该项目很顺利地解决了一些核心技术需求，但是反倒是在推到运维那里的时候碰到了障碍。其实那些障碍可大可小，如果严格按照传统运维规则去要求，那就会阻碍重重，但是如果愿意给与新生事物足够的耐心，让它在使用中慢慢完善，那就可以顺利推行下去。这都取决于决策人员的魄力和权责范围。

　　●用户的研发部门或者第三方研发人员必须有足够的研发能力，能够有充分的理性选择合适的技术。整个SDN体系中的核心是什么?是交换机吗?是控制器吗?都不是!核心是应用程序。在SDN中，用户自己或者用户委托的第三方必须有足够的能力去研发上层应用软件，必须知道这些应用软件如何去通过控制器控制交换机。很多人通常会问SDN交换机厂商：你们除了交换机，还有控制器卖吗?我假设我们有，你拿去就能用吗?不能!因为设备商提供的控制器不知道用户要用来做什么应用，所以它实际上提供的只是一些基础API以及实现这些API的内部逻辑，如何用这些API，那是用户或者用户委托的第三方需要去考虑的事情。国外的SDN为什么部署得比国内多?至少我看到的原因之一是，国外有一些独立的第三方的SDN应用提供商，他们有能力架设起最终用户和SDN设备商之间的桥梁，把用户需求和SDN设备以及控制器结合在一起，打包交付给用户。比如前面讲的亚太环通的SDN应用，就是一个第三方软件提供商把盛科SDN交换机、另外一个厂商的SDN光传输设备、开源的控制器加上他们自己的应用程序结合在一起，一起交付给客户。而且他们进行技术选择的时候，非常理性不会刻意地去追求标准，他们追求的是满足客户需求，所以有不少私有化的扩展。盛科推到欧洲、日本、美国去的SDN设备，也都是因为有强有力的第三方合作伙伴或者客户本身有强有力的研发能力。否则SDN交换机只能在实验室玩玩。我也很遗憾地看到过一些反面例子，本来他们或者他们的客户确实有SDN的需求，但是他们自己不愿意或者没有能力去针对控制器做二次开发，也不愿意花钱去请第三方开发，而在没有量的保证的时候，设备商也不愿意去做太多定制开发，最终导致落地受阻。