不要为了速度而牺牲服务

不，不是那种速度。 另一种速度。

速度，即应用开发和投入生产的速度，是组织采用敏捷开发方法和 DevOps 进行部署的常见驱动因素。 指标通常围绕“周期时间”和“部署频率”而定，它们经常与敏捷指标一起被引用，敏捷指标以越来越短的“冲刺”来衡量时间，以便更快地将特性和功能推向市场。

这与速度有关，而云一直被吹捧为实现速度的一种手段。 无需漫长的采购时间，也无需等待货架和堆放。 预定的部署窗口可能需要等待数月？ 没有这样的事。 云的“敏捷性”实际上只是速度的同义词。 在CA Technologies 于 2015 年开展的一项调查中，90% 的高管面临着更快发布应用程序的压力。 当问题在于实现适当的市场速度时，云通常被视为答案。

但在急于转向云计算的过程中，企业往往被迫牺牲一些服务，通常是因为没有类似的产品或部署专业知识。 这是一个问题，特别是当涉及到性能、安全性和规模这三个运营要素时。 牺牲上述任何一项都会对利润和生产力产生毁灭性的影响，这两项指标都是企业每季度甚至每日进行自我衡量的指标。

这可能就是为什么 Network World 2016 年网络状况调查中的大多数受访者表示网络投资的主要驱动力是提高性能（55%）、数据安全（53%）和确保可用性（50%）。

我们自己的application交付状况调查也发现这三者同样受到重视。 当被问及受访者如果没有哪些服务就不会部署应用程序时，安全性和可用性位居榜首。 还有表现吗？ 这是组织机构最后愿意放弃的事情，即使这意味着让他们的网络更加安全。

组织需要“两全其美”的方法。 他们需要云计算的灵活性（即速度）来匹配开发和运营将应用程序投入生产的速度，但他们不能牺牲他们所依赖的安全性、规模和性能的服务。 关键时刻的违规、性能不佳或无法扩展与根本无法将应用程序推向市场一样具有破坏性。

问题是这两个世界似乎互相矛盾。 这是由于试图同时支持可靠性和灵活性而产生的数据中心不和谐。

事实证明，世界实际上并不像听起来那么不和谐。 业务层面所需的敏捷性，包括优化应用程序和事物的运营，以及更快、更频繁地将特性和功能推向市场，都取决于提供这些特性和功能的基础设施的可靠性。 这并不是说网络无法以这样的速度移动，而是网络需要更多的关注来确保部署不仅可重复，而且也是一致和可预测的。

这意味着，部署维护安全性、规模和速度所需的应用服务的传统方法不是问题。 问题在于它们部署的速度。 解决这个问题意味着要转向 API 和模板等编程方法，这些方法与编排相结合，可以加快应用服务的部署速度。 速度与应用程序开发和操作的速度更加一致。

一个解决方案是在所有环境中采用一组操作一致的服务，无论是传统环境还是托管环境、公共云还是私有云。 凭借能够在一系列强大环境（如所有云和传统数据中心）中部署的平台，组织可以通过减少因创建和管理多组策略而导致的运营摩擦来提高速度，其中一些策略可能缺乏促进一致性和合规性的必要能力。 通过平台方法，集中指挥、分散执行可以成为现实，并提供可重复性，从而建立部署信心。

使用模板或将“基础设施即代码”视为可确保跨环境服务部署的一致性和可重复性，从而提高可靠性，而编排则可提高速度，从而支持当今更加流畅、敏捷的运营特性。

您可以同时享受两全其美的成果。 可靠性和灵活性。 您不必为了速度而牺牲服务。 你只需确保在正确的位置拥有正确的平台和正确的功能。