毫无疑问IT技术和基础架构在过年几年当中实现了快速发展。而网站系统也已经从最初的“脚本和文件的简单组合”发展成为“由可重用代码组件构成的复杂模块化应用系统”——所有网站都在使用HTTP，其已经成为互联网通信的主要协议。各种各样的Web应用已经完全融入到人们的生活当中。用户期望获得响应速度快、性能良好并且能够在所有设备上流畅运行的应用程序。

尽管我知道很多工程师都认为这是一件令人兴奋的事情，但是同时我也知道很多技术经理敏锐地意识到技术的快速发展以及用户不断提升的期望值所带来的全新挑战。而在所有这些挑战当中，管理权限是一个非常突出的问题。我们在将传统基础架构迁移到更加流畅的web架构方面已经取得了很大进步，但是仍然在使用传统方式来分配控制权限。这就能够解释为什么现在很多公司当中，网络团队依然控制着应用程序交付流程——而不是那些负责开发应用程序、并且加速其性能的DevOps工程师。显而易见，这种权限分配方式并不合理。

相互矛盾的优先级和复杂性关系影响团队表现和效率

下面的情况是否听起来十分熟悉？也许你也曾经在自己的企业当中遇到过类似的问题。如果真的是这样，那么是时候思考应该如何避免这些由控制和问责机制失衡所导致的矛盾和冲突了。

也许你是一位开发人员，现在想要为某个应用程序添加或者修改访问控制列表（ACL）以提升系统安全性；或者想要临时将流量重定向到另外一台备份服务器。现在你需要做的不是思考应该如何自己完成这项任务，而是认真地准备一份相关申请，之后提交给网络运维团队。（由于他们很有可能需要处理企业当中的所有请求）因此你必须等待他们找到合适的时间来处理你的请求。

当然，如果你总是向他们提交申请，那么最终他们可能会为你分配一些简单的控制权限，因为他们需要处理其他（通常是更加重要的）任务。但是如果在你操作过程当中系统出现故障导致无法访问，那么无疑你将会成为那个被责备的对象。导致系统故障的原因很多，可能只是由于某个厂商设备的ACL具有默认的“隐式拒绝”规则，而你忘记显式放行特定流量，也或者你没有搞清楚“反向掩码”，还或者将ACL错误地应用到其他接口上了。因此，不论对于开发人员还是网络团队来说，这种方式都不是一种好的解决方案。

大部分情况下，网络团队掌握应用程序交付控制权是因为当前环境使用了基于硬件的应用程序交付控制器。但是这些集中式应用程序交付解决方案由于潜在的单点故障问题而变得非常脆弱。除了脆弱性之外，还需要思考被分配过多任务的网络团队如何快速构建和部署应用程序，这无疑是一种并不稳妥的做法。

企业当中的开发人员数量通常大大超过网络工程师的数量。我们经常能够听到一家拥有数百个虚拟化服务器实例、数十种应用程序的企业拥有100个人的DevOps团队——但是同时也许只有两个网络工程师在管理多个部署在私有云当中的应用程序交付控制器。显而易见，网络团队很难同时处理多项web加速任务，而且他们同样担心将过多的应用程序逻辑引入到网络环境当中。

此外需要记住的是，高速网络并不一定总是意味着应用程序的良好表现。配置命令当中的潜在冲突或者网络设备当中的错误脚本都有可能导致问题的发生。事实上，向网络团队不停发送配置变更请求所能够得到的唯一结果就是抱怨的逐渐加深。

另外一种不和谐因素的来源是应用程序系统工程师使用的现代敏捷开发过程。使用这种方式之后，开发人员不能在开发完一款产品之后将其交付给其他人进行部署和维护；敏捷开发过程需要创建迭代，之后部署，一直重复这个循环。而这个循环要求开发人员拥有全部、端到端的控制权限，这样才能够避免大量http传输可能产生的系统性能和可扩展性问题。然而协商各个部门任务分工的过程无疑会延缓开发人员的工作进度，并且开发人员难以更改系统配置以提升系统性能。

软件解决方案：新的希望

那么DevOps工程师应该如何解决这些问题呢？其应该想办法获得web加速和应用程序性能方面关键功能的管理权限，同时仍然满足企业对于性能和安全方面的需求。

而坏消息是，你不能使用任何10或15年之前推出的工具，这些工具针对大型、古老的独立应用程序（同时对于消费者和企业来说）而开发，因此并不适用于现代的分布式、松耦合以及组件化的应用程序。而网络工程师也不能帮助开发人员解决HTTP的复杂性问题，他们的注意力仍然在网络设备硬件方面，主要关注数据包，而不是应用程序。

等一下，也许你会想使用NFV（Network Function Virtualization）来解决这个问题怎么样？这是一种可行——但是只适用于部分情况——的解决方案。首先，其主要提供2层、有时是3/4层的功能，而和第7层相关的功能还没有被完全开发。NFV和SDN的另外一个问题是，目前为止，其只解决了商业网络基础架构的问题，而无法应对如何在DevOps环境当中如何管理完整第7层环境的挑战。企业需要寻找一种解决方案，合理地对层级权限进行管理。网络团队需要控制3和4层，而DevOps工程师需要第7层的控制权。

最后同样重要的是，大多数应用程序框架都没有提供良好的方式来快速和轻松解决HTTP的固有复杂性问题——比如并发处理、安全、访问控制等——以及应用层流量管理。

那么究竟应该如何解决这种问题呢？网络或者应用程序框架都不能在端到端web加速方面起到真正的帮助作用，是否存在相关软件能够解决这种矛盾关系，完全满足DevOps的全部需求？

幸运的是，答案是肯定的。现在有很多非常有用的工具，能够提供HAProxy、负载均衡或 SSL termination等功能，而另外一些产品（比如我们自己的NGINX Plus）能够提供所有主要功能，比如应用层负载均衡、请求路由、应用程序内容交付、web缓存、SSL termination、即时压缩、协议优化等。

这些DevOps工具的配置方式遵循“应用程序风格”，能够很好地兼容Puppet或Docker等其他工具所提供的自动化功能。此外，其还能够被轻松部署到云环境当中，在虚拟化环境当中高效运行，并且和应用程序协同工作，最终成为应用程序的一部分。同时，这些产品拥有和网络硬件设备相同、甚至更好的性能表现，在低成本投入的情况下拥有无限制的吞吐量。

最后，也许是最重要的一点，其还能够为DevOps团队提供期望已久的针对HTTP性能和可扩展性的端到端控制权限。

使用DevOps工具合理控制权限

决定使用DevOps工具之后，下一步就是思考如何使用其满足当前需求了。DevOps和网络基础架构团队可以融洽相处，并且更加高效地合作，如果应用层功能由基于软件的可扩展层实现——完全由DevOps团队进行创建和管理——而像数据包传输、QoS以及其他传统网络功能仍然交给网络基础架构团队进行管理。

谁能够从中受益？所有人。开发团队可以从顺利运营、快速配置和部署以及更加简化的应用程序开发流程当中受益。而网络团队的负担减少，能够更好地控制其所需要管理的领域，同时将集中精力于自身工作。用户受益于更好的应用程序使用体验。最终，公司也能够从高效交付高性能应用程序以及满足市场预期等方面获益。

我们推荐用户尝试使用这种基于软件的解决方案，查看应用程序速度和效率的提升情况以及团队成员是否对其感到满意。企业现在可以免费试用NGINX Plus以替换现有的基于硬件的应用程序交付控制器，或者联系我们，更好地了解NGINX如何帮助企业以一种DevOps友好的方式交付高性能、安全、可靠和可扩展的应用程序。