为了以最终用户所需要的速度部署新的基础设施，企业IT部门需要拥有基本模块架构和真正DIY功能的可视化自动化工具。
云计算的两个主要价值就是速度和灵活性。云计算编排和自动化工具有望让IT部门大大加快运营速度，并且成为更具竞争力的服务型部门。虽然一旦虚拟化系统落实到位，编排工具在灵活地部署应用程序方面通常做得很到位，可是遗留的非虚拟化底层基础设施其灵活性或自动化程度不是很高。人们没有正面解决这个问题。相反，许多人把精力放在了解决物理基础设施问题上，试图获得灵活性时，这就成了致命弱点。不过，可以避免这种情况。
为什么基础设施灵活性至关重要？
企业IT部门面临许多方面的压力：上头下达的任务、预算、用户期望以及与竞争对手之间的差距。
首先，这是个不言而喻的现实：企业IT部门面临的任务正在迅速转向支持灵活创新。不过，预算并没有相应增加，帮助IT部门满足这个要求。根据知名调研机构Gartner的《2014年CIO议程报告》的调查结果显示，全球CIO声称，2014年累计的IT预算增幅只有区区0.2%。
原因可是带来压力的另一个方面：用户要求IT部门提供IT消费化，这促使用户从别处获取服务。在Gartner的同一份报告中，有CIO声称，25%的IT开支出现在IT预算外面――这仅仅是他们所看到的。换句话说，企业的IT部门将“市场份额”拱手让给了公共云计算服务。
一方面是几乎立马就能提供的公共云资源，另一方面是传统IT流程交付的速度较慢的服务，这种竞争差距或许可以解释这种转变。据企业管理协会（EMA）的《2014年软件定义数据中心》研究显示，47%的企业自称，为应用程序开发人员和测试人员部署基础设施所需的时间短至一星期、长达一个月。
基础设施交付时间
来源：企业管理协会（EMA）的《2014年软件定义数据中心》报告。
相比只需要短短“几分钟”就能获得公共云资源，这个竞争差距相当大。当然，并非一切都会很快向公共云转移。在将来，会有好多基础设施事务需要IT部门处理好，不过提高标准对IT部门来说有百利而无一害。
物理基础设施仍是云灵活性面临的一大障碍
云计算及相应云计算自动化的两大原则就是，所有的基础设施变成虚拟化；拥有对自动化友好、***是代表性状态传输（REST）式样的应用编程接口（API）。这无疑是一种大有帮助的、简化操作的愿景。这让人们有可能将“基础设施变成代码”，因为一切都是抽象处理的、软件定义的、可编程的。
这个愿景方面鼓舞人心的主要例子有Netflix等大规模互联网公司，它们的业务运营有赖于亚马逊网络服务公司（AWS）等提供商提供的公共云基础设施。遗憾的是，大多数企业组织的历史不像这些互联网公司那么短，也没有似乎无限制的IT预算；对它们来说，IT基础设施的实际现状可能显得相当混乱。据NTT通信公司在2013年的一项调查显示，58%的CIO表示，阻碍自己采用云计算的***障碍之一就是，现有系统错综复杂。任何已经存在了10多年的IT部门拥有没有虚拟化的遗留基础设施，这些基础设施可能不会在短时间内马上消失。
物理基础设施的现状影响着IT取得类似云服务的灵活性，这体现在几个不同的方面：
•零日部署。如今，大多数企业在IT基础设施方面的投入仍然侧重私有云，而IT团队购买基础设施设备的方式已发生了翻天覆地的变化。以前的方法是，购买计算、网络、存储和虚拟化这每个类别的同类中***解决方案，然后自行把这些部分集成起来。现在，人们越来越追捧VCE Vblock等融合型基础设施产品、EMC VSPEX等参考架构，甚至Nutanix或最近宣布的VMWare EVO:RAIL等超融合型解决方案。融合型基础设施、参考架构和超融合型解决方案具有诸多优点，包括：它们本身已经过集成、测试和兼容性认证，能够达到某些性能基准，或者支持一定数量的虚拟机或桌面。这为企业的IT部门减轻了扮演系统集成商的压力。然而，即便有了集成的产品，搭建基于这些产品和架构的小型集装箱式数据中心（pod）所需的零日配置也绝非易事。这通常需要多个领域的专家协同工作，针对某一个特定的部署场合来进行手动配置。这往往需要一到三个星期的时间。如果不是那么浪费人才，如果这么长的配置和部署时间与公共云提供商的解决方案不是相差甚远（可以在短短数分钟内构建好虚拟机），那这很好。
•供应链。考虑到部署时间方面与公共云服务提供商之间的竞争差距，有必要强调一点：私有云基础设施的部署与供应链确实密切相关。如今的大多数数据中心基础设施是通过分销和系统集成渠道而购买的。究其原因，那是由于，即使我们假设分销商保持充足的库存量（在适时物流世界），那样根本不存在设备制造商发货引起的滞后时间，分销商或系统集成商通常不得不执行某种程度的配置工作。我们也别忘了，IT产品分销行业靠相对较薄的利润来运作。因此，虽然利润丰厚得多的制造商有许多高度专业化的人才，但分销渠道拥有的这方面人才比较少。这就意味着，如果配置工作需要专家们在房间里待三星期，可供调派的专家就比较少。然后，哪怕IT企业的小组只是想及时收到基础设施，供应链也会成为一大制约因素。如果企业的IT部门受到反应迅速的公共云/影子IT这个竞争对手的威胁，那么供应链也受到威胁。
•基础设施即服务。构建私有云或混合云基础设施即服务（IaaS）解决方案时，许多IT部门面临这个事实的挑战：它们必须处理物理基础设施资产，比如非虚拟化/专用服务器、网络交换机和遗留的非虚拟化存储阵列。这些资产的存在绝对不是什么小事。比如说，EMA的软件定义数据中心研究发现，83%的IT部门在专用服务器上运行应用程序。此外，虽然软件定义网络（SDN）现处于炒作周期的高峰期，但事实上，实际部署的SDN几乎就没有，尤其在企业IT环境中。实际上，2014年8月开展的一项调查发现，三分之二的调查对象估计至少三五年后才会部署SDN。因此，无法处理好虚拟化基础设施和非虚拟化基础设施的IaaS可能会沦为另一个孤岛，无法帮助整个行业向前推进。
编排和自动化适合何处？
如今市面上不乏出色的编排和自动化工具；然而，绝大多数工具属于两大类，没有哪一类真正面对基础设施灵活性的实际现实：
•纯虚拟化编排。大多数编程和自动化工具实际上假设：一切系统都是虚拟化的。无论是面向整个堆栈，还是可能面向网络虚拟化，这类解决方案根本没有以任何一种有意义的方式来处理物理基础设施。
•垂直集成的编排。大多数数据中心计算基础设施厂商提供编排工具，以处理物理基础设施和虚拟基础设施。然而，所有这些基础设施必须由同一家厂商来提供，它很少可以延伸到其他所有已落实到位的物理或遗留基础设施。
当然，这不是说这两种解决方案都缺乏有效性、都没有用――它们显然适合特定的使用场合和环境，但它们也明显存在局限性。
通常来说，为了克服这些挑战而提供的解决方案就是API：你可以使用API，扩展工具的业务逻辑，以便处理原本无法处理的对象，包括物理基础设施。这种办法确实存在着一些问题，但我只想说一句：就算有意愿，大多数企业的IT团队也无力构建和维护一套内部自行开发的自动化架构（通常意味着面临一大堆难以维护的脚本），以便满足这些需求、与那些API进行集成。
灵活基础设施编排技术和***实践
好消息是，现在已经有编排技术和与之配套的***实践，可以克服异构基础架构这个挑战。方法包括下面这些主要原则：
1. 基本模块对象架构。为了满足将物理库存和虚拟化资源编排成公共资源池这一需要，所有的资源及配置接口都表示成或编码成基本模块对象。这意味着，可以为基础设施库存资源分配公共属性，以便识别应该使用哪些配置对象。比如说，它们是虚拟机、是IOS或IOS-XR交换机，还是运行Linux的非虚拟化的戴尔或惠普服务器？配置对象还有着同样的公共属性，以便从底层API语法抽取输入参数。这种方法的一大优点是，它为自动化重复使用奠定了基础，因而大大减少了维护自动化所需要的成本和时间。这与基于脆弱脚本的系统形成了鲜明对照：脚本系统往往难以维护，这是由于在几百个或数百个不同的脚本之间有着太多重复的公共函数或API调用，另外由于脚本比较难以理解，特别是由于它们往往缺少详细的说明文档。
2. 创建即开即用、自己动手（DIY）的配置接口。对自动化工具厂商们来说，为公共云API构建库比较容易。试图支持在企业IT部门多年来部署的基础设施这个庞大环境里面的所有一代又一代的接口，好比试图把整个海洋烧开，无疑是白费力气。如果完全依赖自动化工具厂商来构建和维护这些接口，自动化过程也就丧失了大部分灵活性，因为代码更新可能需要耗时几个月，甚至在开始为那些接口编写代码之前可能需要与业务部门洽谈相关事宜。在许多情况下，配置基础设施其实只需要API的一小部分。所以，想保持自动化方面的灵活性，能够自行创建配置对象的DIY方法必不可少。
3. 可视化编排和自动化创作工具。如前所述，大多数企业的IT小组没有大批程序员。这些部门最不希望被没有根据本企业的人员状况而开发的一套方法捆住手脚。企业的IT人员习惯于使用用户界面（UI）工具。GUI编排工具相当常见，但它们应该具有真正的灵活性，以便构建资源环境，包括任意的网络拓扑结构，以便连接可能需要的所有不同资源。编排工具应该可以将物理资源和虚拟资源都能拖放到设计画布，并且在物理层和虚拟层都能管理好连接。一旦自动化对象创建起来，你没必要让业务逻辑与环境构建、仅由程序员构建的配置混在一起。可视化自动化创作工具让见多识广的非程序员也可以通过拖放操作来设计工作流程。对象重复使用和可视化创作工具这对组合意味着，你可以增加实现和维护自动化的人员的数量，而这有助于形成一种真正可持续发展的自动化实践。
企业的IT团队确实很需要提高部署基础设施方面的灵活性。在竞相构建和证明这种灵活性的过程中，别忘了全面顾及最终用户需要的所有基础设施，包括物理基础设施。然后，选择一种编排技术，并确立自动化实践，以便有效管理该基础设施，让你可以为长远目标构建和维护自动化。
