由于混合云和container（容器）技术的出现，数据中心网络架构比以往任何时候都更加难以被攻破。
当然，这个技术再好，还是有法可循，如果我们遵循一种简单的方法，还是可以破解的。
在不太远的过去，数据中心内的流量转发很简单。 一个IP地址与另一个IP地址通话。 这些地址属于端点 - 裸机主机或虚拟机与其他裸机主机或虚拟机通话。 这些IP地址之间的路径是数据中心交换机已知的路由和桥接表中的条目。
如果工程师需要排除两个IP端点之间性能不佳或奇怪的行为，一个好的起点就是通过查看这些表来构建两者之间的路径。 同等成本的多路径和多机架链路聚合增加了此过程的复杂性，但总的来说，运营商可以确定任何给定的数据中心会话遍历的路径。
在端点之间的通信流并没有什么太复杂的。网络地址转换、加密或隧道传播中很少出现。这些功能往往位于数据中心边缘，与受信任外围设备进行通信。
现代数据中心
随着业务需求的变化，现代数据中心的网络架构已经和以前的完全不一样啦。曾经相对简单的数据中心，通讯简单，现在的数据中心可以看做是一个统一基础设施的平台，在这个平台上运行各种应用程序。数据中心作为一个整体运行；它是应用程序交付的引擎。
越来越多的基础设施对开发人员和他们的应用程序是透明的。一个彻底的现代基础设施是开发人员应用程序的抽象。资源池是按需分配的，而开发人员不必担心基础设施。相反，基础设施是有效的。
现代数据中心还以一种分布式的方式处理安全问题，它与动态站立和拆除工作负载相协调。不再需要通过一个中央的物理防火墙来强制执行安全策略。相反，构建一个中央安全策略，一个安全管理器将该策略的相关部分安装到受影响的主机、vm或container中。没有基础设施的选择，也没有晦涩的路由需求来强制执行这样的政策。
在更高的级别，我们在构建私有云架构。同错采用这种抽象物理基础结构的方式，可以与公有云进行更简单的协作。因此，混合云架构越来越受欢迎，人们期望公共云工作负载与私有云工作负载具有相同的安全性和连接性。
层
随着混合云架构成为新的标准，重要的是要注意这些趋势对网络的影响。数据中心不再像一个IP地址那样简单地与另一个IP地址交谈，在遇到麻烦时，需要通过路由和桥的联络，进行协商。
提供现代数据中心灵活性的基础设施机制依赖于复杂的网络。推动这种复杂性的是工作负载隔离、服务策略实施和安全性的需要。因此，与其说数据中心是IP地址的海洋，倒不如更像是一块有层次的蛋糕。
在这块“有层次的蛋糕”底部是底层网络。这个网络是所有其他网络服务的基础。这也是网络工程师最熟悉的网络。当他们查看他们的路由和桥接表时，他们看到的是底层网络——数据中心的基础。
然而，底层本身并不能提供混合云所需的一切。一个日益增长的需求是隔离，被称为多租户。租户可以是应用程序、业务单元或客户。
租户的流量通过虚拟可扩展LAN（VXLAN）封装技术与其他流量隔离。来自一个段的流量被封装在一个VXLAN包中，它通过这个包装器在网络中传输，并在另一端被斩首。VXLAN是另一层——覆盖层——在我们的基础底层之上。
它不仅提供了流量隔离，而且VXLAN还可以通过网络中的特定路径来路由流量。假设数据中心需要通过特定的防火墙和负载平衡器来进行传输。在现代网络中，防火墙和负载平衡器很可能作为虚拟网络功能存在，驻留在数据中心的任何位置。为了将流量送到它需要去的设备，VXLAN封装可以用于隧道从设备到设备的通信流，直到它们遍历所有需要的设备。
防火墙规则在我们的覆盖层和底层蛋糕中形成另一层。一个中央策略管理器会在主机上插入防火墙规则。每个主机最终都有自己的一套规则，这些规则控制着设备的进出。这是一种用于确保可伸缩数据中心安全性的实用方法。
一个添加了更多网络复杂性的通配符是container（容器技术）。container网络是一种新兴的技术，由名称空间、代理服务器和网络地址转换管理，使container能够相互通信，以及与外部工作连接——这是另一层。
在去年，Docker是最火爆的技术之一（不相信的人可以查一下google trends的引用量），Docker是什么呢？白话点说，就是一个Container的管理工具。那Container是什么呢，白话点说，就是一个更轻量级的虚拟机，但是这个虚拟机没有操作系统和设备（操作系统可以共享的）。
一个没有操作系统和设备的虚拟机怎么会如此火爆呢？不是因为container技术本身有多厉害，而是因为container技术目前解决了软件行业的最大问题之一：应用的共享，配置管理和维护（还有应用的隔离，效率等等），不管是在物理机环境还是云环境。
通俗一点儿说，就是container技术，你无论在云环境，还是其它环境安装一个SAP系统都和在app store上安装一个微信差不多简单。这个很吸引人吧。所以不管你是软件开发公司，集成公司，服务公司，电商，还是云计算公司，都跑来跟风（包括google，亚马逊，易贝，微软，IBM……）。大公司里，不跟风的，也就剩HP等为数不多的公司。
那Container如何做到实现应用的部署和隔离呢？它把应用和应用关联的lib库都装在container里面，这个container可以在某个操作系统上跑，而container内的东西和container外的东西是隔离的。大家很快会想到，这不就是虚拟机吗？Container和虚拟机看上去差不多，但是还是有些不同的。
和虚拟机相比，container不仅更轻量，而且配置简化了很多（不用考虑操作系统和设备的配置）。这样做有2个好处。
一个是写应用的人不用管操作系统的事了（我只会写Java，不懂Linux，没关系，你把JAVA相关的配置搞好就好了），因为应用都在container里面。另一个好处是，你的container既可以部署在笔记本的操作系统上，也可以部署到云环境，只要操作系统一样，其它区别都没关系。并且不需要安装，解压等等（这个类似于虚拟机，但是虚拟机要考虑虚拟机容器的不同，而对于container，只要操作系统一样就行了）。从配置管理来看，Container可以做增量的管理。
刚才是从应用共享和部署的角度看container技术。从更大的影响来讲，container技术会影响我们整个软件的开发和管理方式，我拿汽车做一个类比，我们过去的企业级软件（或者叫复杂软件），软件生产的很多工作都是装配和调试，由于IT系统配置相关的复杂性（和汽车相似，一大堆零部件），软件的管理和维护也非常复杂，软件的发布会牵涉到一大堆部门，软件的开发，集成，和其它工具的集成，还有运维，测试等等。由于软件本身是需要改进和升级的，在这种基于装配和调试的生产方式下，软件的管理和维护工作不仅复杂而且工作量大。而基于container和Docker技术，未来应用软件的主要工作会转变为整个部件的替换，装配工作在开发阶段就一次完成了。管理工作的复杂性必然大大降低。软件产品的工业化水平也会大大提高。
另一方面，站在程序员的角度，过去软件的管理和共享，主要是在代码层面，例如github，未来的管理和共享，是在应用层面，类似于google app store.程序员和最终用户的距离会非常近。最终用户也有可能自己搭建SAP这样的系统，这种变化的影响会非常深远。
另外，从效率的角度，container也可以更有效地利用机器资源，这对于云计算的服务商来说，是至关重要的。
运营商的困扰
现代数据中心网络体系结构的复杂性，对于运营商来说是一个潜在的问题。大多数网络问题都与连接性能有关。两个能够连接的断电，却不能相互连接，是一类问题。还有就是，两个端点能够连接，但却没有像预期的那样快速地进行连接，这又是问题。
可以通过检索数据包的方法，查询网络的连通性，从而进行故障排除。从一个网络设备到另一个网络设备，跟踪数据包到达目的地的路径。当实际的IP端点已知时，查询起来就相对简单。
在现代数据中心，底层是用来传输VXLAN或其他覆盖包的。除此之外，我们还添加了防火墙规则，然后可能是网络地址转换或代理服务；包走变得更加困难，充满了细微的差别。要诊断连接问题，操作人员需要知道数据包的起点和终点——包括容器技术、虚拟机或裸机主机、管理数据包、封装包以及要遵循的服务链的防火墙策略。
假设操作人员能够理解应用程序流，并且在一个平面的、无竖井的IT组织中工作，看起来还不是那么糟糕，但也不容易。在桥接和路由表中查找媒体访问控制和IP地址只是排除更复杂的故障过程中很小的一部分。 事实上，增加现代化的基础设施的步伐永远跟不上技术发展的步伐，运营商总在解决过去发生的问题，而过去发生的问题，恰恰很难改造。
性能挑战更难诊断。 触摸给定会话的网络设备的数量可能涉及虚拟操作系统，虚拟机管理程序软交换机，虚拟防火墙，机架顶交换机，脊柱交换机，然后一直到另一端点。
当一些工作负载在公共云中时，事情就变得更加复杂了。将基础设施或平台作为服务的一个服务，意味着为我们的故障排除方程添加高延迟和额外的隧道。
业界的反应是我们被IP所困。由于我们在同时需要额外的功能的同时又被困在IP里，所以覆盖在这里。覆盖层使我们能够引导和隔离流量，这种功能是很重要的。有了它，我们就可以将我们的基础设施看作是资源池，随意地添加和减去容量。然后，这个问题就变成了管理我们在环境中添加的网络复杂度的一个问题。
网络行业已经从几个方面对这个挑战进行了挑战。第一个是接受。如果我们同意复杂性将继续存在，那么我们将提供一些工具，让我们能够发现或可视化网络上正在发生的事情。
例如，Cisco为操作人员提供了增强的工具，以解决其以应用程序为中心的基础设施平台上的端到端连接问题。VMware最近收购了Arkin，这是一种可视化工具，它将工作负载与防火墙策略和VXLAN分割相关联，并与自然语言搜索引擎相结合。
在现代数据中心平台中，有效的故障排除和可视化工具是越来越多的优点。然而，一些人通过创建转发方案来避免这种复杂性，如果可能的话，避免覆盖。
例如，Romana.io开源项目依赖于分层IP寻址方案，结合基于主机的防火墙规则来创建分段和中央安全策略。 开源项目Calico是类似的。 Romana.io和Project Calico都非常有趣，因为它们提供了扩展到大数据中心的转发方案，同时仍然处理安全性和分段要求，而且它们没有覆盖。
也许最大的问题不在于如何处理网络复杂性，而是关于人们支持解决方案。 有一个想法，自动化将允许IT人员变薄。 作为一个20年IT基础设施的老将，我看不到这样的。 极大的复杂性需要很大的支持。 当魔术变得侧面时，组织不会想要与供应商保持联系。 他们会希望让那些知道系统的专业人士准备好解决什么坏事。
