En general, las aplicaciones se crean de forma monolítica al principio. Las aplicaciones monolíticas funcionan muy bien cuando hay un número menor de usuarios y el tráfico es muy bajo. Pero, cuando aumenta el tráfico, el sistema se sobrecarga y se ralentiza, lo que da como resultado un bajo rendimiento, latencia y fallas del sistema.
De acuerdo con el modelo de cubo AKF Scale, para lograr la escalabilidad, la aplicación debe escalarse en 3 dimensiones. A saber, X, Y y Z. Este enfoque se puede utilizar para escalar una aplicación infinitamente.
El cubo de escala
Escalado del eje X: replicación y clonación
Es una aplicación de replicación y clonación. Comprende la ejecución de una serie de aplicaciones que realizan la misma tarea o bases de datos clonadas que almacenan los mismos datos. Estas copias se ejecutan detrás de un balanceador de carga. El balanceador de carga distribuye equitativamente la carga entre todos los sistemas de clonación. Es un enfoque muy común y fácil de entender para escalar una aplicación.
Ventajas del escalado del eje X:
- es intelectualmente muy facil
- Maneja el escalado de transacciones decentemente.
- La implementación es muy rápida.
Desventajas de la escala del eje X:
- El costo de configuración es elevado ya que se utilizan múltiples clones de bases de datos.
- Tampoco es compatible con el almacenamiento en caché de manera eficiente. El caché requiere más memoria.
- No es compatible con el escalado organizativo.
- No es compatible con la complejidad de la aplicación y el aumento del desarrollo.
Escalado del eje Y: división de cosas diferentes
Divide la aplicación en varios servicios separados. Un servicio solo es responsable de una sola función. También puede ser de grano fino y acoplarse libremente cuando estos servicios se distribuyen más separados. La arquitectura de microservicios es principalmente una aplicación de Y-Scaling. Hay muchos enfoques para descomponer la aplicación. En términos generales, hay dos: basados en verbos (un servicio responsable de implementar un caso de uso) y basados en sustantivos (un servicio responsable de manejar todas las operaciones y que pertenecen a una sola entidad). Un buen enfoque es utilizar una combinación de ambos.
Ventajas del escalado del eje Y –
- Permite el escalamiento organizacional
- El aislamiento de fallas, las pruebas y la depuración son fáciles
- La tasa de aciertos de caché aumenta significativamente
- Las transacciones escalan bien
Desventajas de la escala del eje Y –
- Se necesita mucho análisis e intelecto para encontrar la descomposición perfecta que se adapte a la aplicación.
- Se necesita tiempo para implementar
Escalado del eje Z: división de cosas similares
Es bastante similar a X-Scaling y, por lo tanto, se confunde mucho. Aquí, cada réplica ejecuta la misma copia de código. Pero cada réplica no está haciendo exactamente lo mismo. La carga de trabajo se distribuye entre ellos. Una réplica solo funciona en un subconjunto de datos. Una parte de la aplicación enruta cada solicitud al servidor apropiado. Se puede hacer sobre una base geográfica para aumentar la velocidad de respuesta. También se hace sobre la base del cliente. Por ejemplo, un cliente privilegiado de una aplicación se enrutará a un conjunto de servidores más rápido. Al igual que hay muchos servidores de descarga que limitan la velocidad de descarga para los clientes que no pagan.
Ventajas de la escala Z –
- Es intelectualmente fácil de implementar. Reduce la cantidad de uso de memoria y el tráfico que maneja un servidor.
- También aumenta el golpe de caché de manera muy significativa.
- Mejora el escalado transaccional a medida que se distribuyen las requests.
- También mejora el aislamiento de fallas, ya que una falla del servidor no hace que todas las partes de los datos sean inaccesibles.
Desventajas de la escala Z –
- Se necesita tiempo para implementar
- No habla de escalamiento organizacional
- Requiere automatización para reducir los saltos