管理≠编排

随着我们继续看到敏捷方法对 IT 的其他部分（如网络和安全）产生的连锁反应，我们看到了 SDN 和 SDDC 等架构和技术的兴起，以及 DevOps 继续扩展到相邻的 IT 问题。

这是因为对于（部署）速度的需求正在增长，其渴望几乎与消费者对应用程序的渴望一样难以满足。 当今业务的增长取决于 IT 的扩展能力；不仅在交易率和吞吐量方面，而且在运营方面。

实现支持快速（且通常不可预测的需求）所需的规模意味着需要更多的硬件（无论是定制的还是 COTS）、更多的平台、更多的服务等等。 更多需要监控、备份、配置和许可的事物。 这就是管理。

实现部署应用程序和交付服务所需的速度意味着部署过程的自动化。 这就是编排。

这两者并不相同。 事实上，将它们混为一谈是危险的，因为这样做会使它们紧密耦合，并难以快速改变流程。 这通常是必要的，以提高效率或向系统添加组件，以维持企业生产率和利润所依赖的应用程序的性能、速度和安全性。 一年中可能会发生多次。 业务流程管理专家从研究告诉我们，企业每年改变其核心流程4-7次。 他们通过分析 IT 收集的所有数据以及来自消费者和企业用户的反馈来做到这一点。

为了确保业务层的灵活性，业务流程编排 (BPO) 在 2000 年代中期成为一项要求。

现在我们在 IT 层面也看到了这一点。

对于任何寻求实现业务成功所需的部署规模和速度的组织来说，运营流程编排对于其成功转型都至关重要。

但这并不意味着管理不重要。

管理仍然是需要的，虽然某些管理任务可以（通常应该）自动化，但这不是编排。 关键系统的自动夜间备份、升级、许可证管理、补丁甚至资产管理（库存）是IT确保其运营规模的重要手段，使单个管理员能够管理越来越多的设备，但这不是编排。

相反，编排不是管理。 虽然您可以从使用编排引擎（系统、框架，无论您想怎么称呼它们）中受益，例如OpenStack或 Cisco ACI 或VMware NSX ，但它们都无法实现对它们所配置的实际组件的核心管理。 例如，他们当然可以创建并启动 BIG-IP 来提供 LBaaS，但其业务并不实际管理该实例。 它不进行更新，不应用热修复，不监视警报或任何确保业务持续运行的日常职责。 这是管理的任务，而不是编排的任务。

虽然它们并不相同，但在应用世界中它们同样重要。 编排使 IT 能够扩展应用程序部署，从而使业务能够扩展，而管理则通过处理所有我们似乎忘记了（感谢云）仍需完成的任务来确保业务保持运行。 

管理通过启用自助服务配置和部署与编排协同工作（协作），但它们并不相同。 他们也不应该这样。