企业架构应用程序的方式已经改变。根据我们最近的用户调查，企业组合中 58% 的应用程序是单体应用程序，其中所有应用程序逻辑都作为单个单元打包和部署。这一百分比低于一年前的 65%，突显出企业转向更现代的应用程序架构的速度有多快。在同一项调查中，我们发现其余 42% 的应用程序完全或部分由微服务组成（其中应用程序的功能组件被重构为离散的打包服务）。此外，我们调查的组织中有 42% 已经在生产中使用微服务，40% 表示微服务对其业务战略非常重要。
很明显，微服务最初是 Google、Netflix 和 Facebook 等云原生公司的领域，现在已成为企业 IT 架构的支柱。您可以在我们关于微服务的开创性博客系列中阅读更多相关内容。它详细介绍了从整体架构到微服务的旅程，这从三个方面深刻影响了应用程序基础设施：
- 人员：控制权从基础设施团队转移到应用程序团队。 AWS 向业界表明，如果基础设施易于管理，开发人员将自行配置。然后，基础设施的责任就从专用基础设施和网络角色转移。
- 流程：DevOps 加快了配置时间。 DevOps 将敏捷方法应用于应用程序部署和维护。现代应用基础设施必须实现自动化，并且配置速度要快几个数量级，否则您将面临延迟关键修复和增强功能部署的风险。
- 技术：基础设施将软件与硬件分离。软件定义的基础设施、基础设施即代码和可组合基础设施都描述了价值从专有硬件转移的趋势dware 设备到商用硬件或公共云计算资源上的可编程软件。
这些趋势影响应用程序开发和交付的各个方面，但特别是它们改变了负载均衡器（有时称为应用程序交付控制器或 ADC）的部署方式。负载均衡器是位于所有应用程序以及越来越多的微服务前面的智能控制点。
弥合开发和运营之间的鸿沟
现在 NGINX 已成为 F5 的一部分，客户经常询问是否应该部署 F5 BIG-IP 或 NGINX Plus 和 NGINX Controller 作为负载平衡基础设施。为了回答这个问题，我们需要了解负载均衡器（ADC）是如何发展的。
从历史上看，负载均衡器是作为硬件部署在数据中心边缘的。该设备提高了其背后所有应用程序的安全性、性能和弹性。然而，向微型化的转变服务以及由此产生的应用程序基础架构人员、流程和技术的变化需要对应用程序进行频繁的更改。这些应用程序更改反过来又需要更改负载均衡器策略。
位于环境前端的 F5 BIG-IP 设备承担繁重的工作，提供高级应用程序服务，例如本地流量管理、全局流量管理、DNS 管理、僵尸程序防护、DDoS 缓解、SSL 卸载以及身份和身份验证访问管理——针对数百甚至数千个应用程序。强制对此环境进行不断的策略更改可能会破坏应用程序交付和安全性的稳定性，从而引入风险并要求您的 NetOps 团队花时间测试新策略而不是其他增值工作。此过程适用于 F5 BIG-IP 的所有外形尺寸，F5 BIG-IP 已发展到支持硬件、软件和云选项。所有这些都共享相同的架构：一个强大的、完全集成的系统提供丰富的应用程序服务的解决方案。
现代、快速变化的应用和微服务世界需要一种不同的方法。在此，我们建议企业双管齐下。首先，在前端保留 F5 BIG-IP 基础设施，以便为其负责保护和扩展的大量任务关键型应用程序提供这些高级应用程序服务。其次，通过将 NGINX 的轻量级软件负载均衡器（NGINX 控制器管理 NGINX Plus 负载均衡器的实例）直接放置在现代应用程序环境前面来增强该解决方案。
NGINX 与硬件和操作系统分离，使其成为应用程序堆栈的一部分。这使您的 DevOps 和应用程序团队能够直接管理软件负载均衡器并配置任何关联的应用程序服务，通常将它们作为 CI/CD 框架的一部分进行自动化。
结果呢？您可以实现应用团队所需的敏捷性和上市时间优势，而无需牺牲网络团队所需的可靠性和安全控制。
NGINX 软件负载均衡器是弥合开发（AppDev、DevOps）和运维（NetOps、SecOps）团队之间鸿沟的关键。大多数客户发现他们需要将部分或全部 F5 硬件迁移到 NGINX 软件。但如何选择正确的迁移策略呢？
合乎逻辑的第一步是使用 NGINX Plus 和 NGINX Controller 增强现有的 F5 BIG-IP。需要考虑三种常见的部署模型：
- 在 F5 设备后面部署 NGINX，充当 DevOps 友好的抽象层
- 为您的每个应用甚至每个客户配置一个 NGINX 实例
- 运行 NGINX 作为云原生应用的多云应用负载均衡器
由于 NGINX 是轻量级且可编程的，所以我它消耗的计算资源非常少，并且对您的基础设施几乎没有任何额外压力。
这种方法使您能够根据应用程序策略评估构建软件负载平衡所需的速度。迁移到基于软件的基础架构的速度取决于您迁移到包含微服务和云原生服务的现代应用程序架构的积极程度。为了提供帮助，我们整理了一系列资源来帮助您研究、评估和实施 NGINX。
帮助您从 F5 硬件迁移到 NGINX 软件的资源
第一阶段：研究 NGINX 作为 F5 的补充解决方案
该过程的第一阶段是了解部署 NGINX 作为附加负载均衡器的好处。如果您刚刚开始，我们建议您查看我们的：
视频：将您的硬件 ADC 从传统变为传奇 – 在 30 秒内了解企业为何如此正在从硬件负载平衡器迁移到软件负载平衡器。
博客：并非所有软件负载均衡器都是一样的 – 许多供应商提供软件负载均衡器，但它们与 NGINX 不同。这篇博客解释了原因。
博客：增强您的硬件负载均衡器以推动敏捷开发（和竞争优势！）——开发人员在当今竞争激烈的商业环境中占据主导地位。了解 NGINX 如何为他们提供支持。
客户成功案例：IgnitionOne 以最小延迟管理海量流量 – 了解 IgnitionOne 从 F5 迁移到 NGINX 以实现 5 倍容量并降低总体拥有成本 (TCO)。
第 2 阶段：评估 NGINX 的业务案例和迁移选项
现在您已经了解了基础知识，是时候构建 NGINX 的业务案例了。了解部署 NGINX 来增强 F5 解决方案的各种方法。向客户和 NGINX 专家学习：
白皮书：从 F5 BIG-IP 迁移到 NGINX Application Delivery Controller – 了解在 F5 BIG-IP 硬件后面、旁边或代替 F5 BIG-IP 硬件部署 NGINX 的优势。
客户成功案例：DataposIT 使用 NGINX Plus 和 NGINX Controller 为 NASCOP 实施分布式、可扩展架构 – 了解肯尼亚国家艾滋病和性传播感染控制计划 (NASCOP) 如何增强其 F5 基础设施以加速其混合云计划。
视频：戴尔如何使用 NGINX 实现 dell.com 上的 CI/CD 管道现代化 – 戴尔通过 NGINX 增强了其 F5 BIG-IP，为应用团队提供自助服务能力。
视频：NGINX 应用程序平台的 TCO – 了解如何量化 NGINX 的投资回报率和总拥有成本。请联系我们进行定制投资回报率计算。
第 3 阶段：实施 NGINX 并迁移 F5 BIG-IP iRules
做出投资决定后，就该卷起袖子部署 NGINX 了。无论你是否将全部或部分硬件迁移到 NGINX 软件时，您需要了解如何将 F5 BIG-IP iRules 转换为 NGINX 配置指令，以确保从前端 BIG‑IP 到后端 NGINX Plus 实例的应用程序服务的连续性。您还需要了解使用 NGINX Plus 和 NGINX Controller 的基础知识。
网络研讨会：NGINX 控制器：大规模配置、管理和故障排除 – 了解如何管理和监控 NGINX Plus 软件负载均衡器。
网络研讨会：NGINX：基础知识和最佳实践 – 了解如何充分利用 NGINX Plus 实例来补充您的 F5 投资的功能。
电子书：F5 BIG-IP 到 NGINX Plus：迁移指南 – 阅读此详细指南，了解如何将 F5 iRules 和其他配置轻松迁移到 NGINX Plus。
网络研讨会：从 F5 BIG-IP 迁移到 NGINX 应用程序交付控制器 – Wa将这篇姊妹篇添加到电子书中，了解从 F5 迁移到 NGINX 的技巧。
开始免费试用 NGINX 软件
NGINX 入门很简单。我们提供自动化试用体验。
请求免费试用 NGINX Controller（还包括 NGINX Plus），体验 NGINX 的强大功能以及额外的监控、管理和分析功能。对于不通过 API 管理网络基础设施或希望将 NGINX 应用平台评估为更类似于 F5 BIG-IP 的软件 ADC 的基础设施和网络团队来说，这是最佳选择。
我们很乐意与您讨论 NGINX 如何帮助您完成用例。
发表回复