复杂性阻碍DevOps取得成功

鉴于开发人员已经开始采用敏捷、方便的可编排技术，会越来越多地采用基于容器的应用程序。当这些应用程序进入生产阶段时，他们的编排解决方案对操作复杂性产生了相当大的影响。DevOps成功的最大障碍之一仍然是复杂性，Quali Survey进行的调查显示，11%的受访者认为自动化相关的挑战以及系统的编排是影响DevOps成功的障碍。

这种复杂性部分来源于将应用程序分解成“微服务”的模块，每个微服务本身都是一个可扩展性域，需要负载均衡和安全以及网络支持。随着容器部署越来越多，这些主要的基于软件的解决方案需要大量的容器内和集群内，增加了东西向流量的数量和频率。规模化应用的传统网络托管解决方案（负载均衡等）必须适应，不仅是通过软件提供功能，还要通过满足相对极端的需求来跟上基于容器环境的极端动态性质。

为此，出现了一种独特的架构模式，轻量级负载均衡应用程序代理驻留在容器集群中，以便扩展和协助服务之间的集群内路由。当应用程序分解时，其内部通信模式转变成外部通信模式，并且必须通过网络而不是在应用程序内部进行。这带来了复杂性以及规模的需求，随后通过纳入东西向集中的负载均衡代理来解决这个问题。

在架构方面，在应用层面上仍然存在规模化，这需要在南北向网络纳入能提供规模、性能和安全性的上游业务。通常由应用交付控制器（ADC）或其他负载均衡代理（软件或硬件）提供，并且促进用户、事物和集群外部的应用程序之间的通信。

无论是Kuberes还是Mesos或OpenShift，容器集群解决方案都适用这种模式，其带来的额外的复杂性以及对代理提供的不仅仅是传统功能的需求，还支持应用程序接口（API）调动，基于软件的模型、容器、云和应用程序正在不断构建。

云也在不断发展，新兴的计算模式是无服务器模式，或称为功能即服务（FaaS），该模式假定比云或容器性能更加优秀，按要求但不按需调用资源。支持网络对这种环境的响应能力，对于这些模式在实现其预期收益方面的成功至关重要。

为了应对这些挑战，网络必须一如既往地满足速度需求。，速度并不是目前唯一的关注点，负载均衡服务更新资源池的速度至关重要。这给负载均衡服务带来了压力，必须确保其API具有与其核心功能相同的可扩展性和性能，对于服务集群内通信解决方案的微服务和应用程序之间的东西向流量而言尤其如此。

必须从网络方面整合到由Kuberes、Mesos和OpenShift编排的集群内容器的自动化和编排中。假设网络根据管理、调度和编排容器生命周期的集群主节点提供的信息自动调整配置和行为，那么像负载均衡这样的服务必须能够监控并了解集群活动的各种标签和消息，并对这些作出反应。例如，当Kuberes宣布推出新的容器时，负载均衡器需要识别事件并通过调整配置进行响应。相反，当Kill一个容器时，网络需要从负载均衡资源池、路由表和安全策略中删除相关信息来进行响应。这对速度提出了相当高的要求，以避免无意中将请求分发到已经不可用的资源。

这些行动必须以速度为前提，以免可用性或规模化受到损害。可扩展、快速的管理平面是网络服务的需求，希望在容器甚至基于云的环境中保持相关性和有用性。两者都高度依赖于自动化和业务流程，需要专注于其应用程序接口（API）及其核心功能。如果没有快速、易使用的API，网络解决方案将面临被淘汰的风险，并被软件为基础的服务取代。

云计算强制网络无论是形式还是操作都要采用软件定义的模式，容器正在进一步改变通信模式，以使规模、路由和安全性与这些日益增长的易失性环境协同工作。网络必须适应对应用程序变更作出反应的模式，更直接地与应用程序基础设施集成。最终，网络必须靠真正意义上的应用来支持当今的应用交付模式。