F5 iApps： 将application交付转移到网络之外
当今的企业要求网络内更高水平的应用感知和管理。 数据中心是为了提供应用和服务而建立的，但它们仍然作为大型网络进行管理，并且各个网络组件作为独立的单点设备进行管理。 例如，传统路由器的管理就好像它只是在虚空中路由 IP 流量一样。 然而，应用完全依赖该路由器才能按预期工作。 目前，大多数企业将组织和数据中心网络视为一系列由各个团队管理的单独对象，但缺乏对这些组件之间以及与基础设施其余部分之间如何相互关联，或者这些组件如何协同工作以向用户提供应用的总体了解。
将整个基础设施作为单独的组件进行管理会妨碍 IT 工作，因为它需要不同组内有太多移动部件才能充分管理和控制向用户以及数据中心内的其他服务交付应用。 因此，IT 部门通常拥有复杂的电子表格，详细说明哪些组件在网络级别执行哪些操作，但没有关于这些组件如何与应用绑定的信息。 这种复杂而孤立的基础设施视图对数据中心管理、故障排除和自助服务配置等敏捷模型构成了挑战，因为人们不了解基础设施组件如何组合在一起来交付应用。
虽然这种对数据中心的过时看法仍然影响着许多组织的管理，但应用正在不断发展，并占据着中心地位。 这种转变迫使企业 IT 部门开始以应用程序为中心的视图进行管理，而不是从设备和对象开始，将组件拼凑在一起来交付应用。 这种转变很大程度上是由云计算和软件即服务 (SaaS) 的采用推动的，其中应用成为最重要的组件并且基础设施变得商品化。
然而，如今管理应用比五年前复杂得多。 在后端，应用现在可以驻留在任何地方，无论是在企业数据中心内部还是外部。 管理员可以在不同的云提供商之间部署应用程序，将其作为 SaaS应用运行，甚至在不同大陆的数据中心之间进行地理分布。 随着虚拟化的发展，数据中心正在摆脱一对一、服务器到应用程序的模式；资源在减少，而服务却在不断增长。 应用本身也正在转向数据更加丰富的模型，并依赖于通过 API 进行应用程序间通信，从而增加了系统和网络资源需求。 尽管企业 IT 消费化正在快速发展，应用程序为王，但基础设施却尚未适应。 管理应用交付不仅仅涉及网络组件，还涉及上下文，以及了解用户如何实时与应用交互。
F5 iApps 是 BIG-IP 系统中一组强大的新功能，它提供了一种在数据中心内构建应用交付的更好方法。iApps 植根于一种以应用为中心的整体方法，该方法涉及如何在数据中心内部、外部和外部管理和交付应用。iApps 技术在 BIG-IP 系统中提供了一个框架，该框架提供了有关支持业务的应用服务的上下文视图和高级统计数据。 有了它，应用、安全、网络、系统和运营人员可以统一、简化和更有效地控制应用交付服务。
iApps 抽象了交付应用所需的许多单个组件，并将这些资源分组到与特定应用程序相关的模板中。 这减轻了管理员管理网络上离散组件的需要。
大多数企业 IT 部门将网络各个部分的管理职责委托给不同的团队： IP 地址、路由和 DNS 由网络团队管理；物理和虚拟服务器、操作系统构建和病毒管理由服务器团队负责；API 交互、应用标准和访问权限由应用和安全团队负责。 因此，IT 部门内通常没有一个单独的团队可以回答这个问题：“在您的组织中传递电子邮件需要哪些组件以及每个组件是如何配置的？” 不协调的活动部件实在太多了。
iApps 通过从应用程序为中心的角度管理一切来改变这种状况。 节点、应用监视器、池——通过 iApps，这些应用交付服务组件可以聚集在一起并作为应用工作流的一部分进行管理。 这使得应用和网络管理员能够通过自动执行关键管理任务轻松定义成功交付应用所需的基础设施组件。
除了配置和管理应用交付服务之外，iApps 还可以定义自动化任务，例如部署其他应用交付资源。iApps 依靠 BIG-IP 系统的许多不同部分来管理应用交付的所有部分，从通过 F5 的 iRules 引擎为 AAA 安全基础设施应用负载均衡规则，到将应用诊断和可见性数据显示给 F5 面向客户的支持门户 iHealth。
通过 iApps，所有应用交付服务组件都捆绑在一起并被视为应用的扩展。 例如，新的 SharePoint应用将需要特定的健康监视器来检查 SharePoint 的 Web 前端、搜索和数据库组件的状态。 传统上，这些组件需要单独分配和管理，这很容易导致错误，并大大增加部署时间。 通过 iApp for SharePoint，所有这些部分都成为应用本身的组件，并且可以在一个集中位置进行部署和管理。
从本质上讲，iApps 由几个独立的组件组成，每个组件负责管理部分应用交付基础设施。 这些组件结合在一起，构成了统一的 BIG-IP应用交付控制器 (ADC) 的一部分。
iApps 通过创建 iApps应用服务将应用组件捆绑在一起进行交付，这些应用服务可以在交付期间应用于应用的任何部分。 例如，SharePoint 的 iApps应用服务最初可以与 BIG-IP 本地流量管理器 (LTM) 策略和一套 SSL 相关的 iRules 相关联。 稍后，管理员可以通过选中单个 iApps 框将 BIG-IP 访问策略管理器 (APM) 访问策略与相同的 iApps应用服务 (适用于 SharePoint) 关联起来，然后将其重新分发到整个网络中。iApps应用服务通过提供对整个应用交付基础设施的洞察，将应用和网络依赖关系绑定在一个统一的系统中，从而降低运营成本。
与面向对象编程改变应用编写方式的方式类似，iApps应用服务改变了典型应用交付服务置于应用“前端”的范式。iApps应用服务可以在交付过程中的任何时间应用于应用交付链的任何部分，这使组织能够选择应用的哪些部分受哪些服务组件的影响以及在何时受影响 — 所有这些都基于上下文。iApps 策略不仅限于构建负载均衡配置。 作为整个 BIG-IP 统一 ADC 平台的一部分，iApps 策略还可以包括高级 BIG-IP 系统模块和功能的配置设置，例如使用 BIG-IP APM 为应用分配用户访问策略。
访问模板是 iApps 最引人注目的优势之一。 尽管自版本 10 以来，BIG-IP LTM 中就已经提供应用模板，但它们仅限于新应用的初始部署阶段。 此外，他们无法修改以后的运行配置。
iApps 模板灵活且易于使用，可用于部署和管理应用服务 - 它们充当跨所有 BIG-IP 系统模块构建、管理和监控应用的单点界面。 当管理员使用现有模板构建新的 iApps 配置时，生成的配置将用于设备服务集群中的所有 BIG-IP 设备，并为 F5 Analytics 提供必要的信息。
除了 BIG-IP系统配置和管理之外，iApps 模板还允许 IT 内的多个团队定义交付和管理应用所需的所有设置。 跨职能的架构师团队可以定义应用参数——从提供 IP 地址信息的网络团队，到配置缓存和压缩策略的应用团队，再到定义用户和区域访问策略的安全团队——并在 iApps 模板中推出程序。 然后，他们可以将模板交付给 IT 运营部门，以便在测试或生产 BIG-IP 设备中进行部署。 一旦建立，iApps 模板就可以由适用的组进行修改，并随着业务和 IT 需求的发展在整个组织内重复使用。
iApps 的另一个主要优势是消除了在 ADC 和整个基础设施上部署新应用的“主题专家”障碍。 应用所有者不再需要考虑部署单独的 BIG-IP LTM 设备以实现可用性或部署 BIG-IP ASM 设备以实现安全性。 利用 iApps，应用所有者只需将这些服务添加为 iApps应用配置的一部分，BIG-IP 平台就会部署相应的服务以及与该服务相关的所有移动部件。 应用所有者通常花费大量时间来配置通过 BIG-IP 系统设备交付的应用。 使用 iApps 模板，前期工作可以在整个组织内重复使用。 可定制的 iApps 模板可帮助组织节省运营费用，只需对应用策略进行一次微调和测试，然后通过导出配置并与其他 BIG-IP 设备和其他 IT 组织共享来重复使用该工作即可。
iApps 配置策略旨在可在 BIG-IP 系统之间和用户之间移植。iApps 模板可以根据每个应用程序导出并在整个应用网络中重复使用。 此外，它们还可以通过 F5 社区网站 DevCentral 上的 iApps 生态系统进行导出和共享，BIG-IP 系统管理员和开发人员可以在其中创建、修改和共享自己的用于其他应用的 iApps 模板，或者调整现有的 iApps 模板。
F5 定期通过 DevCentral 上的 iApps 生态系统发布适用于新应用的官方 iApps 模板；这利用了来自 F5 合作伙伴（例如 Microsoft、IBM 和 Oracle）的新应用工程工作，以及特定于金融、政府和医疗保健等垂直市场的应用模板。
iApps 策略的主要内容是配置交付应用所需的流量管理组件。 但是，BIG-IP 平台还包括用于监控应用的工具，并提供实时应用性能统计数据。 它还提供诊断和故障排除信息，例如应用响应时间、网络延迟以及整个应用、虚拟服务器、池和节点的连接统计信息。
与传统监控工具不同，F5 Analytics 在应用级别收集性能数据，将信息绑定到应用本身而不是单个基础设施组件。 应用所有者可以通过应用服务器一直到网络监控应用的性能。 这使得组织能够根据应用响应、网络条件和用户环境准确监控应用的实时运行情况。
F5 Analytics 利用来自 BIG-IP 系统的统计和日志数据。 它获取这些数据并将其格式化为 JSON 对象，然后将其导出以供数据消费者（例如 F5 BIG-IQ）或应用（例如 Splunk）使用。
使用 F5 Analytics，您可以配置要导出的几类数据。 对于像 Splunk 这样的数据消费者，它允许您配置发送数据的网络端点。
数据中心硬件设备通常以冗余对的形式运行，可以是主动/待机模式（一个系统管理 100% 的任务，而另一个系统等待第一个系统离线后再接手这些任务），也可以是主动/主动模式（两个系统都在设备之间分配工作负载）。 这两种冗余配置对于任何关键任务硬件部署来说都是最佳实践，但它们都存在一个主要的设计缺陷：这种冗余架构是基于整个设备故障的。
更好的方法是根据设备在应用交付过程中任何时候所做的事情来构建容错架构，而不是根据整个设备是在线还是宕机来构建。 BIG-IP 设备在应用级别实现了可扩展、容错的架构，为设备之间的应用程序配置创建了故障转移保护。 BIG-IP 设备服务集群以两种不同的配置选项运行： 仅同步和同步故障转移模式。
BIG-IP 设备服务集群仅同步模式允许多个 BIG-IP 硬件和软件设备在设备之间动态共享特定于应用程序的交付配置和模板。 这样，每当发生变化时，管理员就无需手动更新完整的设备配置。 由于 BIG-IP应用策略与硬件配置分开，管理员可以在设备之间同步应用和网络信息，而不是复制整个 BIG-IP 配置文件。 这使得 IT 能够运行具有不同配置的不同 BIG-IP 设备，但仍可在这些设备之间同步独特的应用程序配置和策略。 例如，BIG-IP应用安全管理器 (ASM) 策略可以在 BIG-IP 设备之间同步，而不会影响每台设备上的其他应用策略，也不需要安全团队在每台设备上手动安装单独的 BIG-IP ASM 策略。
除了设备之间的同步之外，应用配置还可以对设备之间的活动和实时应用流量进行故障转移，将主动/主动概念带入应用层。 BIG-IP 设备服务集群同步故障转移模式将 1:1 主动/主动概念扩展为 N:1，其中尽可能多的主动设备可以根据资源限制和可用性共享应用负载。 这与 RAID 5 条带化的理念非常相似，其中可以根据需要和冗余度确定磁盘的数量。
由于需要更多的应用交付资源，管理员可以将活动的 BIG-IP 设备添加到设备服务集群中。 集群承担了部分整体应用交付负载，而无需添加第二个专用备用设备，以防新设备离线。 利用 BIG-IP 设备服务集群，当某个设备离线时，组内的每个新设备都能够承担一定程度的冗余，以承担额外的应用负载。 成为设备服务集群一部分的 BIG-IP 设备越多，应用负载在所有可用设备之间分配的效率就越高。
iApps 的两个关键原则是可视性和控制。iApps 在整个基础设施中提供了前所未有的可视性和控制水平；但是，它提供的可视性和控制程度取决于它所处的战略点，在这个战略点上，所有应用交付逻辑都可以动态地应用于所有双向应用流量，并在用户、应用和数据之间建立一个协调的中介层。 该层提供了一致的接口和服务集，可用于所有应用和数据，而不管它们当前位于何处。 通过对上下文的智能理解（谁在何处访问什么以及为什么访问），该层可以确定用户、应用和数据之间的最佳连接。 此外，它还提供对上下文的深入了解，以告知底层应用和数据元素当前的资源需求，并指示基础设施实时适应，以确保优化应用和数据访问。
这种应用信息的战略流成为 iApps 配置的一部分。 iApps 模板的初始配置基于如何在理想架构中交付应用；应用在整个交付生命周期中通过 iApps 模板和 BIG-IP 设备服务集群进行管理，提供什么和在哪里。 F5 Analytics 带来了原因部分，并将该信息报告回 IT 进行分析。iApps 处于战略控制点 — — 这是唯一允许进行如此细粒度和广泛的应用交付管理的地方。
随着企业转向更加模块化的云和 SaaS 模型，管理应用变得比构建基础设施更为重要。 转向更敏捷的模型所带来的许多好处与管理基础设施无关；然而，管理云和 SaaS 环境中的应用部署、性能和可用性通常很困难，因为应用仍然与基础设施紧密相关。iApps 将应用程序控制、可视性和管理与在数据中心之外交付这些应用和服务所需的基础设施绑定在一起。
iApps 支持的架构将网络从由孤立组件组成的静态资源转变为与应用或服务直接相关的统一、灵活且有弹性的资源池。 这种转变实现了应用层的快速网络部署、集成、管理和可见性。iApps 通过使网络适应应用应用，提供了对整个应用交付基础设施的完全控制。 由此产生的快速部署和单点功能节省了运营成本。 借助 F5 iApps，企业可以在战略控制点创建通用且高度可重复使用的安全性、加速和可用性服务目录，从而大幅提高 F5 BIG-IP 设备的组织灵活性和效率。
