弥合鸿沟： 规模和可靠性

生产不是为了失败而建立的。

传统的网络和应用服务架构即使出现故障也是可靠的。 冗余和故障转移是位于客户和组织最宝贵的资产（即应用）之间的基础设施的关键功能。

故障转移（真正的故障转移）不能通过简单地启动一个新容器来实现。 这种方法仅适用于设计为无状态的现代应用。 这很少是传统应用的特征，甚至现代应用程序也不一定具有这一特征。 企业级的规模和可靠性对于维持企业应用组合中剩余的大部分（传统应用程序）的可用性至关重要。

但这并不意味着我们应该忽视现代应用数量的增长。 每个新的应用程序架构都是从几个项目开始的，然后随着组织学习如何开发、部署和操作扩展和保护这些新应用程序所需的系统和解决方案而呈现爆炸式增长。 企业内部使用现代架构开发的全新应用的数量仍然很少，但正在快速增长。 如果组织想要在数字经济中保持领先，就必须这样做。

以applications速度构建架构

目前，超过五分之一的组织在其应用积压中拥有五十 (50) 个或更多的主要应用程序请求。 超过 61% 的企业的队列中有超过十 (10) 个新的应用请求。 传统的开发方法已无法跟上时代的步伐。 随着组织转向敏捷和微服务来帮助加速交付，更多基于现代架构的应用程序将会出现。

在此过程中，他们需要一种方法来弥合现代架构的规模和可靠性模型与实现企业级部署所需的严格规模和可靠性之间的差距。

这些现代架构通常包括 NGINX。事实上，可以说大多数新兴的现代架构在一个或多个角色上都依赖 NGINX。

NGINX 是容器中运行的十二大应用组件之一。在最顶级（老实说，是最顶级）的容器入口提供商中，你会发现 NGINX。在每一份关于云、容器和微服务的调查和数据报告中，你都可能在运行的组件列表中找到 NGINX。

NGINX 主要满足现代架构的扩展需求。 它为现代应用程序提供了可靠性，因为如果一个应用程序实例出现故障，NGINX 会注意到并将后续请求定向到其他应用程序实例。 它涵盖了容器环境中固有设计的故障。 它还满足了大多数 DevOps 和开发人员对应用正常运行时间的要求。

但这并不一定意味着扩展整个企业架构并确保其可靠性。 同样的“注定失败”的系统虽然对现代应用非常有效，但却不适合为传统应用程序和应用服务基础设施提供同样的功能。 差异的核心是“状态与有状态”模型。 现代应用程序的目标是无状态，因为这反过来使得架构能够发挥作用。 传统应用程序和网络本身都是有状态的。 故障会导致正在进行的交易和会话终止并破坏可用性。

现代可靠性

影响共享基础设施（占大部分）的生产故障的爆炸半径很大。 非常大。 负责数百个应用的交付和安全的网络和应用服务并非注定要失败，而是注定要可靠。 

在企业级规模和可靠性方面发挥作用的是 F5 和 BIG-IP。 BIG-IP 专为可靠性而设计，能够扩展以满足需求和大规模攻击，是超过 25,000 家企业交付应用程序的手段。 它满足了 NetOps 对网络和应用正常运行时间的要求。

通过将两者结合起来，无论定义如何，我们都能够满足“可靠”的要求。 无论是适用于扩展现代应用程序的小型、开发人员驱动的部署的可靠性，还是扩展应用服务和传统应用程序的大型部署，组合产品组合都将为客户提供为正确的应用程序使用正确的工具的能力。

有关 F5 与 NGINX 合作的优势的更多信息，请参阅 F5 首席执行官介绍“弥合鸿沟”博客系列的文章。