趋势

趋势

Forrester 称,50% 的组织正在实施 DevOps 实践,以加快进入市场的速度(高功能速率),并改善稳定性(降低停机发生率,加快问题解决速度)。

随着 DevOps 实践的增长,企业利用微服务架构让应用程序实现现代化,在这些架构中,不同的应用程序被分解成离散的打包服务。近 10% 的应用程序经过全新构建成为微服务,另外 25% 为混合应用程序(与附加的微服务形成整体,有时被称为“微型服务”)。

DevOps 原则的发展和微服务架构的采用对应用程序开发和基础结构的所有方面均具有深远的影响。

相关内容
下载解决方案指南以获取全部详情。
获取 NGINX 指南
DEVOPS 转型

DEVOPS 转型

这些趋势正在改变我们的认知方式,也在改变我们开发应用程序的方式。

人员 >

控制权从基础结构团队转到应用程序团队。基础结构为 DevOps 所开发和维护的应用程序提供支持,为了快速进入市场,DevOps 期望能够掌控该基础结构。

流程 >

DevOps 缩短预配时间。 现代的应用程序基础结构必须实现自动化,并要更快对其进行数量级预配,否则可能会面临延误部署关键修补程序和增强功能的风险。

技术 >

基础结构将软件与硬件分离。 软件定义的基础结构、基础结构即代码和组合式基础结构均描述了全新的部署架构,其中的可编程软件在通用硬件 (commodity hardware) 或公有云计算资源上运行。

挑战

挑战

尽管 DevOps 和微服务会影响应用程序基础结构的所有方面,但是其专门更改了企业部署负载均衡器技术的方式,因为负载均衡器是位于您所有应用程序前面的智能控制点。

然而,贵组织中不同的团队需要以不同的方式使用负载均衡技术。

企业 >

企业借助高级功能采用中心负载均衡器,以管理所有的应用程序流量,改善部署的吞吐量和稳定性。位于环境前门的 F5 设备负责繁重的工作,提供诸如本地流量管理、全局流量管理、DNS 管理、Bot 防护、DDoS 缓解、SSL 卸载以及身份和访问权限管理等高级应用程序服务。 

DevOps >

DevOps 团队通常需要实施对负载均衡器的更改,以便引进新的应用程序、添加新功能至现有应用程序或扩大规模。在传统流程中,DevOps 必须依赖基础结构和运营 (I&O) 团队,以在生产中修改负载均衡器的配置并对其进行重新部署。 

运营 >

I&O 团队通常会采用谨慎的做法,因为他们必须利用集中式负载均衡器支持数百乃至数千应用程序。任何错误都可能对企业的整个应用程序格局产生灾难性的性能和安全影响。因此,I&O 团队首先会在测试环境中进行更改,然后最终将其投入生产。尽管这些操作规程有利于确保更改不会对应用程序产品组合产生负面影响,但是遵循这些规程行事可能放慢开发和变革的步伐。

解决方案

解决方案

您可以通过部署轻量级灵活负载均衡器提高软件交付和运行性能的速度,这些负载平衡器可以轻松地与更接近应用程序的应用程序代码集成。

F5 的云原生 ADC 解决方案 NGINX 是一种软件负载均衡器,能够帮助您弥合 DevOps 和 NetOps 之间的差异。  

运作方式 >

用于借助 NGINX 扩大 F5 BIG-IP 基础结构的常见部署模型有三种:

  • 在 F5 设备后面部署 NGINX,以充当 DevOps 友好型抽象层。
  • 针对每个应用程序乃至每个客户,预配 NGINX 实例。
  • 对于云原生应用程序,运行 NGINX 作为多云应用程序负载均衡器。

由于可编程的 NGINX 负载均衡器属轻量级,因此其仅会消耗很少的计算资源,并且几乎不会对基础结构造成附加压力。

结论

结论

将 F5 和 NGINX 负载均衡器分层,借此可以加快进入市场的速度,同时不会牺牲安全性和可靠性。

利用此方法,I&O 团队能够保留前端 F5 基础结构,以向需要保护和扩展的大量任务关键型应用程序提供高级应用程序服务。同时,您可以赋权 DevOps 和应用程序团队,以直接管理软件负载均衡器上的配置更改,通常是将这些配置更改作为 CI/CD 框架的一部分进行自动化。

组合式解决方案能让您实现应用程序团队所需的敏捷性和上市时间优势,而无需牺牲网络团队要求的可靠性和安全控制。