云就绪 ADC
云就绪应用交付控制器 (ADC) 不是传统的 ADC。它可用于部署在定制或 COTS 硬件上，是一种可扩展的软件解决方案，可满足快速、安全和可用的应用交付和部署需求。 云就绪 ADC 支持现代化的两层数据中心架构方法，将传统的稳定性、安全性和规模与现代的灵活性、云性和 DevOps 友好的编程功能相结合。
这是很好的描述，但它意味着什么呢？
我之前写过关于如何被视为现代应用代理的文章，这肯定是云就绪 ADC 所需的一部分，但当今苛刻的环境需要的不仅仅是技术能力，它还需要运营和生态系统集成以及支持现代和新兴应用架构的能力。
老实说，有许多 ADC 都会声称自己已经做好云就绪准备，并且支持传统和新兴应用架构，等等。 因此今天我想深入探讨一下云就绪 ADC 与传统 ADC 的不同之处，然后再进一步探讨为什么它在当今的应用世界中如此重要。
五种分化程度
云就绪 ADC 与传统 ADC 的区别基本上有五种（如果要说得更严谨一点，应该是六种）。而且，由于 F5 早在我加入之前就已明确定义了 ADC 应该是什么样子，因此我们比其他任何人都更了解 ADC。 他们既需要成为什么样子，又必须发展成为什么样子，才能继续提供满足业务所需的速度、安全性和稳定性的应用程序。
表现
这是毫无疑问的，对吧？ 毕竟，如果您要坐在应用程序前面并代理它们，那么您的速度最好比您交付的应用程序更快（或者更好，更快）。 传统 ADC 采用电器外形尺寸来交付。 底盘、五金、电器。 但传统 ADC 仍然受到其必须使用的定制硬件中的 CPU 的限制。 ADC 是平台，因此它们倾向于关注通用速度，就像通用 CPU 关注通用处理一样。 但它们几乎总是包含各种硬件加速选项，必须在部署之前确定。 现在我们可能疯了，但我们认为云就绪的 ADC 应该能够超越这一限制，理解一个应用程序可能比另一个应用程序更需要一项服务，而不同的应用程序可能比另一个应用程序更需要其他服务。 就像按需重新利用计算的概念支撑了整个云计算概念一样，投资任何类型硬件的组织也应该能够重新利用它。
这在网络顶层服务中很重要的原因是将常见任务卸载到特定硬件（FPGA）意味着 CPU 可以释放出来做其他事情，比如请求/响应检查、修改、清理等……这使得代理处的整个“停止”速度更快，从而降低延迟并提高用户满意度。
这就是为什么云就绪 ADC 可以打破障碍，利用软件定义的性能并允许组织以编程方式提高 ADC 在某些类型处理（如安全性）中的性能。 这意味着如果组织的需求发生变化，那么该硬件的性能配置也可以随之按需改变。 这就是硬件的灵活性。 我知道，这很矛盾，对吧？ 但这是云就绪 ADC 的一部分；能够重新利用专用硬件，从而保护投资，并消除昂贵的叉车式升级的需要。
可编程性
我个人从客户那里一次又一次听到的一个长期不满就是，在脚本功能方面，NetOps 和 DevOps 之间存在不一致。 问题在于，传统的 ADC 仅提供最基本的脚本，并且使用的是 NetOps 更熟悉的语言，而不是 DevOps。 现在，DevOps 愿意学习利用数据路径中的脚本，因为它可以实现各种更灵活的请求/响应路由、扩展策略甚至安全服务。 但是，由于传统的 ADC 位于核心网络的上游，因此 NetOps 不会让 DevOps 部署可能会干扰流量的脚本。
虚拟版本的出现意味着 DevOps 现在可以以虚拟机的形式访问他们自己的、个人的、私有的 ADC，但他们仍然被迫学习网络脚本语言。 这不是一件好事。 云就绪 ADC 应该同时支持核心网络中的 NetOps 和应用网络中的 DevOps（例如在云端）。 尤其是 DevOps 和开发人员更喜欢开发友好的语言，比如 node.js。 不仅因为他们了解该语言，而且已经存在丰富的库（如NPM ）和服务，可以实现与开发友好型基础设施的更快集成。 这就是为什么云就绪 ADC 应该同时支持两者。
应用程序安全
传统的 ADC 长期以来一直提供基本的应用安全性。 位于应用程序（尤其是 Web 应用程序）前面意味着它们通常是（现在仍然是）数据中心中第一个能够识别攻击并采取措施的东西。 可以理解的是，大部分安全性都围绕协议级安全性。 SYN 洪水保护、DDoS 检测以及其他 TCP 和基本 HTTP 相关的安全选项已经成为传统 ADC 不可或缺的一部分。
但云端 ADC 还应该走得更远。 它们很可能是应用程序架构本身中包含的少数“设备”之一，以确保当今应用所需的不可避免的规模，因此关注全栈安全性是有意义的。 至少我们这么认为，尤其是因为这样做可以提高绩效。 如果您必须停下来进行某种处理，那么同时进行尽可能多的处理才是有意义的。 它更加高效，并且消除了从一个盒子到另一个盒子传输所需的延迟。 如果您曾带着孩子长途旅行，您就会明白我在说什么。 加油站有卫生间。 您不想五分钟后再次停在休息站，对吗？ 网络安全也是一样。 尽量一次性消除经常让客户和企业感到沮丧的开销。 性能至关重要，云就绪的 ADC 应该竭尽全力确保更快的应用体验。
这可能意味着提供新的模型来管理日益增长的需求（在某些情况下是要求），以支持移动设备和应用程序之间的安全通信。 这意味着支持前向保密（FS）及其实现的加密技术。 这意味着启用新模型，将计算成本高昂的加密和解密处理转移到专门设计用于处理它的硬件上，而不会破坏支持微服务和新兴应用所需的架构。 云就绪 ADC 应该同时支持这两种功能，既能实现快速、安全的通信，又能无缝融入当今的架构和云环境。
合作伙伴生态系统和自动化
其他 API 经济对于私有云的成功以及通过提高自动化和编排为企业带来的竞争优势至关重要。 但无论它有多好，数据中心总是会有来自不同供应商的各种服务，而且所有的服务都有不同的集成和对象模型。 这通常意味着痛苦的 API 驱动的自动化，需要每个必要组件的专业知识。 实际情况是，需要两个级别的集成，一个用于编排，一个用于自动化（不，它们不是一回事） 。 该平台通过 API 和模板具有固有的自动化功能，然后可以本机集成到合作伙伴生态系统中，其中编排占据主导地位。 两者都是云就绪 ADC 所必需的。前者通过专有产品或自定义脚本和框架（如 Puppet 和 Chef）确保自动化，而后者通过越来越重要的控制器（如 OpenStack、VMware 和 Cisco）实现编排。
云就绪 ADC 应通过所使用的框架和系统本地集成并提供编排，以提供全面的编排解决方案。
无需多言，云就绪 ADC 应该支持云模板。
关于这个，我要说的就这些。
应用模型
传统 ADC 的诞生源于为传统应用提供一套强大服务的需求。 如果你愿意的话，可以称之为巨石。 当今的应用日益分散、多样化，且与传统的应用程序不同，利用了各种架构、平台和部署模型。 无论是容器还是虚拟机、云还是类似云的环境，应用仍然需要其中一些服务。 如果同时需要多个服务（例如，负载均衡和应用安全），那么您就会发现需要 ADC。虽然传统 ADC 可能不适合微服务，但云就绪 ADC 可以。 这包括可能受益于负载均衡和安全性的更广泛的服务，这些服务完全属于 devops 的范畴，而不是 netops，例如memcached 。
尽管云就绪 ADC 仍然是一个平台，但它仍然支持可编程性、集成性和外形尺寸要求，以便在传统和新兴应用所需的环境中提供它们所需的服务。
传统 ADC 与云就绪 ADC 有很多相似之处。两者仍然是平台，能够通过通用运营模型支持多种服务。 两者都是可编程的，可以与其他数据中心和云系统集成，并提供性能方面的灵活性。 但云就绪 ADC 超越了传统 ADC，它支持两者，同时满足未来业务和应用及其日益多样化的与各种基础设施和环境集成和互操作的需求。