Ve más allá del POLB (balanceo de carga tradicional)

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

La escalabilidad es una capacidad fundamental tanto para las empresas como para las aplicaciones. Desde el punto de vista empresarial, escalar las operaciones es clave para impulsar la nueva economía de las aplicaciones y su ritmo casi constante de despliegues frenéticos. En cuanto a las aplicaciones, la escalabilidad nos permite respaldar el crecimiento tanto del número de usuarios particulares como de los entornos corporativos, garantizando a ambos un rendimiento y una disponibilidad excelentes.

El equilibrio de carga es la base de la escalabilidad. Desde mediados de la década de 1990, ha sido el método utilizado para escalar aplicaciones mediante la distribución de las cargas de trabajo entre conjuntos cada vez mayores de servidores, redes, aplicaciones y servicios.

Antiguamente, el balanceo de carga se centraba exclusivamente en la red. Basándose en técnicas y protocolos existentes que permitían ampliar las redes, el balanceo de carga se enfocaba en aquellos aspectos de la comunicación cliente-servidor que podían utilizarse para distribuir las cargas de trabajo. Así nació el balanceo de carga tradicional (POLB).

Funcionó, y funcionó bien. Sin POLB, es prácticamente imposible saber si la web tal como la conocemos habría llegado a hacerse realidad. Fue —y sigue siendo— fundamental para dar servicio a los usuarios empresariales y particulares de hoy, así como para poder atender a los del futuro.

En algún momento de principios de la década de 2000, la ubicación estratégica del equilibrador de carga lo convirtió en la plataforma perfecta para incorporar otras funciones destinadas a mejorar la experiencia de las aplicaciones. Con el tiempo, se añadieron la aceleración, la optimización, el almacenamiento en caché y la compresión de aplicaciones. La seguridad también acabaría integrándose en esta misma plataforma, ya que su posición en la red era demasiado idónea como para pasarla por alto. Como puerta de acceso a las aplicaciones, su capacidad para inspeccionar, extraer, modificar y transformar el tráfico de las aplicaciones le proporciona información única, aplicable tanto a la seguridad como al rendimiento.

En algún momento de principios de la década de 2000, fuimos más allá de POLB y dimos paso a algo distinto. Los balanceadores de carga se convirtieron en plataformas de entrega de aplicaciones, tan capaces de ofrecer aplicaciones seguras, rápidas y disponibles como lo habían sido hasta entonces de escalarlas mediante POLB.

Estas plataformas modernas, conocidas como ADC (controladores de entrega de aplicaciones), no solo ofrecen funciones de POLB, sino también un auténtico abanico de prestaciones que las hacen indispensables para quienes hoy se encargan no solo de implementar aplicaciones, sino también de distribuirlas.

Cada vez más, no son los equipos de redes quienes se encargan de ello, sino los arquitectos y los equipos de operaciones.

Ese cambio se ha visto impulsado por una serie de tecnologías surgidas durante la última década. Desde las metodologías ágiles hasta la nube, pasando por DevOps y las tecnologías móviles, las prácticas recomendadas actuales están trasladando algunos servicios de aplicaciones fuera de la red y al ámbito de las aplicaciones.

Y mientras la responsabilidad de la escalabilidad pasa de la red a los arquitectos y los equipos de operaciones, el ADC se sigue implementando como si se hubiera quedado anclado en los años noventa. Al tratarlo como un POLB, se desaprovecha gran parte del valor que ofrece a arquitectos y equipos de operaciones para mejorar el rendimiento y la seguridad (o, más acertadamente, se deja en el rack).

Esto suele deberse a que los arquitectos y los equipos de operaciones que ahora se encargan de escalar las aplicaciones no conocen bien todo lo que un ADC puede hacer por ellos y, lo que es más importante, por sus aplicaciones y arquitecturas. Es hora de cambiar esta situación e ir más allá del POLB.

Más allá de POLB: proxy de balanceo de carga L7

El objetivo de POLB era sencillo: garantizar la disponibilidad. Ya fuera mediante la implementación de una arquitectura de alta disponibilidad (HA) basada en la redundancia o mediante una arquitectura de escalado N+1, el objetivo era el mismo: mantener el sitio web (o la aplicación) en funcionamiento y disponible, pasara lo que pasara.

Hoy, el objetivo sigue siendo la disponibilidad, pero ahora va unida a la eficiencia y la agilidad. Las tres son características clave de las empresas modernas y de las arquitecturas que sustentan sus aplicaciones críticas. Sin embargo, para lograrlo debemos ir más allá de POLB y adentrarnos en un mundo de enrutamiento de aplicaciones y distribución de carga que aporte esas eficiencias esenciales tanto a las arquitecturas de aplicaciones como a la infraestructura. Estas capacidades se basan en la capa 7 de la pila de red —la capa de aplicación—, lo que en las arquitecturas modernas significa HTTP.

Los proxies de balanceo de carga de capa 7 no solo pueden distribuir la carga en función de variables de la aplicación, como la carga de las conexiones, los tiempos de respuesta y el estado de la aplicación, sino también dirigirla (enrutarla) en función de las URL, las cabeceras HTTP e incluso los datos contenidos en los mensajes HTTP.

Gracias a su capacidad para analizar, extraer y utilizar estos distintos tipos de datos de la capa de aplicación, los balanceadores de carga de capa 7 actuales pueden participar en aplicaciones y arquitecturas de microservicios y mejorarlas de diversas formas, entre ellas:

• Arquitecturas de particionamiento de datos (sharding)
• Enrutamiento complejo de URL
• Manipular las cabeceras de respuesta
• Enrutamiento dinámico basado en datos del backend
• Escalado mediante descomposición funcional
• Medición del uso de la API y control de acceso

Más allá de POLB: seguridad

Dado que un balanceador de carga de capa 7 se sitúa lógicamente por delante de las aplicaciones a las que presta servicio, tiene visibilidad de todas y cada una de las solicitudes y respuestas. Esto significa que puede realizar diversos controles sobre las solicitudes antes de que se les permita llegar a la aplicación deseada. Estos controles son fundamentales para garantizar que el tráfico malicioso se detecte y se rechace, evitando que sus efectos adversos afecten a la estabilidad, la disponibilidad y la integridad de las aplicaciones de backend.

Pero no se trata solo de impedir que el tráfico malicioso llegue a los servidores, sino también de detener a los actores maliciosos. Para ello, hay que poder identificarlos, y no solo a quienes carecen de credenciales válidas, sino también a quienes utilizan credenciales que no les pertenecen. El papel del control de acceso ha ido cobrando importancia a medida que aumentaba el número de brechas de seguridad provocadas por el robo de credenciales. La nube también ha vuelto a poner de manifiesto la urgencia de gestionar las credenciales de forma global en todas las aplicaciones, con el fin de reducir el riesgo potencial que suponen las cuentas huérfanas y de prueba que permiten acceder a datos corporativos almacenados en aplicaciones basadas en SaaS. La federación de identidades ha dejado de ser una mera estrategia para mejorar la productividad y se ha convertido en una táctica clave dentro de la estrategia global de seguridad corporativa.

Entre las capacidades que se pueden añadir a un balanceador de carga de capa 7 se incluyen tanto las que analizan el comportamiento y la identidad de los clientes como las que examinan el contenido real de los mensajes intercambiados entre los clientes y los servicios de backend. Esto permite que el balanceador de carga de capa 7 realice funciones como las siguientes:

• Protección contra DDoS de capa 7 (aplicación)
• Protección mediante firewall para aplicaciones web
• Top 10 de OWASP
• Control de acceso a aplicaciones
• Identidad federada

Más allá de POLB: optimización

El rendimiento es un componente fundamental para el éxito de las aplicaciones y, por tanto, de las empresas. En el pasado, las organizaciones implementaban varias soluciones de aceleración delante de las aplicaciones para agilizar el proceso de entrega. Los ADC incorporaron estas mismas soluciones como componentes opcionales (complementos), pero con el tiempo integraron estas funciones directamente en las capacidades principales de balanceo de carga, lo que refleja la importancia del rendimiento para su objetivo esencial de entregar aplicaciones y servicios.

Por ello, el balanceador de carga de capa 7 cuenta con diversas características y funciones orientadas a mejorar el rendimiento. Algunas de estas funciones —en particular, las que actúan sobre las respuestas de la aplicación que se devuelven al cliente— se centran en el contenido. Muchas de ellas son técnicas básicas de desarrollo que se utilizan para reducir el tamaño del contenido, mientras que otras se centran en disminuir el número de intercambios necesarios entre el cliente y el servidor.

Asimismo, es importante señalar que los proxies de capa 7 no solo se centran en optimizar el contenido, sino que también son elementos clave para implementar arquitecturas orientadas al rendimiento que incluyen técnicas de equilibrio de carga de bases de datos, así como la integración de cachés en memoria (como memcached) para mejorar el rendimiento general de las aplicaciones. Los proxies de capa 7 más adecuados para implementar estas arquitecturas suelen incorporar un lenguaje de scripting para la ruta de datosque permite personalizar la distribución y el enrutamiento.

Otras funcionalidades se centran en reducir la sobrecarga de los servidores backend para mejorar el rendimiento, así como en distribuir la carga en función de determinados umbrales de rendimiento.

Entre las funciones y capacidades de optimización de un balanceador de carga de capa 7 se incluyen:

Más allá de POLB: Gestionar

Para que una infraestructura esté más integrada en la arquitectura de la aplicación, es imprescindible que pueda integrarse en el pipeline de CI/CD. Esto implica que debe ser compatible con metodologías modernas relacionadas con DevOps y Agile, así como con los conjuntos de herramientas que permiten ejecutar estrategias automatizadas de publicación y entrega.

Para ello, el balanceador de carga de capa 7 no solo debe proporcionar API que permitan gestionarlo, sino también los medios necesarios para supervisarlo y desplegarlo, a fin de garantizar que sea posible mantener una retroalimentación y entrega continuas para cumplir los exigentes plazos y presupuestos actuales.

F5 admite diversas opciones programáticas para aprovisionar, desplegar, gestionar y supervisar la infraestructura de balanceo de carga de capa 7, entre ellas:

• API REST y SOAP
• Complementos para Chef, Puppet, Cisco, VMware, Electric Cloud, New Relic, Nagios, Ansible, Urban {code} y muchos más
• Plantillas inteligentes

Más allá de POLB: ha llegado el momento

Hay diversos motivos por los que la responsabilidad de la infraestructura de aplicaciones, como POLB y el balanceo de carga de capa 7 (L7 LB), está pasando de los equipos de redes a los equipos de aplicaciones y operaciones. Ya sea por la adopción de metodologías ágiles o DevOps para responder a la demanda empresarial de más aplicaciones con plazos de entrega más cortos, o por la necesidad de escalar con mayor rapidez que nunca, ir más allá de POLB ofrecerá un abanico más amplio de opciones de seguridad, rendimiento y disponibilidad, necesarias para dar soporte a arquitecturas modernas de aplicaciones y entrega en una única plataforma gestionable y programable que se integra en el pipeline moderno de CI/CD.

Es hora de plantearse ir más allá de POLB y empezar a aprovechar la infraestructura que cada vez recae más en su ámbito de responsabilidad.

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