Desarrollando elasticidad

Seguramente, al llegar a este artículo, ya habrás leído bastante sobre la nube o el también llamado Cloud Computing y sabrás claramente lo que es IaaS, PaaS y SaaS, por lo que no tiene caso que lo repitamos aquí y en caso contrario, sólo basta con pensar en la nube como el tener nuestros datos y aplicaciones viviendo en la computadora de alguien más, es decir, nosotros como desarrolladores de aplicaciones para la nube nos enfocamos en la forma en la que manejamos diversas cargas de trabajo al ser procesadas en una computadora existente en algún rincón del Internet.

Una de las características que hace a la nube muy atractiva es su elasticidad, que se define como los grados en los cuales un sistema es capaz de adaptarse a los cambios en las cargas de trabajo al abastecer o desabastecer recursos de manera automática, de tal manera que para cada momento en el tiempo, la cantidad de recursos disponibles corresponda lo más cercano a la demanda existente.

¿Cuál es el problema?

Supongamos que desarrollamos un portal, quizás uno que se encargue de hacer la promoción turística de un país, y nuestro cliente queda tan satisfecho con la imagen y el funcionamiento del mismo que contrata una agencia de publicidad enfocada en redes sociales, la cual coloca desde la cuenta de la celebridad pop del momento un mensaje, invitando a los seguidores de dicha celebridad a visitar el portal que acabamos de desarrollar y entonces en horas o quizás minutos, todos sus seguidores deciden visitar este portal. Como buenos desarrolladores nos aseguramos que el portal sea ágil, aproveche al máximo los recursos de los que dispone, pero el tráfico es tal, que tras un par de horas éste deja de operar o empieza a entregar errores dañando irremediablemente la imagen del portal y la nuestra como sus desarrolladores.

Solucionemos el problema

Esta triste historia pudo evitarse mediante alguna de las siguientes alternativas:

 

  • Haber comprado más infraestructura, la cual incrementaría los costos iniciales y la mayoría del tiempo se mantendría ociosa.
  • Rentar infraestructura en la nube durante el día que sabemos que ocurrirá la campaña de publicidad, lo que aún implica mantener ociosa la infraestructura por algún tiempo (ésta debió prepararse con antelación y requerirá de nuestro trabajo para regresar todo a la normalidad).
  • Aprovechar la elasticidad de la nube para el desarrollo del portal.


Siendo elásticos

Al desarrollar una aplicación elástica debemos considerar lo siguiente:
 

  • El tiempo que toma en iniciarse y configurarse una nueva máquina virtual con nuestra aplicación para que esté lista para recibir peticiones. Esto determinará los umbrales en los cuales se deberá iniciar el proceso de crecimiento de nuestra aplicación.
  • Los niveles óptimos de carga que una máquina virtual de un tamaño definido puede soportar con nuestra aplicación sin que se observe una degradación del servicio.
  • La arquitectura de la aplicación deberá estar planeada para operar en un ambiente dinámico, sin afectar los requerimientos del cliente cuando se realicen cambios en el número de instancias en las que corre la aplicación.
  • Elegir la manera más conveniente a la aplicación y al proveedor de servicios en la nube para el manejo de la elasticidad.


Según el proveedor de nube que tengamos existirán diversas maneras de poder aprovechar su nube para crear una aplicación elástica, para el caso de PaaS será tan simple como ejecutar un script que genere nuevos contenedores trabajando en el mismo grupo que nuestra aplicación, para los proveedores de IaaS en algunos se podrá hacer uso de un script que lance y configure nuevas máquinas virtuales, y en otros, será necesario crear imágenes tipo con la aplicación preinstalada que serán clonadas e iniciadas cuando se requiera crecer la infraestructura.

¿Cuál es nuestra propuesta?

En INFOTEC, contamos con el producto open source “SemanticWebBuilder Portal”, el cual cuenta con plugins para los proveedores de nube AWS de Amazon y Dimension Data para operar de manera elástica. Al instalar el plugin y realizar los requisitos previos desde la misma administración de SWB Portal, se configurarán los parámetros y umbrales para que el producto decida cuándo crear o eliminar instancias a fin de mantener los costos al mínimo sin que se observe una degradación del servicio.

SWB Portal toma muestras de tres valores en sus instancias:

  1. Consumo de CPU.
  2. Cantidad de peticiones atendidas por segundo.
  3. Tiempo de procesamiento por página.


Cuando alguno de estos parámetros rebasa los umbrales definidos por el administrador del portal y según el proveedor de nube del que se trate, se lanzará una imagen preconfigurada o lanzará y configurará una nueva instancia.

Si te interesa ver el código de como lo hicimos para el caso de AWS, se encuentra en: http://svn.semanticwebbuilder.org.mx/SemWB4/SWB4/swb/SWBAWSSupport/. Y para el caso de Dimension Data, en la siguiente liga:
http://svn.semanticwebbuilder.org.mx/SemWB4/SWB4/swb/SWBDimensionDataSupport/

(Artículo publicado originalmente en la revista Develop Network No. 6 en su edición marzo 2015)

Por Sergio Edgar Martínez Pacheco
Responsable de Seguridad y Arquitectura de Productos en INFOTEC.


Comments