¿Qué es la escalabilidad?

En el mundo empresarial, el crecimiento puede ser beneficioso. Sin embargo, cuando el crecimiento se produce demasiado rápido y, cuando no lo ha preparado adecuadamente, el crecimiento puede crear problemas. Uno de estos problemas es el efecto del crecimiento en la confiabilidad de las aplicaciones y servicios que no se diseñaron para controlar un gran aumento del tráfico.

Para los clientes y usuarios, una interrupción es una interrupción. No saben ni importan si no pueden acceder a su sitio debido al código de error o porque demasiadas otras personas están intentando usar su sitio perfectamente codificado al mismo tiempo.

La escalabilidad es la capacidad de adaptarse a las mayores demandas o a las necesidades cambiantes. Las aplicaciones y los servicios deben ser capaces de controlar una mayor cantidad de carga de trabajo para dar cabida al crecimiento. Las aplicaciones escalables pueden controlar un número creciente de solicitudes a lo largo del tiempo sin un efecto negativo en la disponibilidad o el rendimiento.

En esta unidad, obtendrá información sobre la relación entre escalabilidad y confiabilidad, la importancia del planeamiento de la capacidad para lograr la escalabilidad y revisar brevemente algunos conceptos básicos y términos relacionados con el escalado.

Relación de escalabilidad y confiabilidad

La buena noticia es que hacer que la aplicación sea más escalable también puede hacer que sea más confiable. Por ejemplo, si el sistema se escala automáticamente, se da un error de componente en una sola máquina virtual, el servicio de escalado automático aprovisiona otra instancia para cumplir los requisitos mínimos de recuento de máquinas virtuales (VM). El sistema se vuelve más confiable. En otro ejemplo, usa un servicio de nivel superior, como Azure Storage, que es intrínsecamente escalable. Si tiene un problema de almacenamiento, el servicio se crea para que sea confiable, por lo que los datos se replican.

Esta es una analogía: Piense en las rampas de accesibilidad que a menudo se ven fuera de los edificios diseñados inicialmente para acomodar personas en sillas de ruedas. Sirven para ese propósito. Pero también son utilizados por los padres con bebés en cochecitos o carruajes, o por niños pequeños para los que los pasos de escalera son demasiado profundos o altos. Este uso es una ventaja secundaria.

La confiabilidad suele ser una ventaja secundaria de la escalabilidad. Si diseña los sistemas para que sean escalables, es probable que también sean más confiables.

Escalabilidad y planeamiento de capacidad

El planeamiento de la capacidad implica determinar los recursos que necesita para satisfacer las demandas actuales y futuras. Para ello, analizará el uso actual de los recursos y, a continuación, proyectará el crecimiento futuro.

Para calcular las necesidades de capacidad en el futuro, debe tener en cuenta factores como:

• Crecimiento empresarial esperado
• Fluctuaciones periódicas (estacionales, etc.)
• Restricciones de aplicación
• Identificación de cuellos de botella y factores de limitación

También debe establecer objetivos de nivel de servicio para que pueda crear un plan de administración de capacidad que cumpla o supere esos objetivos de forma confiable a medida que cambie la carga de trabajo y el entorno.

El planeamiento de la capacidad es un proceso iterativo. A medida que se recorre este módulo, aprenderá a asignar los requisitos de recursos para los componentes de la aplicación.

Conceptos y terminología

Para poder comprender completamente los conceptos y las estrategias que encuentre en este módulo, necesita algunos conocimientos previos de algunos conceptos básicos y términos fundamentales relacionados con el escalado.

• Escalado vertical: hacer que un componente sea más grande para controlar una mayor carga de trabajo. También se conoce como escalado vertical.
• Escalado horizontal: agregar más componentes o recursos para distribuir la carga a través de una arquitectura distribuida. Por ejemplo, mediante una arquitectura sencilla que tiene varios back-end detrás de un conjunto de servidores front-end. A medida que aumenta la carga, agregamos más servidores back-end (y front-end) para controlarlos. También se conoce como escalado horizontal.
• Escalado manual: la acción humana es necesaria para aumentar la cantidad de recursos.
• Escalado automático: el sistema ajusta automáticamente la cantidad de recursos en función de la carga. Para ser claros, la cantidad se ajusta tanto hacia arriba como hacia abajo en función de una carga aumentada o reducida.
• Escala de DIY: escalado por sí mismo por el que tiene que configurar el escalado automático.
• Escala inherente: servicios creados para ser escalables y controlar este escalado para usted en segundo plano sin intervención alguna en su parte. Desde la perspectiva, se ven casi infinitamente escalables porque solo puede consumir más recursos sin necesidad de aprovisionarlos manualmente.

Arquitectura de Tailwind Traders

En este módulo, vamos a usar una arquitectura de ejemplo de una empresa de hardware ficticia denominada Tailwind Traders. Su plataforma de comercio electrónico tiene este aspecto:

Este diagrama es bastante complejo a primera vista, por lo que vamos a recorrerlo. El sitio web tiene un front-end. eso es lo que hablas si vas a tailwindtraders.com.

El front-end se comunica con un conjunto de servicios back-end. Estos servicios back-end incluyen los elementos comunes, como un servicio de cupones, un servicio de carro de la compra, un servicio de inventario, etc. Todos se ejecutan en Azure Kubernetes Service. Hay otras partes y tecnologías en juego con esta aplicación. Todo lo que necesita centrarse es el front-end y los servicios back-end que se ejecutan en Kubernetes.

Puntos únicos de error

Ahora que ha visto toda la arquitectura, dediquemos un momento a examinar los únicos puntos de error y los lugares en los que podríamos prestar atención al pensar en el escalado.

Todos estos servicios son un único punto de error: no se compilan para la resistencia ni para la escala. Si uno de ellos se sobrecarga, es probable que se bloquee y no hay ninguna manera fácil de resolverlo en el momento.

Más adelante en este módulo, veremos otras formas de diseñar este servicio para que sea más escalable y confiable.

Capacidad aprovisionada previamente

Echemos un vistazo a otro problema que podría resultar problemático. Estos son los servicios o componentes que requieren que se aprovisione previamente la capacidad:

Por ejemplo, con Cosmos DB, aprovisionamos previamente el rendimiento. Si superamos esos límites, empezaremos a devolver mensajes de error a nuestros clientes. Con los servicios de Azure AI, seleccionamos el nivel y ese nivel tiene un número máximo de solicitudes por segundo. Después de alcanzar cualquiera de los límites, los clientes se limitarán.

¿Se producirá un pico significativo en el tráfico, como el lanzamiento de un nuevo producto, nos hará alcanzar estos límites? En este momento, no lo sabemos. Este asunto es otro que revisamos más adelante en este módulo.

Costos

Incluso cuando hacemos las cosas bien, todavía necesitamos planear el crecimiento. Estos son los servicios de pago por uso:

Aquí, usamos Azure Logic Apps y Azure Functions, que son ejemplos de tecnología sin servidor. Estos servicios se escalan automáticamente y pagamos por solicitud. La factura crece a medida que lo hace la base de clientes. Al menos debemos tener en cuenta el impacto que pueden tener los próximos eventos, como un lanzamiento de productos, en nuestro gasto en la nube. También trabajamos para comprender y predecir el gasto en la nube más adelante en este módulo.