作为NGINX产品副总裁，我经常与客户和用户交流。无论您是平台运维团队成员、Kubernetes架构师、应用开发人员、首席信息安全官（CISO）、首席信息官（CIO）还是首席技术官（CTO），我都曾与和您角色相似的人交流。在交流中，大家坦诚分享了对NGINX的看法，包括对我们的产品、定价和许可模式的意见，既肯定了我们的优势，也指出了不足。
我们得到的核心启示是，以“NGINX为中心”的做法并不能很好地满足用户需求。此前，我们一直致力于打造以NGINX为“平台”的产品，也就是为应用部署相关的一切提供统一管理平面。我们知道，之前为实现这一目标而推出的一些产品使用率和采用率并不高。大家告诉我们，无论现有平台是自行开发还是采用其他方式构建，NGINX都是其中的关键任务组件，但NGINX本身并不是整个平台。因此，我们需要更好地与平台中的其他组件集成，让产品更易于部署、管理和保护，同时提供透明的定价和用量模式，这一点非常重要。当然，所有这些都应能通过API实现。
核心诉求很明确：让您能够以不受特定方式限制的方式，更轻松地将NGINX集成到工作流、现有工具链和流程中。我们听到了您的反馈。2024年，我们将采用更灵活、简单、可重复且可扩展的方法，针对数据平面和安全用例进行配置与管理。
您的诉求完全合理。您所处的环境已经发生变化，而且仍在不断变化！您经历了多个阶段，从云环境转向混合云、多云以及多云混合架构；从虚拟机转向Kubernetes，从API转向微服务和无服务器架构。许多团队已采用左移策略，但这也增加了复杂性。越来越多的团队使用越来越多的工具，需要投入更多精力进行管理和可观测性监控，并提供强大的安全防护。这些工具共同为应用提供支持，而应用必须能够在几分钟内完成横向扩展，而不是几小时、几天甚至几周。最新的加速因素人工智能（AI），也给传统应用和基础设施架构带来了巨大压力。
我们计划在即将发布的NGINX产品版本中解决的问题
NGINX产品的核心一直坚实可靠，经过实战检验且性能出色，但用户使用、管理和观测NGINX各个方面的方式未能与时俱进。我们正通过发布新产品和推出一系列新功能，迅速改善这一状况。我们将在F5于2月6日至8日举办的大会AppWorld 2024上公布更多相关信息。以下是我们计划在即将发布的产品版本中解决的具体痛点。
痛点1：部署环境多样，现代应用管理面临挑战
如今，CIO和CTO可以从多种应用部署模式中进行选择。这带来了优势，因为在性能、功能和韧性方面有了更多选择；但也带来了挑战，因为多样性会导致复杂性增加和环境无序扩张。例如，管理在AWS中运行的应用，与管理在Azure Cloud中运行的应用，需要采用不同的配置和工具，并依赖不同的团队经验。
尽管容器已使大部分应用部署实现标准化，但容器底层的一切（以及进出容器的一切）仍存在差异。作为事实上的容器编排平台，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上介绍这些令人期待的更新，并将在未来12个月内，按照长期计划和路线图逐步推出该解决方案的部分功能。
欢迎与我一同踏上这段旅程，并关注AppWorld，全面了解未来规划。早鸟优惠价截至1月21日。更多详情，请查看AppWorld 2024注册页面。此外，诚邀您于2月6日晚前往F5圣何塞办公室，与NGINX领导者及其他社区成员齐聚一堂，共同展望NGINX的未来、增进社区交流，并享用经典组合：披萨和周边礼品！有关注册及活动详情，请查看活动页面。
期待下个月在圣何塞与您见面！
相关博客文章
NGINX Plus R26 正式发布
NGINX Plus R26通过缓存JSON Web密钥集加快JWT验证，并强化TLS握手，从而提升安全性。NGINX JavaScript的新功能包括增强对异步函数的支持，以及实现WebCrypto API。
使用NGINX App Protect DoS保护gRPC应用，抵御严重的DoS攻击
gRPC具备开发人员设计和部署现代应用所需的速度与灵活性，但其开放性也使其极易受到第7层DoS攻击。NGINX App Protect DoS可保护gRPC应用免受此类破坏性攻击。
Ingress Controller 选型指南（第 2 部分）：风险与面向未来的规划
了解选择错误的Ingress控制器可能带来的风险，以及如何从关键方面着手，让您的选择更好地适应未来需求。
NGINX Plus R19 正式发布
NGINX Plus R19扩展了监控功能，不仅提供更多指标，还新增了指标分析方式；增加试运行模式，用于测试限速效果；增强键值存储，以支持IP地址范围；并使限速更加动态。
NGINX现已正式加入F5
NGINX现已正式成为F5的一部分。Gus Robertson现任F5 NGINX业务部门负责人。他阐述了两家公司在人才、文化和愿景方面融合的价值，以及双方将如何携手增强NGINX的开源产品和商业产品。
