Cubo de escala

El cubo de escala es un modelo tecnológico que indica tres métodos (o enfoques) mediante los cuales las plataformas tecnológicas pueden escalarse para satisfacer niveles crecientes de demanda sobre el sistema en cuestión. Los tres enfoques definidos por el modelo incluyen el escalado a través de la replicación o clonación (el “eje X”), el escalado a través de la segmentación a lo largo de los límites de servicio o componentes disímiles (el “eje Y”) y la segmentación o partición a lo largo de componentes similares (el “eje Z”). ^{[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]}

El modelo se publicó por primera vez en un libro en la primera edición de The Art of Scalability . ^{[ 7 ]} Los autores afirman que la primera publicación del modelo en línea fue en 2007 en el blog de su empresa. ^{[ 6 ]} Versiones posteriores del modelo se publicaron en la primera edición de Scalability Rules en 2011, ^{[ 8 ]} la segunda edición de The Art of Scalability en 2015 ^{[ 1 ] [ 4 ]} y la segunda edición de Scalability Rules en 2016. ^{[ 9 ]}

El eje X del modelo describe la escalabilidad de una solución tecnológica a través de múltiples instancias del mismo componente mediante la clonación de un servicio o la replicación de un conjunto de datos. Los servidores web y de aplicaciones que realizan la misma función pueden existir detrás de un balanceador de carga para escalar una solución. Los sistemas de persistencia de datos, como una base de datos, pueden replicarse para un mayor rendimiento de transacciones. ^{[ 1 ]} El eje Y del modelo describe la escalabilidad de una solución tecnológica separando una aplicación monolítica en servicios mediante verbos de acción o separando elementos "disímiles". Los datos pueden separarse mediante sustantivos. Los servicios deben tener los datos sobre los que actúan separados y aislados para ese servicio. ^{[ 1 ] [ 10 ]} El eje Z del cubo describe la escalabilidad de una solución tecnológica separando componentes a lo largo de límites "similares". Dichas separaciones pueden realizarse sobre una base geográfica, a lo largo de números de identificación de clientes, etc. ^{[ 1 ] [ 11 ]}

El escalado del eje X es el enfoque más común y suele ser el más fácil de implementar. Si bien puede resultar costoso, la rapidez con la que se puede implementar y empezar a solucionar problemas suele compensar el costo. El eje X suele ser una simple copia de un servicio que luego se somete a balanceo de carga para ayudar con los picos de tráfico o las interrupciones del servidor. Los costos pueden llegar a ser abrumadores, especialmente al tratar con la capa de persistencia. ^{[ 6 ]}

El escalado del eje Y comienza a separar fragmentos de bases de código monolíticas y crea servicios separados, o a veces microservicios. ^{[ 12 ]} Esta separación crea vías claramente definidas no solo para la responsabilidad y la rendición de cuentas, sino también para el aislamiento de fallos. Si un servicio falla, solo debería afectar a sí mismo y no a otros servicios. ^{[ 6 ] [ 13 ]}

El escalado del eje Z generalmente se basa en casos de uso de datos similares. Ya sea por su naturaleza geográfica, la forma en que los clientes utilizan el sitio web o incluso un módulo aleatorio del conjunto de datos de clientes. El eje Z divide a los clientes en secciones aisladas para optimizar el tiempo de respuesta y ayudar a eliminar problemas si una región o sección en particular deja de funcionar. ^{[ 6 ] [ 14 ]}