ACI的正式开发始于2012年1月，而引发思考并最终带来ACI的初心却可以追溯到12年前。2000年，我们一伙人启动了思科史上的***内部创业，Andiamo Systems，开发光纤通道交换机MDS系列。这是一个非常有意思的项目，它引入了若干崭新的思路。此前，我们设计了思科的Catalyst 5000、6000和6500这些传统的以太网交换机。但与以太网不同，光纤通道网络是具备结构化寻址、多路径且无损耗的二层网络。那时候，这些概念在以太网上并不存在，而价值却显而易见。
Andiamo之后，我们几个人继续开发思科的Fabric Path技术，以及IETF的TRILL，时间是2003年至2011年期间。这时，我们利用叠加网络，将多路径技术引入到二层以太网。Fabric Path采用专有封装，TRILL则更多基于标准的技术路线。我们还带来了所谓的融合以太网，它同时支持无损与有损流量类别以及Fabric Path。TRILL引入了我们都很喜欢的协议学习，但不幸的是，它在市场上并不是很成功。在那段时间，我们还同VMWare定义了VxLAN包格式，它源于LISP及DCI技术的相关工作。
2012年1月，我们开创了Insieme Networks，致力于整合Fabric Path、融合以太网、VxLAN，以及崭露头角的软件定义网络(SDN)，来开发新一代的数据中心网络。在进行这些工作时，一个灵感击中了我们：网络配置与管理的方式同样需要根本性地转变，以降低数据中心的运营成本，提升灵活性、改进安全性并减少人为失误。最终的产物现在大家都知道了，就是“以应用为中心的基础设施(ACI)”以及“基于意图的网络(IBN)”。
在整合之初，我们解构了其中每一项技术，试图理解基础组件都有什么，它们实现了什么目的，及其如何支撑最终的解决方案。我们提了成百上千个问题，诸如：“到底什么是三层转发”，“为何二层网络的配置要少得多”，“为什么要洪泛ARP”。每个问题，都为我们最终保留或放弃某个组件提供了深层见解。我们希望获得三层网络的所有好处、二层网络的所有好处、叠加网络的所有好处，但拒绝它们的缺点。我们期待一个系统可以轻松扩展至***型数据中心的规模，同时也适用于最小规模的数据中心。我们还期待这个系统，它的使用者不太容易因犯错而造成宕机，也没有单点故障，还能与现有环境融洽相处。
我们***讨论的关键问题之一就是如何扩展叠加网络。从一开始我们就认识到，在TOR交换机上实现VxLAN，与那时候刚出现的纯软件方案相比，有着巨大的优势。数据中心的交换机大概比服务器少40倍，这是一个经典的分布式系统问题，因为扩展紧耦合元件的数量是最难的。然而在这个问题上，我们的执行管理层对设计团队追得很紧。过去有许多案例，当产品最终交付时，其原始的可扩展性目标就已经不够了。管理层追问我们是否还能做得更好;同时我们也开始听说，在这个问题上，一些初创公司或许实现不了其野心勃勃的目标。最终，在六个月的开发努力后，我们停掉手头的一切，推倒之前的全部工作——我们大概八个人把自己锁在屋子里整整一个月，重新设计了所有的硬件。我们苦苦思索着决定系统规模的网络状态处理机制。为维持系统的正常运行，必须进行众多网络状态的同步;而在分布式系统中，状态的规模是一个函数，它与状态同步的数量大小、地方多少、频率高低及其机制的健壮程度都有关系。我们开发的方案将全局状态分成两类：端点位置与策略。端点位置可以较快地变化，以适配应用的移动、服务器的上下线以及网络元件的失效。我们将这类状态尽可能减少，只需要在两个地方同步即可保障其行为正常，并与网络的大小无关;而当发生错误时，它完全能够自我修正。策略的状态比端点位置的状态复杂得多，但它不常变化、变化时也更好预测，而且毋需扩散至整个系统。结合这两种状态的处理机制，我们最终得到了一个好得多、快得多、健壮得多的可扩展性方案。对于这一问题的***解决，我们尤为自豪。
该方案的另一大重要组件是APIC控制器。那个时候SDN网络的呼声甚嚣尘上，后起之秀们鼓吹集中式控制器可以解决所有的网络问题。大家都来问思科，你们的SDN策略是什么，还有一些人预言它会终结思科。我们看到集中式控制器的优点，是它提供了对网络的单点联络，保障了整个矩阵配置的一致性;将网络整体视为单一组件，而并非网络设备的堆砌，所有这些都将大幅降低运营成本，并提升灵活性与可用性。然而，控制器也引入了单点故障，或者说它必须足够可靠，最终至少达到与此前的无控制器网络同等的可靠性。我们的方案是在任何关键路径上拿掉控制器。这样，即便控制器由于何种原因离线，网络也能继续工作;与此同时从管理视角而言，它仍然可作为单一的联络点。这意味着控制器并不会降低、实际上反而增强了网络的可用性。***限度的可用性是我们的首要目标，而将控制器从关键路径上移除的同时，还使得软件的升级更容易并且控制器的规模更大。方便的升级与更好的规模，已显著地加速了并将持续加速我们的开发周期。
我们为ACI开发的策略模型，对整体方案而言是一个关键组件。由于这是在网络管理领域引入了一个全新范式，对我们而言***挑战。我喜欢这样来描述它：传统网络有自己的语言来配置并操作;数据中心网络是承载应用的，而应用也有自己的语言。IT专业的主要工作，就是将应用的语言翻译成网络的语言——而恰恰就是这个环节产生了错误、丢失了信息、浪费了金钱。我们试图用ACI的策略模型来变革网络的语言——使其更贴近应用的语言，以减少错误、缩短时间、降低成本。ACI策略描述的是服务器之间的对话，与它们在网络上的位置、桥接还是路由、数量的多少都无关，并尽***可能与其IP地址解耦。这带来了一种更加自动化的、更为安全地配置并管理数据中心网络的方式。今天，我们把这种机制称为基于意图的网络——IBN。
一路走来，ACI的开发和投产已经过去了五年时间，我们学到了很多。我们的客户在利用程式化或API驱动的网络管理方面，远比我们所预想困难得多。这个技能上的鸿沟虽然在缩小，但仍存在于许多客户之间。我们可能应该更快地提供一个纯软件版本的ACI，这样就能尽早地部署到更多环境。我们的对象模型并不***：它很强大，然而要花许多时间来学习。虽然不是刻意为之，但我们基本上让VxLAN的叠加消失了——管理员不需要刻意地配置并管理它。这一点可能比许多人意识到的更加重要、更有价值。我认为对于在网络上植入4-7层服务，我们提供的支持已经超过了实际需求。我们或许应该引导业界，采纳少量的标准方式即可导入这些服务。这耗费了我们过多的工程资源。
这么多年来开发ACI的相关技术与ACI本身，带来了无穷无尽的技术挑战、无数问题解决的惊险激动、改变行业的成就感，及其对同事、员工和客户所产生积极影响的无上喜悦。尽管来日方长，但到目前为止，这已是一个伟大的历程，并为我提供了一段非常令人满意的职业生涯。
Tom Edsall
思科院士/ACI之父
