在大量的软件定义数据中心流行词中，有一个非常重要的概念：整合。这个概念表示构成数据中心网络的所有部件不应该差别太大。经过多年的协议层抽象之后，我们现在想要我们的各种利器（网络、存储和计算机）重新整合成为整体。

为了让各个独立的部分完美整合在一起，我们必须给它们提供一种通信方式，而不需要专业技术人员繁琐的人工干预。我们需要通信、自动化和团队工作，表面上减少中间过程的“团队”。我们需要开放API，至少从理论上是这样的。

如果设计得当，API就可以让我们做任何事情。我们可以编写软件自动迁移存储LUN或虚拟机，定义网络流的实时QoS，给应用和服务器附加各个系统均认可的策略，或者自己为现有产品编写自动化机制。但是，开放API还要求我们掌握新的技术，还需要投入大量时间进行编程和开发。

而且，虽然开放API表面上可以解决现代数据中心网络的许多问题，但它们实际上是现代IT领域中众所周知的“42”。和Douglas Adams名著里的主角一样，我们需要知道我们要解决的问题是什么。所以我们需要先确定想要实现的目标。

开放API很好，但是供应商之间的合作更好

API就是救世主的论断源于我们对网络与基础架构工具现状的不满。在网上随便搜索，我们就可以发现人们对几乎所有制造商的所有GUI或CLI都有怨言。有一个人说：“这个GUI竟然不支持HTML5！”另一个人说：“这个GUI不支持我喜欢的操作系统。”还有另一个话题不常见：“真正的高手都用命令行。”是不是经常听到这种说法？这样就变成，如果只能访问我们系统的内部环境，那么我们就可以写出更好的CLI、GUI或自动化工具套件。

但是，即使在理想情况下，我们拥有实现这种可编程性所需要的全部技术与时间，而且所有API都开放、有文档且非常好，那么统一整个数据中心内各个分散系统所需要的工作仍然很繁重。因此，我们不仅仅需要开放API，还需要供应商方面对于整合过程的参与和贡献。

我认为，我们应该要求供应商提供所购买设备的编程访问。但是，我们需要解决的更大一个问题是团队合作和协作。我们希望所有设备和系统能够互相通信，同时这个过程又不能给我们带来风险，也不能增加业务成本，还要能够提供网络生产力，但是我们并不一定要自己来完成这些工作。

我们希望供应商交付的系统本身要能够互相通信。我们需要购买的存储和计算资源本身知道如何连接我们的网络，告诉网络它们需要什么，而且我们也希望我们的网络能够与它们通信。这就要求使用通用的协议和工具。但是，这也要求我们愿意去寻找价值，而不要在将来的业务中依赖于某一个供应商。因为它不是API能解决的问题。