En mi post anterior, he explicado el concepto de elasticidad como la capacidad de mover los recursos dentro de una infraestructura virtual para cumplir con las demandas de negocios y los picos de actividad, estos últimos no siempre predecibles.

Pero la elasticidad no significa unicamente la capacidad de «inflar» la infraestructura mediante la adición de recursos, pero – y sobre todo – poder «desinflarla» mediante la reasignación de esos recursos en otra parte.

Como un globo, más elástica la infraestructura, más fácil de inflar y desinflarla.

También es necesario que las aplicaciones están programadas con la elasticidad en los objetivos.

 

La elasticidad de una aplicación supone:

• Escalabilidad: mantener el rendimiento de las aplicaciones cuando aumenta el número de usuarios – y por consecuencia el volumen de datos.
• La capacidad de liberar recursos cuando la carga disminuye.

Hay dos tipos de escalabilidad:

• La escalabilidad horizontal consiste en distribuir una aplicación en diferentes máquinas. Por ejemplo, añadir instancias adicionales del servidor de aplicaciones y utilizar un load-balancer para equilibrar la carga.
• La escalabilidad vertical es aumentar la capacidad (memoria, CPU, disco duro) en la máquina que aloja la aplicación.

Escalabilidad horizontal

La escalabilidad horizontal no es muy elástica, ya que supone añadir más o menos manualmente las instancias de arquitectura que se necesitan y que estarán inutilizadas cuando no se encuentran picos de actividad. En otras palabras, se infla el globo, pero no se saben desinflar. Sin embargo, es el caso que encontraremos con más frecuencia. No muy dinámico.

Y mantener una infraestructura basada en la redundancia de diferentes partes de la arquitectura de la aplicación resulta en en una infraestructura de gran tamaño para hacer frente a picos de actividad, pero sin usar más del 10 o 20% de la capacidad el resto del tiempo. Pocas ventajas sobre a una infraestructura física.

Escalabilidad vertical

La escalabilidad vertical es mucho más elástica. Se instala la aplicación en una máquina virtual que se llevará 50% de los recursos en situaciones normales, dentro de un servidor que aloja otras máquinas virtuales con aplicaciones sin tanta variación de la carga. Si hay un pico de actividad imprevisto y violento de la máquina virtual, esta puede pedir prestado recursos a las máquinas en el mismo servidor. La capacidad de tomar prestado memoria también se conoce como ‘ballooning’ (para VMWare). Una vez pasado el pico de carga, la máquina virtual va a liberar los recursos prestados y devolverlos a sus vecinas. Todo ello de forma dinámica, con menos saturación posible.

Sin embargo, la escalabilidad vertical alcanza rápidamente sus límites: no se puede aumentar indefinidamente la CPU o el rendimiento de un disco duro. Puede inflar y desinflar el globo, pero dentro de unos límites.

La elasticidad del Cloud

Cualquier aplicación ganará en fuerza en el Cloud.

Por ejemplo, algunos tratamientos consumidores de memoria, como la creación de un objeto, no se deben realizar dentro de un bucle. Muy a menudo, los bucles se utilizan para realizar procesamiento de datos de una tabla. Más datos contiene la tabla, más alto el número de iteraciones del bucle, mayor es la creación de objetos y el consumo de memoria. Cuantos más usuarios será, más el servidor de aplicaciones realizará estos tratamientos y requerirá memoria.

Esto es un ejemplo típico de una aplicación con una escalabilidad baja que se puede superar mediante la adición ‘elástica’ de memoria durante una actividad máxima.

Otro ejemplo: un load-balancer y dos servidores de aplicaciones en dos máquinas virtuales. Así que tienes dos copias del mismo software – el servidor de aplicación – instaladas en memoria. Si el hipervisor de maquinas virtuales es capaz de detectar estos tipos de memorias idénticas, se puede establecer un mecanismo para compartir la memoria con el fin de usar un único espacio de memoria que se accede por las dos máquinas virtuales. Esto ahorra memoria.

Elasticidad de las aplicaciones

Algunas técnicas de programación ayudarán a hacer las aplicaciones más o menos elásticas. La primera y la más citada es hacer la aplicación la más stateless posible. ¿Qué significa esto?

En pocas palabras, una aplicación stateful almacena en memoria los datos de la sesión del usuario y de su contexto. La sesión se mantiene en el mismo servidor, siempre y cuando el usuario está conectado: no es posible la transferencia de sesiones – los datos almacenados en la memoria – entre servidores cuando es posible para un servicio stateless.

Imaginemos un sitio web de tienda online, con una alta actividad entre las 9:00 y las 17:00, que corresponde a 10 000 usuarios que están repartidos en 10 servidores. Si la aplicación es stateful, todos los datos se almacenan en la memoria, incluyendo la identificación del usuario, y la memoria se libera sólo cuando el deja el sitio al cerrar la sesión. Si el 10% de los usuarios se olvide de cerrar la sesión, o si la actividad cae a 1 000 usuarios, entonces vamos a mantener en la memoria 1 000 sesiones … repartidas en los 10 servidores. En otras palabras, la aplicación utilizará el 10% de los 10 servidores cuando sería suficiente un unico servidor.

Ahora bien, si la aplicación es completamente stateless, la sesión no se guarda en memoria y por lo tanto, no está atada a un servidor. Aunque 10% de las sesiones permanecen activas, será posible liberar los servidores como y cuando la actividad disminuye, para mantener un servidor ocupado al 100% (o más bien dos servidores ocupados a 50%).

Es difícil programar aplicaciones completamente stateless, ya que debemos almacenar los datos en alguna parte, y si no en la memoria, será en la base de datos, por lo menos temporalmente. Pero el acceso a una base de datos es más caro en rendimiento que un acceso en memoria. Por lo tanto, se tratará de desarrollar la aplicación en módulos diferentes o diferentes sub-aplicaciones, algunos stateless, otros stateful.

Por ejemplo, la aplicación que gestiona la cesta del usuario se beneficiará de ser programada en modo stateful, con varias ventajas:

• Se trata de datos que son los más accesidos y modificados durante la sesión, así que se requiere el mejor rendimiento: nada peor que tener que esperar 10 segundos cada vez que se agrega un nuevo elemento en la cesta, vas a salir del sitio rápidamente y jamás volverás.
• La cesta tiene una vida limitada: por lo general de 30 a 60 minutos. Si un usuario permanece conectado sin actualización, la sesión se elimina de la memoria al final de este período, y se ‘desinfla’ la memoria. Esto resuelve el problema del 10% de los usuarios que se olvidan de cerrar la sesión.

Otros datos, como la identificación del usuario, pueden ser administrados por un módulo stateless con una tabla temporal. Nota importante: también vemos en este ejemplo lo importante que es de pensar en términos de tiempo de vida de cada módulo y programarlo a través de un time-out.

Asincronismo es otro mecanismo que promueve la elasticidad. El procesamiento de la cesta en una tienda online no termina con la finalización de la compra y el pago: se deben utilizar los datos para la preparación del paquete, su entrega, los datos en la contabilidad, la transferencia entre bancos, sin hablar de procesos de CRM (Customer Relationship Management) y otras cosas que hacen vivir la gente de marketing. Pero todos estos tratamientos no son urgentes y se pueden hacer cuando los servidores están menos ocupados durante la noche por ejemplo.

Por lo tanto, se tratará de separar el front-end – la tienda online – del back-end mediante el envío de un mensaje de forma asincrónica a la contabilidad y las aplicaciones de logística, con los datos del pedido para que sean processados durante el tiempo de actividad más baja en los servidores con los recursos liberados

El principal obstáculo para la elasticidad de las aplicaciones es en mi opinión, en la base de datos, sin duda el más difícil «escalable» horizontalmente. La gestión de la persistencia necesitará una vez más una cierta modularidad que permite distribuir la información en bases de datos diferentes.

Por último, creo que la realización de aplicaciones elásticas van a introducir profundos cambios en las metodologías y los ciclos de los proyectos, como una mejor integración entre los equipos de desarrollo, de control de calidad y de producción. Una especie de fusión entre ITIL y Agil.

La principal preocupación de los equipos de desarrollo y de QA es entregar aplicaciones en tiempo y con la mejor calidad posible, no el consumo de recursos. A menos que tengamos equipos de proyecto dedicados a la realización de aplicaciones virtualizadas, tomar en cuenta el consumo de recursos o la elasticidad no está en el orden del día. El único punto donde estos dos mundos se encuentran es en la disponibilidad de servicios y por lo tanto, los acuerdos de nivel de servicio (Service Level Agreement).

Así que estoy convencido de que cada desarrollador tendrá que agregar conocimiento de virtualización en su CV y que cada empresa de servicios tendrá que adquirir estas habilidades y metodologías para desarrollar aplicaciones elásticas.

El Cloud está saliendo de las salas de máquinas. Prepárate.

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