La evolución de los controles de entrega de aplicaciones

En el mundo dinámico de hoy, las organizaciones enfrentan constantemente el desafío de entregar aplicações críticas a millones de usuarios en todo el mundo. Es extremadamente importante que implementen servicios de red y aplicação para que las aplicaciones sean escalables, seguras y disponibles. Esta es una de las principales razones detrás de la evolución de los controladores de entrega de aplicação (ADC). Sin embargo, ninguna de estas características se puede implementar sin una base sólida en la tecnología básica de equilibrio de carga. Entonces, comencemos por comprender la importancia del equilibrio de carga, cómo conduce a una entrega eficiente de aplicação y cómo los ADC continúan evolucionando y adoptando el mundo de la nube.

El objetivo principal del equilibrio de carga es equilibrar el tráfico entrante de la red o de aplicação entre muchos servidores físicos y hacer que esos servidores parezcan un solo servidor para el mundo exterior. Hay muchas razones para hacer esto, pero las principales son la necesidad de "escalabilidad", "alta disponibilidad" y "previsibilidad".

La escalabilidad es la capacidad de adaptarse de forma dinámica o sencilla a una mayor carga sin afectar el rendimiento existente. La alta disponibilidad (HA), por otro lado, es la capacidad de un sitio de permanecer disponible y accesible incluso durante la falla de uno o más sistemas. La virtualización de servicios (imitación del comportamiento de los componentes de software para acelerar y probar el desarrollo de aplicação ) presenta una oportunidad interesante tanto para la escalabilidad como para la disponibilidad. Si el servicio o punto de contacto del usuario está separado de los servidores reales, la aplicação se puede escalar agregando más servidores. Además, el fallo de un servidor individual no hará que toda la aplicação quede indisponible. La previsibilidad es un poco menos clara, ya que representa partes de HA, así como algunas lecciones aprendidas a lo largo del camino. Se puede describir mejor como tener control sobre cómo y cuándo se prestan los servicios con respecto a la disponibilidad y el rendimiento.

En los primeros días de Internet comercial, muchos aspirantes a millonarios de las puntocom descubrieron un grave problema en sus planes. Los mainframes no tenían software de servidor web (al menos no hasta el AS/400e) e incluso si lo tuvieran, no podrían costearlos con los presupuestos iniciales. Lo único que podían permitirse era hardware de servidor estándar, disponible en el mercado, de alguno de los omnipresentes fabricantes de PC. El principal problema con la mayoría de ellos era que no había forma de que un solo servidor basado en PC pudiera manejar la cantidad de tráfico que generaría su negocio. Y si fallaba, se quedaban fuera de línea y sin negocio. Afortunadamente, algunas de esas personas tenían planes de ganar millones resolviendo ese problema en particular. Esto condujo al nacimiento del equilibrio de carga.

Antes de que existieran dispositivos de equilibrio de carga diseñados específicamente para este fin y disponibles comercialmente, hubo muchos intentos de utilizar la tecnología existente para lograr los objetivos de escalabilidad y disponibilidad. La tecnología más común (y aún utilizada) fue el DNS round-robin.

Con este método, el DNS asignaría una serie de direcciones IP únicas a diferentes servidores, bajo el mismo nombre DNS. Esto significaba que la primera vez que un usuario solicitaba resolución para “ www.example.com ”, el servidor DNS pasaría cada nueva conexión al primer servidor en la fila hasta llegar al final de la misma, antes de volver nuevamente al primer servidor. Esta solución fue sencilla y condujo a una distribución uniforme de las conexiones entre una serie de máquinas.

Desde el punto de vista de escalabilidad, esta solución funcionó notablemente bien ya que ofreció la oportunidad de agregar una cantidad casi ilimitada de servidores a un nombre DNS. Sin embargo, en cuanto a la disponibilidad, la solución creó obstáculos ya que el DNS no tenía la capacidad de saber si los servidores enumerados funcionaban o no. Si un servidor deja de estar disponible y un usuario intenta acceder a él, la solicitud podría enviarse a un servidor que no funciona.

Otro factor que impulsa el sistema round-robin de DNS es la previsibilidad, que es un alto nivel de confianza de que un usuario será enviado a un servidor en particular. Esto se centra en la idea de persistencia: el concepto de asegurarse de que un usuario no sea transferido a un nuevo servidor una vez que ha comenzado una sesión o cuando el usuario reanuda una sesión previamente suspendida. Este es un problema muy importante que el sistema round-robin de DNS no pudo resolver.

Para abordar este problema, una de las primeras soluciones diseñadas específicamente fue el equilibrio de carga integrado directamente en el software de aplicação o en el sistema operativo (OS) del servidor de aplicação . Si bien hubo tantas implementaciones diferentes como empresas que las desarrollaron, la mayoría de las soluciones giraban en torno a trucos básicos de red. Por ejemplo, una de esas soluciones tenía todos los servidores en un grupo (también conocido como clúster), además de su propia dirección IP física.

Cuando los usuarios intentaron conectarse al servicio, se conectaron a la IP del grupo en lugar de a la IP física del servidor. Cualquier servidor del grupo que respondiera primero a la solicitud de conexión redirigiría al usuario a una dirección IP física (la suya o la de otro sistema del grupo) y comenzaría la sesión de servicio. Uno de los beneficios clave de esta solución fue que los desarrolladores de aplicação podían usar una variedad de información para determinar a qué dirección IP física debía conectarse el cliente. Por ejemplo, podrían hacer que cada servidor del grupo mantenga un recuento de cuántas sesiones ya estaba atendiendo cada miembro del grupo y luego dirigir cualquier solicitud nueva al servidor menos utilizado.

Inicialmente, la escalabilidad de esta solución estaba clara. Todo lo que tenías que hacer era construir un nuevo servidor, agregarlo al grupo y aumentar la capacidad de tu aplicação. Sin embargo, con el tiempo, la escalabilidad del equilibrio de carga basado en aplicaciones comenzó a cuestionarse. Debido a que los miembros del grupo necesitaban mantenerse en contacto constante entre sí para decidir a quién debía dirigirse la siguiente conexión, el tráfico de red entre los miembros del grupo aumentaba exponencialmente con cada nuevo servidor agregado al grupo. Una vez que el grupo creció hasta un tamaño determinado (generalmente entre 5 y 10 hosts), este tráfico comenzó a afectar el tráfico de los usuarios finales, así como la utilización del procesador de los propios servidores. Por lo tanto, la escalabilidad era excelente siempre y cuando no fuera necesario superar un número pequeño de servidores (por cierto, menos que con el sistema DNS round-robin).

La alta disponibilidad se incrementó drásticamente con el round-robin de DNS y el equilibrio de carga de software. Debido a que los miembros del grupo estaban en constante comunicación entre sí y a que los desarrolladores de aplicação podían usar su amplio conocimiento de las aplicação para saber cuándo un servidor estaba funcionando correctamente, estas soluciones prácticamente eliminaron la posibilidad de que los usuarios llegaran a un servidor que no pudiera atender sus solicitudes. Cabe señalar, sin embargo, que cada iteración de las características de HA que habilitan inteligencia tuvo un impacto correspondiente en la utilización del servidor y la red, lo que limitó aún más la escalabilidad. El otro impacto negativo de HA fue en el ámbito de la confiabilidad. Muchos de los trucos de red utilizados para distribuir el tráfico en estos sistemas eran complejos y requerían una considerable monitorización a nivel de red. En consecuencia, estos métodos de distribución a menudo encontraban problemas que afectaban a toda la aplicação y a todo el tráfico en la red de la aplicação .

Estas soluciones también mejoraron la previsibilidad. Como los diseñadores de la aplicação sabían cuándo y por qué los usuarios debían regresar al mismo servidor en lugar de equilibrar la carga, pudieron incorporar una lógica que ayudó a garantizar que los usuarios permanecieran persistentes si fuera necesario. También utilizaron la misma tecnología de "agrupamiento" para replicar la información del estado del usuario entre servidores, eliminando muchas de las instancias que requerían persistencia en primer lugar. Por último, gracias a su profundo conocimiento de las aplicação , pudieron desarrollar mejor algoritmos de equilibrio de carga basados ​​en el estado real de la aplicação en lugar de en cosas como las conexiones, que no siempre eran un buen indicador de la carga del servidor.

Además de las posibles limitaciones en la escalabilidad real y los problemas de confiabilidad, el equilibrio de carga basado en aplicaciones propietarias también tenía un inconveniente adicional: Dependía del proveedor de la aplicação para su desarrollo y mantenimiento. El problema principal aquí era que no todas las aplicações proporcionaban tecnología de equilibrio de carga (o agrupamiento) y las que sí lo hacían a menudo no funcionaban con las proporcionadas por otros proveedores de aplicação . Si bien hubo varias organizaciones que produjeron software de equilibrio de carga a nivel de sistema operativo y neutral respecto del proveedor, lamentablemente sufrieron los mismos problemas de escalabilidad. Y sin una integración estrecha con las aplicações, estas "soluciones" de software también experimentaron desafíos de alta disponibilidad adicionales.

La segunda iteración del equilibrio de carga especialmente diseñado surgió como dispositivos basados en red. Estos son los verdaderos padres fundadores de los controladores de entrega de aplicação actuales. Estos dispositivos residían físicamente fuera de las propias aplicações y, aunque comenzaron como balanceadores de carga, lograron su equilibrio de carga utilizando técnicas de red mucho más sencillas, como NAT. Estos dispositivos presentarían una dirección de servidor virtual al mundo exterior y cuando los usuarios intentaran conectarse, los dispositivos reenviarían la conexión al servidor real más apropiado.

El equilibrador de carga podía controlar exactamente qué servidor recibía qué conexión y empleaba "monitores de salud" de complejidad creciente para garantizar que el servidor de aplicação (un servidor físico real) respondiera según fuera necesario. Si el servidor no respondía correctamente, el balanceador de carga dejaría automáticamente de enviar tráfico a ese servidor hasta que produjera la respuesta deseada. Aunque los monitores de salud rara vez eran tan completos como los creados por los propios desarrolladores de aplicação , el enfoque de hardware basado en red podía brindar servicios básicos de equilibrio de carga a casi todas las aplicação de una manera uniforme y consistente, creando finalmente un punto de entrada de servicio verdaderamente virtualizado y exclusivo para los servidores de aplicação .

Desde el punto de vista de la escalabilidad, las organizaciones que comenzaron a reemplazar el equilibrio de carga basado en software por una solución basada en hardware vieron una caída drástica en la utilización de sus servidores. Esto les evitó tener que comprar servidores adicionales a corto plazo y ayudó a generar un mayor ROI a largo plazo.

De manera similar, HA ayudó a reducir la complejidad de la solución y a proporcionar un equilibrio de carga imparcial para cada aplicación, lo que generó una mayor confiabilidad y profundidad como solución. El hardware de equilibrio de carga basado en red permitió al propietario de la empresa brindar un alto nivel de disponibilidad a todas sus aplicações en lugar de a unas pocas seleccionadas con equilibrio de carga incorporado.

La previsibilidad fue un componente central agregado por el hardware de equilibrio de carga basado en red. Ahora era mucho más fácil predecir hacia dónde se dirigiría una nueva conexión y mucho más fácil manipularla. Estos dispositivos agregaron inteligencia al proceso, lo que a su vez ayudó a crear una distribución de carga controlada (a diferencia de la distribución no controlada del DNS dinámico). Esto permitió a los propietarios de empresas distribuir la carga a los servidores según la capacidad del servidor para manejarla.

La llegada del equilibrador de carga basado en red y la virtualización trajo consigo nuevos beneficios para la seguridad y la administración, como el enmascaramiento de la identidad de los servidores de aplicação de la comunidad de Internet y la capacidad de "purgar" conexiones de un servidor para poder desconectarlo para realizar tareas de mantenimiento sin afectar a los usuarios. Esta es la base a partir de la cual se originaron los ADC.

Con una función de equilibrio de carga central, que también es un proxy completo, TI vio un excelente lugar para incorporar y consolidar servicios nuevos y emergentes. Esto condujo a que un dispositivo de equilibrio de carga evolucionara hacia una plataforma ADC extensible. En pocas palabras, el proxy es la base para el equilibrio de carga y la tecnología subyacente que hace posibles los ADC.  

Al analizar la seguridad del ADC, la virtualización creada por el proxy (la tecnología base) es fundamental. Ya sea que hablemos de descarga de cifrado SSL/TLS, autenticación centralizada o incluso firewalls fluidos para aplicaciones, el poder de estas soluciones reside en el hecho de que un equilibrador de carga (hardware o edición virtual) es el punto agregado de virtualización en todas las aplicações. La autenticación centralizada es un ejemplo clásico. Los mecanismos tradicionales de autenticación y autorización siempre se han integrado directamente en la propia aplicação . Al igual que el equilibrio de carga basado en aplicaciones, cada implementación dependía y era única para la implementación de cada aplicación, lo que daba lugar a numerosos y diferentes métodos. En cambio, al aplicar la autenticación en el punto de entrada virtualizado a todas las aplicações, se puede aplicar un método de autenticación único y uniforme. Esto no sólo simplifica drásticamente el diseño y la gestión del sistema de autenticación, sino que también mejora el rendimiento de los propios servidores de aplicação al eliminar la necesidad de realizar esa función. Además, también elimina la necesidad (especialmente en aplicações locales) de gastar tiempo y dinero para desarrollar procesos de autenticación en cada aplicação por separado.

La disponibilidad es el atributo de ADC más fácil de vincular con el balanceador de carga original, ya que se relaciona con todos los atributos básicos del balanceador de carga: escalabilidad, alta disponibilidad y previsibilidad. Sin embargo, los ADC llevan esto incluso más allá de lo que lo hizo el balanceador de carga. La disponibilidad para los ADC también representa conceptos avanzados como la dependencia de aplicação y el aprovisionamiento dinámico. Los ADC son capaces de comprender que las aplicações ahora rara vez funcionan de manera autónoma: A menudo dependen de otras aplicações para cumplir su diseño. Este conocimiento aumenta la capacidad del ADC para proporcionar disponibilidad de la aplicação teniendo en cuenta también estos otros procesos. Los ADC más inteligentes del mercado también proporcionan interfaces programáticas que les permiten cambiar dinámicamente la forma en que proporcionan servicios en función de la información externa. Estas interfaces permiten el aprovisionamiento dinámico y el escalamiento ascendente o descendente automatizado necesario para entornos modernos como las implementaciones en la nube y en contenedores.

La mejora del rendimiento fue otra extensión obvia del concepto de equilibrio de carga. Los balanceadores de carga mejoraron inherentemente el rendimiento de las aplicações al garantizar que las conexiones no solo se dirigieran a los servicios que estaban disponibles (y que respondían en un plazo de tiempo aceptable), sino también a los servicios con la menor cantidad de conexiones y/o utilización del procesador. Esto garantizaba que cada nueva conexión fuera atendida por el sistema que mejor podía manejarla. Más tarde, cuando la descarga de SSL/TLS (mediante hardware dedicado) se convirtió en un elemento básico común de las ofertas de equilibrio de carga, redujo la cantidad de sobrecarga computacional del tráfico cifrado, así como la carga en los servidores back-end, mejorando también su rendimiento.

Los ADC de hoy van aún más lejos. Estos dispositivos a menudo incluyen tecnología de almacenamiento en caché, compresión e incluso de modelado de velocidad para aumentar aún más el rendimiento general y la entrega de aplicações. Además, en lugar de ser implementaciones estáticas de dispositivos independientes tradicionales que brindan estos servicios, un ADC puede usar su inteligencia de aplicaciones innata para aplicar estos servicios solo cuando produzcan un beneficio en el rendimiento, optimizando así su uso.

Por ejemplo, la tecnología de compresión —a pesar de la creencia común—no es necesariamente beneficioso para todos los usuarios de la aplicação. Ciertamente, los usuarios con un ancho de banda pequeño pueden beneficiarse enormemente de paquetes más pequeños, ya que el cuello de botella es el rendimiento real. Incluso las conexiones que deben recorrer largas distancias pueden beneficiarse, ya que los paquetes más pequeños significan menos viajes de ida y vuelta para transportar datos, lo que disminuye el impacto de la latencia de la red. Sin embargo, las conexiones de corta distancia (por ejemplo, dentro del mismo continente) con gran ancho de banda podrían tener un peor rendimiento al aplicar compresión. Dado que el rendimiento no es necesariamente el cuello de botella, la sobrecarga adicional de compresión y descompresión agrega latencia que el mayor rendimiento no compensa desde una perspectiva de rendimiento. En otras palabras, si no se gestiona adecuadamente, la tecnología de compresión como solución puede ser peor que el problema original. Pero al aplicar inteligentemente la compresión solo cuando beneficia el rendimiento general, un ADC optimiza el uso y el costo de la tecnología de compresión, dejando más ciclos de procesador para funciones que aprovecharán al máximo sus beneficios.

Debido a que la transformación digital es un imperativo estratégico tan importante, muchas empresas han comenzado a emprender su viaje hacia la nube. Con el creciente número de aplicações que surgen y cambian el mundo que nos rodea, se cree que las organizaciones que migran a la nube disfrutarán de muchos beneficios, como mayor agilidad, costos operativos mejor alineados, escalabilidad a pedido y un mayor enfoque en su negocio principal.  

La “nube” no es una entidad única amorfa de recursos compartidos de computación, almacenamiento y redes; más bien, se compone de una combinación compleja de proveedores, infraestructuras, tecnologías y entornos que a menudo se implementan en múltiples nodos globales. Esta es la razón por la que muchas empresas han implementado aplicações en varias nubes diferentes (públicas, privadas e incluso una combinación de todas ellas). Esto es multi-cloud: la nueva realidad.

Incluso con este panorama en rápida evolución, varios factores están ralentizando la adopción de la nube. El primer desafío es la proliferación de múltiples nubes, donde las aplicações existentes han sido “transferidas y trasladadas” y las aplicações “nacidas en la nube” se han implementado de manera no planificada ni gestionada. Además, para satisfacer sus necesidades a corto plazo, las organizaciones tienden a utilizar distintas plataformas en la nube, arquitecturas diferentes, distintos servicios de aplicação y múltiples conjuntos de herramientas. Esto genera complejidad arquitectónica en toda la empresa y hace que trasladar aplicações de un entorno a otro sea mucho más difícil (sin mencionar que resulta costoso).

Los ADC son la evolución natural del espacio de red crítico que ocupaban los balanceadores de carga del pasado. Si bien los ADC deben mucho a aquellos dispositivos del pasado, son una clase claramente nueva que ofrece no solo disponibilidad, sino también rendimiento y seguridad. Como sugiere su nombre, se ocupan de todos los aspectos necesarios para entregar una aplicação de la mejor manera posible.

Con funciones avanzadas como inteligencia de aplicaciones, descarga de SSL e interfaces programáticas, los ADC modernos pueden ayudar a las organizaciones a escalar su negocio y llegar a los usuarios en cualquier lugar y en cualquier momento. Con las necesidades siempre cambiantes del mundo técnico, los ADC también son más capaces de adaptarse a las tecnologías más nuevas en entornos de múltiples nubes y contenedores.

Al final, podemos decir con seguridad que los ADC no solo serán el conducto principal y el punto de integración a través del cual las aplicações se entregarán de una manera más rápida, inteligente y segura, sino que continuarán evolucionando y adoptando el mundo de la nube.