构建下一代 NGINX 体验，专为现代应用的现实而设计

作为 NGINX 的产品副总裁，我经常与客户和用户交谈。 无论您是平台运营团队、Kubernetes 架构师、应用开发人员、CISO、CIO 还是 CTO – 我都曾与像您这样的人交谈过。 在我们的交谈中，您向我讲述了对 NGINX 的真实想法，包括我们的产品、定价和许可模式，强调了我们的优势和劣势。

我们学到的核心道理是，我们的“NGINX是宇宙的中心”的方法不能很好地服务于我们的用户。 我们一直在构建旨在使 NGINX 成为“平台”的产品——与应用部署相关的一切的统一管理平面。 我们知道，我们之前为实现这一目标而推出的一些产品并未得到充分使用和采用。 您告诉我们，NGINX 是您现有平台（无论是自主研发的还是其他平台）的关键任务组件，但 NGINX 不是平台。 因此，我们需要更好地与其他组件集成，以便更轻松地部署、管理、保护我们的产品以及（这很重要）透明的定价和消费模式。 当然，通过 API 可以实现这一切。

其潜在的信息很简单：让您更轻松地以不带偏见的方式将 NGINX 集成到您的工作流、现有工具链和流程中。 我们听到了您的声音。 2024 年，我们将采用更加灵活、简单、可重复和可扩展的方法来实现数据平面和安全的用例配置和管理。

你的愿望完全合理。 您的世界已改变并且继续改变！ 您经历了各个阶段的转变，从云到混合，再到多云和多云混合设置。 也发生了从虚拟机到 Kubernetes、从 API 到微服务和无服务器的变化。 你们中许多人已经向左转，这导致了复杂性。 更多团队拥有更多工具，这些工具需要更多的管理、可观察性和强大的安全性——所有这些都支持必须能够在几分钟内扩展的应用程序，而不是几小时、几天或几周。 最新的加速器人工智能（AI）给传统的应用和基础设施架构带来了巨大的压力。

我们计划在即将发布的 NGINX 产品中解决哪些问题

虽然 NGINX 产品的核心一直是坚如磐石、久经考验、性能卓越的，但我们的用户使用、管理和观察 NGINX 各个方面的方式却没有跟上时代的步伐。 我们正在迅速采取行动，通过推出新产品和一系列新功能来解决这个问题。 我们将在 2 月 6 日至 8 日举行的 F5 大会AppWorld 2024上宣布更多有关此消息的信息。 以下是我们计划在即将发布的产品中解决的具体痛点。

痛点#1： 由于部署环境的多样性，现代应用程序的管理具有挑战性

如今，首席信息官和首席技术官可以从各种各样的应用部署模式中进行选择。 这是一件好事，因为它在性能、功能和弹性方面提供了更多的选择。 这也是一种祸害，因为多样性会导致复杂性和蔓延。 例如，管理在 AWS 中运行的应用与管理 Azure 云中的应用所需的配置、工具和部落知识不同。

虽然容器已经标准化了大量应用部署，但容器下方的所有内容（或进出容器的内容）仍然存在差异。 作为事实上的容器编排平台，Kubernetes 应该清理这一过程。 但是任何在 Amazon EKS、Azure Kubernetes Service (AKS) 和 Google Kubernetes Engine (GKE) 上部署过的人都会告诉你——它们完全不一样。

您告诉我们，在如此多样化的环境中管理 NGINX 产品需要大量的运营资源，并会导致浪费。 坦率地说，基于年度许可的定价模型在动态环境中会崩溃，您可能会在无服务器环境中启动应用程序，在 Kubernetes 环境中扩展它，并维护在云上运行的小型内部部署以用于开发目的。

痛点＃2： 在多种环境中运行并跨许可证类型的应用程序的安全具有挑战性

多样化环境的复杂性可能使发现和监控现代应用程序的部署位置以及应用正确的安全措施变得困难。 也许您已部署NGINX Plus作为全局负载均衡器，并将NGINX Open Source用于各种微服务，每个微服务都在不同的云中或不同类型的应用之上运行。 此外，他们可能对隐私、数据保护和流量管理有不同的要求。
每次排列都会增加新的安全变化。 没有标准、全面的解决方案，这会增加操作复杂性和配置错误的可能性。 不可否认的是，我们让哪些类型的安全性可以应用于哪些 NGINX 解决方案变得混乱，这增加了复杂性。

我们明白。 客户需要一种单一方法来保护所有利用 NGINX 的应用。这种统一的安全解决方案必须涵盖绝大多数用例，并在所有云、本地、无服务器和其他环境中部署相同的工具、仪表板和操作流程。 我们还认识到转向更智能的安全方法的重要性，利用 NGINX 社区的集体智慧和我们有幸拥有的前所未有的全球流量视图。

痛点3： 管理现代应用程序的成本非常复杂，而且会导致浪费

在左移的世界中，每个组织都希望让开发人员和从业者能够更好地完成工作，而无需提交工单或发送 Slack。 但事实却并非如此。 通过 Kubernetes、无服务器和其他用于管理分布式应用以及跨本地、云和多云环境的应用的机制，已经实现了一些复杂性的边缘抽象。 但这种进展很大程度上还局限于容器和应用领域。 它无法很好地转换到网络、安全和可观察性等应用层，也无法很好地转换到 CI/CD。

我在前面的痛点中已经暗示过这些问题，但底线是：复杂性会浪费大量时间和精力，损害安全性和弹性，从而带来巨大的成本。 维护日益复杂的系统从根本上来说具有挑战性并且需要大量资源。 定价和许可证的复杂性又增加了一层不愉快的因素。 NGINX 从来都不是一个在用户错误地过度消费时会向用户追究责任的“负责任”的公司。

但是在 SaaS、API 和微服务的世界中，您希望按使用量付费，而不是按年付费，也不是按席位或站点许可证付费。 您需要一个基于消费的易于理解的定价模型，适用于所有 NGINX 产品和服务，涵盖您的整个技术基础设施和应用组合。 您还需要一种方法来整合您的团队所运行的任何开源模块的支持和安全性，只需为您需要的部分付费。

这将需要 NGINX 对产品的包装和定价方式做出一些改变。 最终的解决方案必须是简单、透明、按消费付费，就像任何其他 SaaS 一样。 我们听到了。 我们已准备好一些好东西，可以解决上述三个痛点。

欢迎参加 App World 2024

我们将在AppWorld 2024上讨论这些令人兴奋的更新，并将在未来十二个月内作为我们长期计划和路线图的一部分推出该解决方案的各个部分。

与我一起踏上这段旅程并关注 AppWorld 以全面了解商店中的内容。 早鸟价有效期至 1 月 21 日。 请查看AppWorld 2024 注册页面了解更多详细信息。 我们还邀请您于 2 月 6 日晚上与 NGINX 领导人及社区其他成员一起前往圣何塞 F5 办公室，共度一个展望 NGINX 未来、建立社区联系并尽享经典美食：披萨和礼品的夜晚！ 请参阅活动页面以了解注册和详细信息。

我们希望下个月在圣何塞见到您！