Muchas veces, cuando hablamos de alojar determinados servicios TI en el Cloud lo asociamos con el proceso de virtualizar servidores existentes donde albergamos aplicaciones, para finalmente ejecutarlos en alguna entorno de virtualización de nuestro proveedor de confianza. Esto, por sí solo, no hace que nuestra aplicación se haya convertido en «cloud», es decir, aún no podemos disfrutar de muchas de las ventajas que los evangelistas del cloud predican, ya que, estamos pasando por alto un aspecto muy importante: la arquitectura de los servicios o aplicaciones que queremos ejecutar.
Pero, para poder utilizar y aprovechar las ventajas que ofrecen en términos de flexibilidad y escalabilidad las plataformas Cloud, es necesario en primer lugar, que nuestras aplicaciones estén preparadas. Definimos entonces escalabilidad como, la capacidad del software para adaptarse al crecimiento y a las necesidades de rendimiento a medida que el número de usuarios o las transacciones se incrementan.
Aplicaciones en el Cloud: escalado vertical vs horizontal
Cuando tenemos una aplicación corriendo en un servidor y la demanda de peticiones se incrementa corremos el riesgo de que el servidor no pueda atender y servir correctamente todas esas peticiones. En este punto tenemos un problema y dos opciones: escalado vertical vs horizontal.
1. Escalado Vertical
Es lo que se conoce como ‘hacer crecer el hardware’, ya que, permite aumentar las prestaciones del servidor, es decir, más memoria, más CPU, etc. Este tipo de escalado es el que se planteaba antiguamente cuando la demanda crecía lentamente y existía la posibilidad de hacer presupuestos a X años vista. Además, era posible contar siempre con capacidad sobrante en los servidores como previsión del posible crecimiento.
En la actualidad, los proyectos o servicios nuevos tienen una producción a corto plazo y es difícil realizar predicciones a más de un año vista, por ello, cuando se está buscando ajustar costes y no pagar más de lo estrictamente necesario, el escalado vertical deja de tener sentido e incluso se puede considerar una estrategia peligrosa. Las ampliaciones (o reducciones) de hardware, aunque sean de manera virtual implican tareas de mantenimiento y cortes de servicio.
Adicionalmente, un servidor no puede crecer indefinidamente en memoria, disco o cpu, puesto que, siempre hay un límite y muchas veces aparece en un momento poco oportuno.
Basta con mirar a nuestro alrededor: ninguno de los grandes servicios o portales que conocemos y que son ejemplo de crecimiento y escalabilidad (Google, Facebook, Twitter, Evernote, Whatsapp, Linkedin, etc ..) podrían ser servidos desde un único «gran «servidor, dicho de otra manera: ninguno de estos servicios habría sido posible utilizando el escalado vertical.
2. Escalado Horizontal sobre arquitecturas distribuidas
Una estrategia diferente, es la de distribuir la aplicación en diferentes componentes y aumentar el número de cada uno de ellos según convenga. Aquí, es donde encontramos la clave principal, y es que, en lugar de diseñar una aplicación de forma monolítica, la descomponemos en diferentes módulos y cada uno de ellos ejecuta una función concreta. Solo de esta manera conseguimos crecer allí donde es necesario en número de servidores (instancias o nodos), en vez de aumentar cpu o la memoria de un único gran nodo, como ocurre en el escalado vertical.
Si utilizamos el escalado horizontal, al tener más de una instancia (servidor) para cada servicio, lo que hacemos es balancear las peticiones entre los diferentes nodos que dan ese servicio pudiendo añadir más nodos según las necesidades y la carga global de peticiones. Este balanceo de peticiones nos ofrece una segunda ventaja: la alta disponibilidad del servicio.
Esto se traduce en la posibilidad de parar un nodo, ya sea porque tiene problemas o porque necesitamos realizar algún tipo de mantenimiento como actualizar el sistema operativo, con lo que redirigiremos las peticiones hacia los nodos restantes de forma que el usuario final no notará ninguna interrupción de servicio.
Adicionalmente, una arquitectura distribuida nos permite afrontar cambios en una parte de la aplicación sin afectar al resto facilitando el control de versiones y la gestión del cambio. Además, nos ayuda también a que cada parte de la aplicación funcione con el sistema operativo y versiones más adecuado, sin tener que asumir compromisos ni tener problemas de compatibilidad. Ahora bien, el escalado horizontal también nos plantea una serie de retos que debemos superar para poder disfrutar de sus ventajas, para ello, será necesario seguir un conjunto de buenas prácticas que veremos más adelante.
Ejemplos de escalados
Un ejemplo de arquitectura monolítica y que debe crecer mediante escalado vertical es un Servidor Web con una aplicación (PHP, Java, ASP, etc.) y una Base de Datos (MySQL, SQL Server, etc.), todo ejecutándose en un mismo servidor.
Cuando el número de visitantes o el número de peticiones simultáneas en la base de datos hace que nuestro servidor llegue al máximo de memoria o CPU éste dejará de responder y lo único que podremos hacer es parar el equipo, añadir más memoria RAM o CPU y volver a encenderlo esperando que, los nuevos recursos adicionales sean suficientes para asumir la carga. Si pasado un tiempo baja la actividad y vemos que ya no necesitamos aquellos recursos extra y queremos dejar de pagarlos, lo que tendremos que hacer es similar: parar el equipo (un nuevo corte de servicio), sacar memoria ram y / o cpu y volver a poner en marcha, y así sucesivamente.
Todo ello con el inconveniente añadido de que un problema de recursos con el servicio web puede dejar sin memoria el servicio de base de datos y viceversa, dificultando aún más las previsiones y la gestión de la carga en momentos críticos. Está claro que esto no es un buen ejemplo de escalabilidad.
En cuanto pensamos en arquitecturas web distribuidas probablemente la primera idea que nos viene a la mente es separar la base de datos del servicio web. De esta manera cada función es ejecutada en un servidor diferente, cada uno puede tener los recursos y versiones del sistema operativo que más se adecuen a la función a realizar, y si es necesario podemos añadir más nodos de cada tipo para dividir la carga y aumentar la capacidad.
Será necesario que nuestra aplicación tenga en cuenta la existencia de los nodos adicionales, y aquí aparece uno de los primeros retos. Para ello, nos pueden ser de ayuda elementos como los balanceadores de peticiones web. En otros casos, el propio código de la aplicación decide enviar datos o peticiones a diferentes nodos por ejemplo cuando tenemos más de una base de datos donde guardamos diferentes tipos de información.
De todas formas una arquitectura escalable al cloud va mucho más allá de eso, y para conseguir sistemas realmente autoescalables y elásticos basados en plataformas cloud deberemos incorporar un conjunto de metodologías y tecnologías adicionales.
