En general, escalar aplicaciones y API es prácticamente lo mismo. Ambas necesitan algún tipo de equilibrador de carga —normalmente un proxy— para distribuir las solicitudes entre un conjunto de recursos.
Pero hay una diferencia bastante significativa en cómo se distribuyen esas solicitudes entre los recursos. En el caso de los algoritmos, realmente estamos distribuyendo la carga, mientras que, en el caso de la arquitectura, estamos dirigiéndola. Puede que esto parezca una distinción pedante que sería mejor dejar en manos del mundo académico. Lo cierto es que elegir entre algoritmos y arquitectura tiene un profundo impacto en la escalabilidad y el rendimiento. Dado que ambos son, en cierto modo, la razón por la que se utiliza el balanceo de carga, esta distinción cobra importancia.
Balanceo de carga tradicional
El balanceo de carga basado en algoritmos puede denominarse simplemente balanceo de carga o, como me gusta llamarlo, balanceo de carga tradicional. Este es el método de escalado que utilizamos desde antes del cambio de siglo. Su antigüedad no significa que deba abandonarse; más bien al contrario. En muchas situaciones, el balanceo de carga tradicional es la mejor opción para lograr un equilibrio entre escalabilidad y rendimiento.
Como cabría esperar, el balanceo de carga algorítmico tradicional utiliza algoritmos en su proceso de toma de decisiones. Esto significa que se emplean algoritmos de distribución como round robin, menor número de conexiones, respuesta más rápida y sus equivalentes ponderados para seleccionar el recurso que responderá a cada solicitud.
Es una decisión sencilla. Al igual que al tejón melero, a los algoritmos no les importa nada más que ejecutarse en función de los datos disponibles. Si hay cinco recursos disponibles, se seleccionará uno de ellos según el algoritmo. Punto.
El balanceo de carga basado en algoritmos es, como cabe imaginar, bastante rápido. Con la capacidad de procesamiento actual, ejecutar el algoritmo adecuado y tomar una decisión lleva muy poco tiempo. A excepción del algoritmo round robin y de determinados algoritmos de distribución ponderada, los algoritmos mantienen información de estado. Esto significa que deben realizar un seguimiento de variables como «¿cuántas conexiones hay ahora mismo con los recursos A, B y C?» o «¿Qué recurso respondió más rápido a la última solicitud?». El balanceador de carga debe llevar un registro de esta información, que puede llegar a ser muy voluminosa y requerir más recursos para gestionarla en entornos donde se escalan aplicaciones monolíticas tradicionales que necesitan múltiples conexiones de larga duración.
Donde el balanceo de carga tradicional destaca especialmente es en el escalado de microservicios. Esto se debe a que cada microservicio tiene (o debería tener, en una arquitectura ideal) una única función. Estos servicios se pueden escalar fácilmente mediante un algoritmo básico (normalmente, round robin), ya que suelen ser equivalentes en cuanto a capacidad y rendimiento. Debido a la naturaleza de las arquitecturas de microservicios, que pueden requerir varias llamadas a servicios para atender una sola solicitud de usuario, es imprescindible tomar decisiones con rapidez. Por ello, el balanceo de carga básico basado en algoritmos es una buena opción para este tipo de entornos.
La regla general básica es la siguiente: si se están escalando servicios sencillos con un conjunto limitado de funciones, todas ellas generalmente equivalentes en términos de rendimiento, bastará con el balanceo de carga tradicional. Esto es lo que se observa dentro de los entornos de contenedores y la razón por la que gran parte de las capacidades de escalado nativas se basan en algoritmos sencillos.
Para otras aplicaciones y situaciones, deberá recurrir al balanceo de carga basado en la arquitectura.
Balanceo de carga HTTP
El balanceo de carga basado en la arquitectura es el arte (sí, arte, no ciencia) de utilizar un balanceador de carga para segmentar y dividir las solicitudes de forma que se adapten a la arquitectura de la aplicación que se está escalando. El balanceo de carga basado en la arquitectura consiste más en dirigir el tráfico que en distribuirlo. Esto se debe a que aprovecha la capa 7 (normalmente HTTP) para decidir adónde debe dirigirse una solicitud determinada, razón por la que solemos denominarlo balanceo de carga HTTP (entre otros términos más esotéricos y centrados en las redes).
La capacidad de dirigir las solicitudes es cada vez más importante en un mundo expuesto mediante API y basado en microservicios. Esto se debe a que es necesario poder dirigir las solicitudes de API en función de la versión, utilizar nombres de host o rutas URI para enviar solicitudes a microservicios específicos o descomponer una aplicación por funcionalidades.
La mayoría de las organizaciones quieren ofrecer una API coherente y fácil de usar. Ya sea para animar a desarrolladores no profesionales a crear nuevas aplicaciones que utilicen la API o para permitir que los socios se conecten e integren fácilmente, contar con una API sencilla y coherente es fundamental para garantizar su adopción.
Pero, en la práctica, las API suelen ser complejas. Se sustentan en varios servicios (a menudo microservicios) y pueden estar distribuidas entre distintas ubicaciones. Rara vez se limitan a un único servicio. Para complicar aún más las cosas, se actualizan con mayor frecuencia que las generaciones anteriores de aplicaciones y no siempre mantienen la compatibilidad con versiones anteriores. Además, las aplicaciones móviles pueden utilizar tanto recursos antiguos como nuevos, compartir imágenes con aplicaciones web y usar las mismas API que el resto.
Para escalar estas «aplicaciones» y API se requiere un enfoque arquitectónico del balanceo de carga. Es necesario dirigir el tráfico antes de distribuirlo, lo que implica utilizar un balanceador de carga compatible con la capa 7 (HTTP) para implementar patrones arquitectónicos como el enrutamiento de URL, la partición de datos y la descomposición funcional. Cada uno de estos patrones es de naturaleza arquitectónica y requiere una mayor afinidad con el diseño de la aplicación o la API que en el caso de las aplicaciones tradicionales.
El balanceo de carga HTTP es cada vez más importante para escalar las aplicaciones, mantener el equilibrio entre eficiencia y agilidad, y ofrecer compatibilidad con las API.
La escalabilidad requiere ambas
En el mundo real, rara vez se observa un único tipo de escalabilidad. Esto se debe a que las organizaciones ofrecen cada vez más un sólido conjunto de aplicaciones que abarca décadas de desarrollo, arquitecturas de aplicaciones, plataformas y tecnologías. Muy pocas organizaciones pueden presumir de admitir únicamente aplicaciones «modernas» (a menos que por «modernas» se entienda cualquier aplicación que no se ejecute en un mainframe).
Por tanto, es probable que veas —y utilices— tanto el balanceo de carga algorítmico como el arquitectónico para escalar diversas aplicaciones. Por eso es importante entender la diferencia, ya que utilizar uno cuando el otro resulta más adecuado puede provocar un rendimiento deficiente o interrupciones del servicio, algo que no beneficia ni a los usuarios, ni a la empresa ni, por supuesto, a ti.
Cada vez será más habitual ver ambos enfoques combinados para escalar aplicaciones modernas. En ocasiones, ambos coexistirán como un único servicio diseñado para escalar tanto la parte lógica (la API) como la física (el servicio real que hay detrás de la API). Los controladores de entrega de aplicaciones (ADC) suelen ser la plataforma en la que se implementa este enfoque combinado, ya que pueden realizar ambas tareas con la misma agilidad.
A veces, estas tareas las realizan dos sistemas diferentes. Por ejemplo, en entornos en contenedores, un controlador de entrada se encarga del balanceo de carga arquitectónico, mientras que los servicios internos y nativos suelen encargarse del escalado mediante el balanceo de carga algorítmico.
Independientemente de los detalles de implementación y despliegue, lo cierto es que tanto los enfoques algorítmicos como los basados en la arquitectura para el balanceo de carga desempeñan un papel importante a la hora de escalar aplicaciones y API. La clave para aprovechar al máximo sus ventajas es adaptar el balanceo de carga a la arquitectura de la aplicación.
Sigue escalando.
Sobre el autor
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 VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.