F5 在 DevOps 世界中的地位
在会议发言后，我经常被问到 F5 在竞选中到底有什么优势。 最近，该主题通常是 DevOps 或以某种方式与 DevOps 相关。
现实情况是，负载均衡等应用亲和服务正被拉向应用，进入构成应用网络的更灵活、软件驱动和自动化的环境。 这就是使用依赖大量自动化和编排的 CI/CD（持续集成/持续交付）方法部署计算和应用中心系统（如缓存（例如memcached和 redis）、数据库和容器）的地方。
F5（更具体地说是 BIG-IP）几乎与负载均衡同义。 我们从世纪之交之前就一直在做这件事，事实上，您今天在其他负载均衡器中使用的许多核心负载均衡算法和概念都是在这里发明的。 因此，说我们对负载均衡应用有所了解，这只是轻描淡写。 我们通过部署在定制硬件甚至云端的软件来实现这一目标。
该软件启用了 API。它被称为iControl ，提供 SOAP 和 REST 两种版本，方便您进行编程。 该 API 允许任何人（甚至我）为任何应用调配、配置和控制 BIG-IP 的负载均衡（和其他）服务。
现在，正如我所说，应用程序亲和服务每天都在向应用转移。 可扩展性——负载均衡——就是这些服务之一。 如今，它已成为任何应用的关键组件，而且对于构成现代应用的微服务而言，它的作用也越来越重要。 正如微软在 2015 年关于扩展服务的论文中指出的那样：
在存在多种多样且丰富的机器的情况下，开发人员被迫考虑对应用工作负载进行分区，以及支持每种分区方案所需的网络连接。 连接的一个非常重要的方面存在于外部用户和服务本身之间。 除了最小的服务外，还需要某种形式的负载均衡机制来分配 FE 盒上的传入连接的负载。 许多大型服务还包含子服务，这些子服务本身也经过了负载均衡。[强调]
负载均衡并不是事后才想到的；它是当今应用和服务的自然补充，具有让用户满意和业务正常运转所需的规模（和可靠性）。 这使得负载均衡成为整个应用架构的一部分这一点越来越真实。 事实确实如此，因为向应用架构中添加任何组件都可能引入需要克服的问题或集成问题。 这些问题需要在应用程序投入生产之前解决，而不是之后。 在生产中查找和修复问题所需的时间比在开发或测试环境中要多很多倍，因此在应用架构中包含负载均衡意味着更顺畅（和更快）地过渡到生产和用户手中。
但这意味着您需要能够将负载均衡器集成到 DevOps 工具链自动化的流程中，从而不断推动开发和测试环境中的集成和交付。 这意味着提供一套全面的编程工具，如 API 和模板，使得将基础设施视为代码并自动化其配置和配置成为可能。 这就是 iControl（REST 或 SOAP）为 F5 所做的事情。
通过使用您喜欢的任何语言（包括Powershell 、 Python和 Perl），或者通过Chef和Puppet等框架以及Ansible和SaltStack等工具，BIG-IP 可以集成到部署、测试和发布阶段的 DevOps 中。iApps是我们描述应用服务配置的模板，可以像代码一样处理：将其存储在 Github 中，按原样检索和部署，或者使用脚本对其进行自定义。
基本上，BIG-IP应用服务（例如负载均衡）及其许多应用性能和安全服务应在 CI/CD 流程中尽早集成，以确保这些关键服务能够按照预期与应用无缝协作。
最终，我们将看到越来越多的传统“网络”设备融入 DevOps 世界，因为更快、更频繁、更少中断地移动应用的压力继续推动企业和 IT 领导者进入应用经济。
要深入了解可以与 BIG-IP 一起使用的 DevOps 工具，请查看 DevCentral 上的这篇文章“ F5 Friday”： DevOps 工具和 F5 ”