En su mayor parte, escalar aplicaciones y API son prácticamente lo mismo. Ambos requieren algún tipo de equilibrador de carga (normalmente un proxy) y son necesarios para distribuir las solicitudes entre un conjunto de recursos.
Pero hay una diferencia bastante significativa entre cómo se distribuyen esas solicitudes entre los recursos. En el caso de los algoritmos, en realidad estamos distribuyendo la carga, mientras que en el caso de la arquitectura, estamos dirigiendo la carga. Ahora bien, puede que parezca una distinción pedante que es mejor dejar en manos del mundo académico. La verdad es que la elección entre algoritmos y arquitectura tiene un impacto profundo en la escala y el rendimiento. Dado que ambos son la razón por la que se utiliza el equilibrio de carga, la distinción se vuelve importante.
El equilibrio de carga basado en algoritmos se puede denominar simplemente equilibrio de carga o, como a mí me gusta llamarlo, equilibrio de carga simple . Éste es el método de escala que hemos estado utilizando desde antes del cambio de siglo. Su antigüedad no significa que deba abandonarse, todo lo contrario. En muchas situaciones, el equilibrio de carga tradicional es la mejor opción para equilibrar la escala y el rendimiento.
El equilibrio de carga algorítmico tradicional utiliza, como se puede suponer, algoritmos en su proceso de toma de decisiones. Esto significa que se utilizan algoritmos de distribución como round robin, menos conexiones, respuesta más rápida y sus equivalentes ponderados para seleccionar un recurso para responder a cualquier solicitud determinada.
Esta es una decisión sencilla. Al igual que el tejón de miel, 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 esos cinco según el algoritmo. Período.
El equilibrio de carga basado en algoritmos es, como puedes imaginar, bastante rápido. No se necesita mucho tiempo utilizando la potencia de procesamiento actual para ejecutar el algoritmo apropiado y tomar una decisión. Con excepción del algoritmo round robin y ciertos algoritmos de distribución ponderada, los algoritmos son con estado. Esto significa que deben realizar un seguimiento de variables como "¿cuántas conexiones hay ahora mismo a los recursos A, B y C?" o "¿qué recurso respondió más rápido a su última solicitud?". El balanceador de carga debe realizar un seguimiento de esta información. Esta información puede crecer bastante y requerir más recursos para administrarla en entornos que escalan aplicações tradicionales y monolíticas que requieren múltiples conexiones de larga duración.
Donde el equilibrio de carga tradicional destaca es en el escalado de microservicios. Esto se debe a que cada microservicio tiene (o debería tener en una arquitectura ideal) una función. Es fácil escalar estos servicios empleando un algoritmo básico (generalmente round robin) porque generalmente son equivalentes en capacidad y rendimiento. Debido a la naturaleza de las arquitecturas de microservicios, que pueden requerir múltiples llamadas de servicio para satisfacer una sola solicitud de usuario, es imprescindible tomar decisiones rápidas. Esto hace que el equilibrio de carga basado en algoritmos básicos sea una buena opción para dichos entornos.
La regla básica es esta: si está escalando servicios simples con un conjunto limitado de funciones, todas las cuales son generalmente equivalentes en términos de rendimiento, entonces el equilibrio de carga simple será suficiente. Esto es lo que se ve dentro de los entornos de contenedores y por qué gran parte de las capacidades de escalamiento nativas se basan en algoritmos simples.
Para otras aplicações y situaciones, necesitará recurrir al equilibrio de carga basado en la arquitectura.
El equilibrio de carga basado en la arquitectura es el arte (sí, arte, no ciencia) de utilizar un equilibrador de carga para dividir y segmentar las solicitudes de una manera que coincida con la arquitectura de la aplicação que está escalando. El equilibrio de carga basado en la arquitectura tiene más que ver con dirigir el tráfico que con distribuirlo. Esto se debe a que aprovecha la capa 7 (normalmente HTTP) para decidir a dónde debe ir una solicitud determinada, y por eso solemos llamarlo equilibrio de carga HTTP (entre otros términos más esotéricos (y centrados en redes)).
La capacidad de dirigir solicitudes es cada vez más importante en un mundo expuesto por API y construido sobre microservicios. Esto se debe a que necesita poder dirigir solicitudes de API en función de la versión, usar nombres de host o rutas URI para enviar solicitudes a microservicios específicos o descomponer la funcionalidad de una aplicação.
La mayoría de las organizaciones quieren exponer una API consistente que sea fácil de usar. Ya sea para alentar a los desarrolladores ciudadanos a crear nuevas aplicações que usen la API o para permitir que los socios se conecten e integren fácilmente, una API consistente y simple es fundamental para garantizar la adopción.
Pero en realidad las API suelen ser confusas. Están respaldados por múltiples servicios (a menudo microservicios) y pueden distribuirse en diferentes ubicaciones. Rara vez se limitan a un solo servicio. Los asuntos son complicados, se actualizan con más frecuencia que las generaciones anteriores de aplicaciones y no son compatibles con versiones anteriores de forma fiable. Además, las aplicaciones móviles pueden utilizar recursos antiguos y nuevos: compartir imágenes con aplicaciones web y utilizar las mismas API que todos los demás.
Para escalar estas “aplicaciones” y API se requiere un enfoque arquitectónico para equilibrar la carga. Es necesario dirigir el tráfico antes de distribuirlo, lo que implica utilizar un balanceador de carga con capacidad de capa 7 (HTTP) para implementar patrones arquitectónicos como envío de URL, partición de datos y descomposición funcional. Cada uno de estos patrones es de naturaleza arquitectónica y requiere una mayor afinidad hacia el diseño de la aplicação o API que la que se da en las aplicaciones tradicionales.
El equilibrio de carga HTTP es cada vez más importante en la búsqueda de escalar aplicaciones y al mismo tiempo equilibrar la eficiencia con la agilidad, además de brindar soporte a las API.
Rara vez verás solo un tipo de escala en el mundo real. Esto se debe a que las organizaciones ofrecen cada vez más un conjunto sólido de aplicações que abarcan décadas de desarrollo, arquitecturas de aplicaciones, plataformas y tecnologías. Muy pocas organizaciones pueden jactarse de brindar soporte únicamente para aplicações “modernas” (a menos que “moderno” incluya algo que no se ejecute en un mainframe).
Por lo tanto, es probable que veas (y uses) equilibrio de carga tanto algorítmico como arquitectónico para escalar una variedad de aplicações. Por eso es importante comprender la diferencia, porque usar uno cuando el otro es más apropiado puede generar un rendimiento deficiente o interrupciones, ninguna de las cuales es buena para los usuarios, el negocio o usted, en realidad.
Cada vez más veremos los dos enfoques combinados para escalar aplicações modernas. A veces, ambos existirán realmente como un único servicio diseñado para escalar lo lógico (la API) y lo físico (el servicio real detrás de la API). Los controladores de entrega de aplicação (ADC) suelen ser la plataforma en la que se implementa un enfoque combinado porque pueden realizar ambas tareas con la misma rapidez.
A veces, estas tareas se realizan mediante dos sistemas diferentes. Por ejemplo, en entornos en contenedores, un controlador de ingreso es responsable del equilibrio de carga arquitectónico, mientras que los servicios nativos internos generalmente son responsables de la escala mediante el equilibrio de carga algorítmico.
Independientemente de los detalles de implementación y despliegue, la realidad es que tanto los enfoques algorítmicos como los basados en la arquitectura para el equilibrio de carga tienen un papel que desempeñar en el escalamiento de aplicaciones y API. La clave para maximizar sus fortalezas en su beneficio es adaptar el equilibrio de carga a la arquitectura de la aplicação .
Escala activada.