El ADC preparado para la nube

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Un controlador de entrega de aplicaciones (ADC) preparado para la nube no es un ADC tradicional. Disponible para su implementación en hardware personalizado o comercial (COTS), es una solución de software escalable que satisface la necesidad tanto de una entrega como de una implementación de aplicaciones rápidas, seguras y con alta disponibilidad. Un ADC preparado para la nube permite adoptar un enfoque moderno de dos niveles para las arquitecturas de centros de datos, que combina la estabilidad, la seguridad y la escalabilidad tradicionales con funciones programáticas modernas, flexibles, orientadas a la nube y compatibles con DevOps.

Es una buena descripción, pero ¿qué significa?

Ya he escrito anteriormente sobre lo que hace falta para que se considere un proxy de aplicaciones moderno y eso es, sin duda, parte de lo que requiere un ADC preparado para la nube, pero los exigentes entornos actuales necesitan algo más que capacidades técnicas: necesitan integración operativa y con el ecosistema, así como la capacidad de admitir arquitecturas de aplicaciones modernas y emergentes.

Y, sinceramente, hay muchos ADC en el mercado que afirmarían igualmente estar preparados para la nube y ser compatibles tanto con arquitecturas de aplicaciones tradicionales como emergentes, entre otras cosas. Por eso, hoy me gustaría analizar en profundidad qué diferencia a un ADC preparado para la nube de uno tradicional, antes de ahondar en por qué es tan importante en el panorama actual de las aplicaciones.

Cinco grados de diferenciación

Básicamente, hay cinco formas distintas (seis, si queremos ser realmente puntillosos) en las que un ADC preparado para la nube se diferencia de un ADC tradicional. Y dado que F5 prácticamente definió lo que debía ser un ADC mucho antes de que yo llegara, podría decirse que entendemos los ADC mejor que nadie: tanto lo que debían ser como aquello en lo que deben evolucionar para seguir ofreciendo aplicaciones con la velocidad, la seguridad y la estabilidad que necesitan las empresas.

Rendimiento

Es evidente, ¿verdad? Al fin y al cabo, si vas a situarte delante de las aplicaciones y actuar como proxy para ellas, más te vale ser rápido (o, mejor aún, más rápido) que las aplicaciones que distribuyes. Los ADC tradicionales se suministran en formato de dispositivo: chasis, hardware, dispositivos. Aun así, los ADC tradicionales se han visto limitados por las CPU del hardware específico con el que tienen que trabajar. Como los ADC son plataformas, han tendido a centrarse en la velocidad general, del mismo modo que las CPU de propósito general se centran en el procesamiento general. Sin embargo, casi siempre incluyen diversas opciones de aceleración por hardware que deben determinarse antes de la implementación. Puede que estemos locos, pero creemos que un ADC preparado para la nube debería poder superar esa limitación y entender que una aplicación puede necesitar un servicio más que otro, mientras que otra aplicación distinta puede necesitar más otro servicio. Al igual que ocurre con la propia idea de reasignar recursos informáticos bajo demanda, en la que se sustenta todo el concepto de computación en la nube, las organizaciones que invierten en cualquier tipo de hardware también deberían poder reasignarlo.

La razón por la que esto es importante en los servicios que se ejecutan sobre la red es que descargar las tareas habituales en hardware específico (FPGA) libera la CPU para que pueda realizar otras funciones, como inspeccionar, modificar y depurar solicitudes y respuestas, etc. Esto agiliza todo el «paso» por el proxy, lo que se traduce en una menor latencia y usuarios más satisfechos.

Por eso, un ADC preparado para la nube puede superar barreras aprovechando el rendimiento definido por software y permitiendo a las organizaciones aumentar mediante programación el rendimiento del ADC para determinados tipos de procesamiento, como la seguridad. Esto significa que, si cambian las necesidades de la organización, también se puede modificar bajo demanda el perfil de rendimiento de ese hardware. Eso es agilidad en el hardware. Paradójico, ¿verdad? Pero eso forma parte de ser un ADC preparado para la nube: la capacidad de reutilizar hardware especializado para proteger las inversiones y evitar costosas sustituciones integrales de equipos.

Programabilidad

Una frustración persistente que he oído personalmente una y otra vez a los clientes ha sido la falta de entendimiento entre NetOps y DevOps en lo que respecta a las capacidades de scripting. El problema es que el ADC tradicional solo ofrecía funciones de scripting muy básicas y en lenguajes más familiares para NetOps que para DevOps. Aun así, los equipos de DevOps estaban dispuestos a aprender para aprovechar el scripting en la ruta de datos, ya que permitía implementar un enrutamiento de solicitudes y respuestas más ágil, diversas estrategias de escalado e incluso servicios de seguridad. Sin embargo, con el ADC tradicional instalado en un nivel superior, en el núcleo de la red, los equipos de NetOps no estaban dispuestos a permitir que DevOps desplegara scripts que pudieran alterar el flujo del tráfico.

La disponibilidad de ediciones virtuales permitió que los equipos de DevOps tuvieran acceso a su propio ADC personal y privado en forma de máquina virtual, pero seguían viéndose obligados a aprender un lenguaje de scripting orientado a redes. Eso no es bueno. Un ADC preparado para la nube debería ser compatible tanto con NetOps en la red central como con DevOps en la red de aplicaciones, por ejemplo, en la nube. Además, los equipos de DevOps y, en particular, los desarrolladores prefieren lenguajes más orientados al desarrollo, como node.js. No solo porque conocen el lenguaje, sino porque ya existe un amplio repositorio de bibliotecas (como NPM) y servicios que permiten una integración más rápida con infraestructuras orientadas al desarrollo. Por eso, un ADC preparado para la nube debería ser compatible con ambos.

Seguridad de la aplicación

Los ADC tradicionales llevan mucho tiempo proporcionando seguridad básica para las aplicaciones. Al situarse delante de una aplicación, especialmente de las aplicaciones web, solían ser (y siguen siendo) normalmente el primer elemento del centro de datos capaz de reconocer un ataque y tomar medidas al respecto. Como es lógico, la mayor parte de esa seguridad se centraba en la protección a nivel de protocolo. La protección contra inundaciones SYN, la detección de ataques DDoS y otras opciones de seguridad relacionadas con TCP y HTTP básico forman parte integral de los ADC tradicionales desde hace tiempo.

Pero un ADC preparado para la nube debería ir más allá. Es probable que sea uno de los pocos «dispositivos» incluidos en la propia arquitectura de la aplicación para garantizar la inevitable escalabilidad que necesitan las aplicaciones actuales, por lo que tiene todo el sentido adoptar un enfoque similar respecto a la seguridad de toda la pila. Al menos eso creemos, sobre todo porque así se mejora el rendimiento. Si hay que detenerse para realizar un tipo de procesamiento, lo lógico es hacer todo lo posible al mismo tiempo. Es más eficiente y elimina la latencia que supone pasar de un dispositivo a otro y a otro. Si ha recorrido largas distancias con niños, sabrá a qué me refiero. En la gasolinera hay un aseo. No querrá volver a parar en un área de descanso cinco minutos después, ¿verdad? Con la seguridad de la red ocurre lo mismo. Conviene hacer todo lo posible de una sola vez para eliminar la sobrecarga, que a menudo es una fuente de frustración tanto para los clientes como para la empresa. El rendimiento es fundamental, y un ADC preparado para la nube debería hacer todo lo posible para ofrecer experiencias más rápidas con las aplicaciones.

Eso puede implicar ofrecer nuevos modelos para gestionar la creciente demanda (y, en algunos casos, la obligación) de admitir comunicaciones seguras entre dispositivos móviles y aplicaciones. Esto implica admitir el secreto hacia adelante (FS) y la criptografía que lo hace posible. También implica habilitar nuevos modelos para descargar el procesamiento de cifrado y descifrado, que requiere una gran capacidad de cálculo, en el hardware diseñado para gestionarlo, sin alterar las arquitecturas necesarias para admitir microservicios y aplicaciones emergentes. Un ADC preparado para la nube debe admitir ambas opciones, permitiendo comunicaciones rápidas y seguras, al tiempo que se integra a la perfección en las arquitecturas y los entornos de nube actuales.

Ecosistema de socios y automatización

La otra economía de las API es fundamental para el éxito de la nube privada y para la ventaja competitiva que las empresas obtienen gracias a una mayor automatización y orquestación. Pero, por muy deseable que fuera, en el centro de datos siempre habrá diversos servicios de distintos proveedores, cada uno con sus propios modelos de integración y de objetos. Esto suele traducirse en una compleja automatización basada en API que exige conocimientos especializados sobre cada uno de los componentes necesarios. La realidad es que se requieren dos niveles de integración: uno para la orquestación y otro para la automatización (no, no son lo mismo). Por un lado, están las capacidades de automatización propias de la plataforma, mediante API y plantillas; por otro, la integración nativa con el ecosistema de partners, donde la orquestación es la protagonista. Ambos son imprescindibles en un ADC preparado para la nube. El primero garantiza la automatización mediante productos propietarios o scripts personalizados y frameworks como Puppet y Chef, mientras que el segundo permite la orquestación mediante controladores cada vez más importantes, como OpenStack, VMware y Cisco.

Un ADC preparado para la nube debe integrarse de forma nativa y ofrecer funciones de orquestación a través de los marcos y sistemas utilizados para proporcionar una solución de orquestación integral.

No debería ser necesario repetir que un ADC preparado para la nube debe ser compatible con plantillas de nube.

Así que eso es todo lo que voy a decir al respecto.

Modelo de aplicación

Los ADC tradicionales surgieron de la necesidad de ofrecer un conjunto sólido de servicios para las aplicaciones tradicionales. Monolíticas, por así decirlo. Las aplicaciones actuales están cada vez más distribuidas, son más diversas y difieren más de sus predecesoras tradicionales, ya que aprovechan una gran variedad de arquitecturas, plataformas y modelos de despliegue. Ya se trate de contenedores o máquinas virtuales, de la nube o de entornos similares a ella, las aplicaciones siguen necesitando algunos de esos servicios. Y cuando se necesita más de un servicio a la vez (por ejemplo, balanceo de carga y seguridad de aplicaciones), se hace necesario un ADC. Aunque un ADC tradicional puede no ser adecuado para los microservicios, uno preparado para la nube sí lo será. Esto incluye un conjunto más amplio de servicios que pueden beneficiarse del balanceo de carga y la seguridad, servicios que pertenecen claramente al ámbito de devops, no de netops, como memcached.

Aunque sigue siendo una plataforma, un ADC preparado para la nube admite los requisitos de programabilidad, integración y formato necesarios para prestar los servicios que necesitan tanto las aplicaciones tradicionales como las emergentes, en el entorno en el que los necesitan.

Existen muchas similitudes entre un ADC tradicional y uno preparado para la nube. Ambos siguen siendo plataformas capaces de habilitar múltiples servicios con un modelo operativo común. Los dos son programables, se integran con otros sistemas de centros de datos y de la nube, y ofrecen flexibilidad en cuanto a prestaciones de rendimiento. Sin embargo, un ADC preparado para la nube va más allá de lo tradicional: ofrece compatibilidad con ambos entornos y, al mismo tiempo, hace posible el futuro de las empresas y las aplicaciones, así como su necesidad cada vez mayor de integrarse e interoperar con una amplia variedad de infraestructuras y entornos.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie