Vaya más allá del POLB (equilibrio de carga tradicional)
La escalabilidad es una capacidad fundamental tanto para las empresas como aplicações. Desde el punto de vista comercial, escalar las operaciones es clave para posibilitar la nueva economía de las aplicaciones y su estado casi constante de implementación frenética. Desde el lado de las aplicação , la escalabilidad es la forma en que apoyamos el crecimiento de las poblaciones de consumidores y corporativas por igual, garantizando un rendimiento y una disponibilidad de primer nivel para ambos.
En el corazón de la escalabilidad está el equilibrio de carga. Desde mediados de la década de 1990, el equilibrio de carga ha sido la forma en que escalamos las aplicações distribuyendo cargas de trabajo entre granjas cada vez más grandes de servidores, redes, aplicações y servicios.
En el pasado, el equilibrio de carga era una cuestión de red. Basándose en técnicas y protocolos existentes que escalaban redes, el equilibrio de carga se centró en aquellos aspectos de la comunicación cliente-servidor que podían usarse para distribuir cargas de trabajo. Nació el sistema Plain Old Load Balancing (POLB).
Funcionó y funcionó bien. Sin POLB es prácticamente imposible saber si la web tal como la conocemos habría llegado a existir. Fue (y sigue siendo) fundamental respaldar a la población corporativa y de consumidores de la actualidad, así como también poder respaldar a la del mañana.
A principios de la década de 2000, la ubicación estratégica del equilibrador de carga lo convirtió en la plataforma perfecta para expandirse a otras funciones que mejoran la experiencia de las aplicaciones. Con el tiempo se agregaron aceleración, optimización, almacenamiento en caché y compresión de aplicação . La seguridad también encontraría su lugar en esta misma plataforma, su posición en la red es demasiado perfecta como para ignorarla. Como guardián de las aplicações, su capacidad para inspeccionar, extraer, modificar y transformar el tráfico de las aplicação le proporciona información única que se aplica tanto a la seguridad como al rendimiento.
En algún momento a principios de la década de 2000, pasamos de POLB a algo más. Los balanceadores de carga se convirtieron en plataformas de distribución de aplicação , tan competentes en la entrega de aplicaciones seguras, rápidas y disponibles como lo habían sido en su escalamiento con POLB.
Los ADC (controladores de entrega de aplicação ), como se conocen estas plataformas modernas , no solo pueden ofrecer capacidades POLB, sino una verdadera cornucopia de capacidades que los hacen invaluables para las personas que hoy tienen la tarea no solo de implementar aplicaciones sino también de entregarlas.
Cada vez más, no son los equipos de red los que se encargan de ello, sino los arquitectos y las operaciones.
Ese cambio ha sido impulsado por una serie de tecnologías surgidas en la última década. Desde Agile hasta la nube, DevOps y dispositivos móviles, las mejores prácticas actuales están impulsando algunos servicios de aplicação fuera de la red y hacia el dominio de las aplicações.
Y a lo largo del traslado de la responsabilidad de la escalabilidad desde la red a los arquitectos y operadores, el ADC se está implementando como si estuviera estancado en la década de 1990. Si lo consideramos como un POLB, la mayor parte del valor que ofrece a los arquitectos y operadores para mejorar el rendimiento y la seguridad se deja sobre la mesa (o, más apropiadamente, en el estante).
Generalmente, esto se debe a que los arquitectos y los equipos de operaciones ahora responsables de escalar aplicações no están familiarizados con lo que un ADC puede hacer por ellos y, más importante aún, con sus aplicaciones y arquitecturas. Es hora de cambiar eso y ir más allá de POLB.
Más allá de POLB: Proxy L7 LB
El objetivo de POLB era simple: disponibilidad. Ya sea mediante la implementación de una arquitectura HA (alta disponibilidad) basada en redundancia o utilizando una arquitectura de escalamiento N+1, el objetivo era el mismo: mantener el sitio web (o la aplicación) activo y disponible, pase lo que pase.
Hoy en día el objetivo sigue siendo la disponibilidad, pero va acompañada de eficiencia y agilidad. Las tres son características clave de las empresas modernas y de las arquitecturas que sustentan sus aplicações críticas. Para llegar allí, sin embargo, tenemos que ir más allá de POLB, a un mundo de enrutamiento de aplicação y distribución de carga que aporta esas eficiencias críticas tanto a las arquitecturas de las aplicaciones como a la infraestructura. Estas capacidades se basan en la capa 7 de la pila de red (la capa de aplicação ) y en las arquitecturas modernas eso significa HTTP.
Los servidores proxy L7 LB son capaces no solo de distribuir la carga en función de variables de aplicação como la carga de conexión, los tiempos de respuesta y el estado de la aplicação , sino también de despachar (enrutar) en función de URL, encabezados HTTP e incluso datos dentro de mensajes HTTP.
Capaces de analizar, extraer y actuar sobre estos diversos tipos de datos de la capa de aplicação , los balanceadores de carga L7 hoy pueden participar y aumentar las aplicações y arquitecturas de microservicios de diversas maneras, que incluyen:
- Arquitecturas de particionamiento de datos (sharding)
- Envío de URL complejo
- Manipular los encabezados de respuesta
- Enrutamiento dinámico basado en datos de backend
- Escalado por descomposición funcional
- Medición de API y control de acceso
Más allá de POLB: Seguridad
Debido a que un LB L7 está ubicado lógicamente aguas arriba de las aplicações a las que da servicio, tiene visibilidad de todas y cada una de las solicitudes y respuestas. Esto significa que es capaz de realizar una variedad de controles y equilibrios en las solicitudes antes de que se les permita proceder a la aplicação deseada. Estos controles y equilibrios son vitales para garantizar que se detecte y rechace el tráfico malicioso, evitando que sus efectos adversos afecten la estabilidad, la disponibilidad y la integridad de las aplicações back-end.
Pero se trata de más que simplemente evitar que el tráfico malicioso llegue a los servidores, también se trata de detener a los malos actores. Esto significa poder identificarlos, y no sólo a aquellos que no tienen credenciales válidas, sino también a aquellos que usan credenciales que, en primer lugar, no les pertenecen. El papel del control de acceso ha ido creciendo a medida que el número de infracciones resultantes de credenciales robadas ha ido en aumento. La nube también ha reintroducido la urgencia de gestionar las credenciales de forma global en todas las aplicações, para reducir el riesgo potencial de cuentas huérfanas y de prueba que otorgan acceso a datos corporativos almacenados en aplicações basadas en SaaS. La federación de identidad se ha convertido en algo más que una mera estrategia de mejora de la productividad: se ha convertido en una táctica clave en la estrategia de seguridad corporativa.
Las capacidades que se pueden agregar a un LB L7 incluyen aquellas que analizan el comportamiento y la identidad de los clientes, así como el contenido real de los mensajes que se intercambian entre los clientes y los servicios backend. Esto permite que el L7 LB realice funciones que incluyen:
- Protección DDoS de capa 7 (aplicación)
- Cortafuegos de aplicaciones web
- Los 10 mejores 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 aplicação y, por tanto, de los negocios. En el pasado, las organizaciones implementaban múltiples soluciones de aceleración de aplicação delante de las aplicações para acelerar el proceso de entrega. Los ADC incorporaron estas mismas soluciones como componentes opcionales (complementarios), pero eventualmente integraron estas capacidades directamente como parte de las capacidades principales de equilibrio de carga, un reflejo de la importancia del rendimiento para su enfoque central en la entrega de aplicações y servicios.
Así es como el L7 LB tiene una variedad de características y funciones enfocadas a mejorar el rendimiento. Algunas de esas funciones, en particular aquellas que actúan sobre las respuestas de la aplicación dirigidas al cliente, se centran en el contenido. Muchas de estas son técnicas básicas de desarrollo que se utilizan para hacer que el contenido sea más pequeño, mientras que otras se centran en disminuir la cantidad de viajes de ida y vuelta necesarios entre el cliente y el servidor.
Además, es importante tener en cuenta que los servidores proxy L7 no solo se centran en optimizar el contenido, sino que también son facilitadores clave de arquitecturas centradas en el 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 la aplicação . Los servidores proxy L7 que son adecuados para habilitar estas arquitecturas generalmente están habilitados con un lenguaje de programación de ruta de datos que brinda la capacidad de adaptar la distribución y el enrutamiento.
Otras capacidades se centran en reducir la sobrecarga de los servidores back-end como una forma de mejorar el rendimiento, además de poder distribuir la carga en función de los umbrales de rendimiento.
Las características y capacidades de optimización de un LB L7 incluyen:
Lado del cliente (Optimización de la respuesta) |
Lado del servidor backend |
• Minificación • Compresión HTTP • Almacenamiento en búfer • Agregación de scripts • Descarga de SSL |
• Multiplexación TCP • Almacenamiento en caché • Distribución de carga basada en el rendimiento • Autoescalabilidad |
Más allá de POLB: Administrar
Para que una infraestructura pueda integrarse mejor en la arquitectura de la aplicação , es absolutamente necesario que pueda integrarse en el flujo de trabajo de CI/CD. Esto significa apoyar las metodologías modernas relacionadas con DevOps y Agile y los conjuntos de herramientas que permiten la ejecución de estrategias de lanzamiento y entrega automatizadas.
Para tal fin, L7 LB debe proporcionar no solo API a través de las cuales pueda administrarse, sino también los medios a través de los cuales pueda monitorearse e implementarse para garantizar que sea posible la retroalimentación y la entrega continuas para cumplir con los exigentes cronogramas y presupuestos actuales.
F5 admite una variedad de opciones programáticas para aprovisionar, implementar, administrar y monitorear la infraestructura LB L7, incluidas:
Más allá de POLB: Es hora
Hay una variedad de razones por las cuales la responsabilidad de la infraestructura de aplicaciones como POLB y L7 LB se está trasladando de los equipos de red a los equipos de aplicação y operaciones. Ya sea la adopción de métodos ágiles o DevOps como respuesta a la demanda empresarial de más aplicaciones con plazos de entrega más cortos o la necesidad de escalar más rápidamente que nunca, ir más allá de POLB brindará una mayor variedad de opciones de seguridad, rendimiento y disponibilidad necesarias para respaldar las arquitecturas de aplicaciones y entrega modernas en una plataforma única, manejable y programable que se adapte a la canalización CI/CD moderna.
Es hora de considerar ir más allá de POLB y comenzar a aprovechar la infraestructura que cada vez cae más bajo su dominio.
