软件定义网络（SDN）的复杂度让人望而却步

OpenFlow和软件定义网络（SDN）背后的基本理念是：只要SDN友好型交换机出现，控制器和应用环境将“
8084.html">蓬勃发展”。但除了SDN友好型交换机外，SDN还有更大的障碍需要克服---
复杂性。具有讽刺意味的是，SDN的目标之一是通过解耦
控制面板，将其决策集中到控制器来简化网络管理的复杂性。这意味着，
例如，统一的政策可以被推广到各网络设备组。F5博客博主Lori MacVittie本周在其博客中指出，SDN其他主要目标是实现网络可编程性，而这从来都不是简单的事情。通过SDN可编程性，工程师可以在一个底层物理基础设施上加速多个虚拟网络，
然后使用SDN控制器来分别为每个网段实现QoS（服务质量）。这将为虚拟化和云网络带来更大的灵活性。然而，正如MacVittie所指出的，这需要大量代码，非常复杂。她写道：“很多人都明白更高的复杂性意味着更高的风险。这不仅是
对大量代码涌入数据中心架构的直观认识，而且已经得到研究证明。”在我们等待SDN友好型交换机面世的同时，Big Switch等公司正在使用网络覆盖技术让工程师通过网络隧道（tunnelling）在任何底层物理基础设施上建立SDN。这意味着用户不需要再等待交换机供应商的OpenFlow交换机创建SDN。而且这也意味着网络工程师将需要管理多个网络，包括物理基础设施以及每个建立在物理基础设施上的SDN，而不再是管理一个网络。在对Big Switch网络覆盖应用程序的报告中，SearchNetworking的新闻主任Shamus McGillicuddy向Big Switch创始人之一Kyle Forster
提出了一个关键问题：“管理两个网络带来的麻烦值得吗？”Forster回答说：“这取决于企业必须支持的虚拟机的数量。换句话说，如果企业对虚拟网络有足够的需要，这种复杂性是值得的。”Forster的回答也说明了SDN的现状。为了引入可编程性，使用复杂的且可能让网络不稳定的代码值得吗？这完全取决于企业对这种可编程性的需要程度。对于
云供应商而言，他们非常迫切地需要用于互联数据中心的可编程的虚拟网络。而对于典型的企业数据中心，情况并不是这样。但这并不意味着企业不想使用SDN，他们在想办法用SDN来管理网络部件（例如校园局域网的入侵防御）。通过那些方法，SDN
的确可以简化管理工作。但随着时间的推移，创业公司和传统网络供应商势必要解决SDN和网络虚拟化相关的代码复杂性问题。