Como hemos visto en un post anterior – La calidad en el cloud – la reducción de costes sigue siendo la principal motivación para la virtualización y el Cloud, luego la capacidad de entregar la capacidad.

Cuando se trata de dimensionar la infraestructura física y un presupuesto operativo, el modelo es el siguiente:

• Planificar la caraga máxima requerida, incluso para cumplir con los picos de actividad.
• Evaluar el crecimiento a medio / largo plazo.
• Añadir un margen de seguridad.

Una arquitectura basada en servidores físicos es necesariamente sobredimensionada en relación con las necesidades. Pregunta a cualquier ingeniero de producción: 20% a 40% de los servidores físicos alojan aplicaciones que utilizan menos del 10% de su CPU. Puedes compartir estas aplicaciones en múltiples máquinas virtuales (VMs) dentro de un único servidor y liberar los otros servidores para reasignarlos en la infraestructura.

Reducción de costes: hacer más con menos.

Gestión de capacidad

Entregar la capacidad es la segunda razón más importante: para responder con mayor reactividad a las peticiones de los usuarios. Antes, cuando uno necesitaba un nuevo servidor, había que esperar, a menudo por varias semanas, el tiempo del pedido y de la entrega y de instalación de la máquina. Hoy en día, se necesitan sólo 3 clics de ratón para instalar una máquina virtual, y los usuarios se han acostumbrado a ver sus requisitos cumplidos dentro de 24 horas.

Esto conduce también al fenómeno bien conocido como proliferación de VMs, con el resultado de reducir las ganancias conseguidas anteriormente por la reducción de los costes de infraestructura. Es fácil de instalar nuevas máquinas virtuales, pero esto representa un costo en términos de recursos, de licencias y de gastos de personal para administrar la infraestructura virtual.

La gestión de la capacidad no es sólo para responder a las peticiones de los usuarios, sino también para hacer frente de manera segura y con máxima reactividad a los picos de actividad. Hacer más pero también mejor, con menos. Este es uno de los beneficios de la virtualización para mover los recursos según sea necesario. Nada peor para la imagen de una empresa que un sitio web inaccesible, y si se trata de un sitio comercial, cualquier interrupción equivale a un accidente industrial.

A pesar de esto, no es raro que los gestores de la producción, el responsable de la infraestructura o el administrador de la capacidad no sean notificados cuando una nueva versión de la aplicación generará un incremento en la actividad. Además, estos picos no siempre son predecibles.

Por último, desde una perspectiva de desarrollo, esta capacidad de responder a las variaciones en la actividad no siempre se incluye en los objetivos del proyecto. Entregar una aplicación a tiempo, con las nuevas características implementadas sin defectos o errores, eso es la prioridad. Asegurarse de que la aplicación es lo suficientemente elástica como para reaccionar correctamente a los cambios en la carga no suele ser un objetivo integrado en el ciclo del proyecto, a menos sin que haya algún evento especial.

Una vez vi a un cliente pedir una auditoría de calidad de su código para comprobar si los programadores conocían y aplicaban correctamente las mejores prácticas de rendimiento. Era una aplicación crítica, que debía ver triplicado su número de usuarios, y entonces los datos. Aparte de tal caso en que el rendimiento – de hecho, la escalabilidad – se incluyó en los objetivos del proyecto, es raro que se considera crítico cuando se trata de identificar el impacto de las nuevas características de una aplicación.

Por supuesto, te preocupas por las buenas prácticas en el rendimiento, pero ¿qué hay de integrar la elasticidad de tu aplicación dentro de tu proyecto?

Elasticidad

El término de la elasticidad proviene del mundo del Cloud. Es un criterio importante de la calidad de una infraestructura virtual: la posibilidad de añadir o eliminar, es decir de mover los recursos (CPU, memoria, espacio y rendimiento de disco duro, principalmente) para cumplir con las necesidades de capacidad.
Imagínete que la infraestructura virtual es un globo: inflar o desinflar un globo más o menos fácilmente o rápidamente depende de su elasticidad.

Medimos la elasticidad con criterios tales como:

• Velocidad para mover los recursos necesarios – para inflar / desinflar el globo.
• La cantidad de estos recursos desplazados.
• La capacidad de mover únicamente a algunos recursos – memoria, CPU, espacio en disco.

La elasticidad es necesaria para satisfacer los picos de actividad y las necesidades de escalabilidad. Pero los dos conceptos no deben confundirse.

Escalabilidad

La escalabilidad es la capacidad para cumplir con el aumento de la carga mediante la adición de recursos. Se puede medir como un ratio carga / recursos. Si una aplicación permite un rendimiento satisfactorio, con N recursos para X usuarios, y si el rendimiento sigue siendo igual de multiplicar los recursos por 2 cuando el número de usuarios se multiplica por 2, entonces esta aplicación tiene una buena escalabilidad. Si esta relación se mantiene constante con el aumento de los dos factores, la escalabilidad es lineal. Este es optimal. Sin embargo, es más probable que algunos componentes no están a la altura deseada, y por lo tanto que el rendimiento se estabiliza en un determinado umbral, a pesar de la adición de recursos adicionales.

La elasticidad es la capacidad de agregar – o disminuir – estos recursos en una infraestructura virtual. La elasticidad incluye la escalabilidad, pero una aplicación ‘escalable’ no es necesariamente una aplicación elástica. Por ejemplo, realizar load balancing para distribuir la carga entre dos servidores de aplicaciones permite garantizar un tiempo de respuesta y un rendimiento adecuado, sea cual sea el número de usuarios, incluso durante los períodos de pico de actividad inesperada.

Pero si no puedes regresar automáticamente a una arquitectura con un único servidor de aplicaciones, sin load balancing, no se puede desinflar el globo, tu aplicación no es elástica.

¿Cómo tener en cuenta la elasticidad en tu proyecto? ¿Cuál es la elasticidad de una aplicación? ¿Qué aplicaciones se ven afectadas? De hecho, si empezamos a ver anuncios de editores de software sobre este tema, no he encontrado muchas respuestas concretas a estas preguntas, desde la perspectiva del desarrollador o del arquitecto. Esto es lo que trataremos de hacer en nuestro próximo post.

Mientras tanto, cualquier comentario será bienvenido.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.