data -->

Cloud Native Apps

Posted by José Manuel Hernández on


Hoy en día la transición al cloud sigue siendo pausada (en el mercado español), quizás por desconfianza o quizás porque aún los costes no son tan bajos como nos cuentan, aunque esto es discutible.

Veo que aún mucha gente del sector no tienen claro el paradigma del cloud computing, cuando hablamos de cloud hablamos de cualquier entorno informático donde el cómputo, redes y almacenamiento se puede aprovisionar y liberar elásticamente de manera automática o bajo demanda.

El mercado cambia de forma rápida y dinámica lo cual implica la necesidad de que nuestros sistemas respondan de un modo ágil y se adapten a esta necesidad, para ello es necesario un cambio cultural y un cambio en el modo de desarrollar nuestras aplicaciones. No vale con arrastrar las aplicaciones legacy al cloud tal cual ya que de ese modo perderemos toda la potencia que el cloud nos aporta como es la elasticidad y tolerancia a fallos.

Figura1. Comparativa Datacenter tradicional vs Datacenter Cloud native

A continuación detallo los puntos mas importantes que toda aplicación Cloud Native debería cumplir (según los twelve-factors de Heroku):

  • Repositorio de Código: Cada aplicación debe de guardarse en un software de control de versiones tal como Git, Mercurial o Subversion, esto nos permitirá llevar un control de cambios y hacer roll-back en caso necesario.
  • Dependencias: Las apps deben declarar y aislar sus dependencias con herramientas apropiadas (Maven, Bundler, NPM) en vez de tenerlas implícitas.
  • Configuración: La configuración o cualquier cosa que pueda diferir entre entornos (desarrollo, pre-producción, producción) debe de inyectarse a través de variables de entorno a nivel de sistema operativo.
  • Backing services: Son los servicios que cualquier aplicación necesita como parte de su funcionamiento tal como bases de datos, sistemas de mensajería/cola, servicio de SMTP, etc. El código de una aplicación “twelve-factor” no hace distinciones entre servicios locales y de terceros. Para la aplicación, ambos son recursos conectados, accedidos mediante una URL u otro modo. Un despliegue de una aplicación “twelve-factor” debería ser capaz de reemplazar una base de datos local MySQL por una gestionada por un tercero (como Amazon RDS) sin ningún cambio en el código de la aplicación.
  • Build, release, run: Separar completamente la etapa de construcción de la etapa de ejecución.
  • Procesos: Las aplicaciones deben de ejecutar uno o varios procesos stateless (sin estado) y no compartir nada. Todo dato persistente debe de alojarse en los servicios de backing (BBDD, caché, almacén de objetos, etc.)
  • Asignación de puertos: Las aplicaciones deben de publicar sus servicios mediante asignación de puertos,
  • Concurrencia: La concurrencia normalmente se logra escalando nuestros procesos o aplicaciones horizontalmente.
  • Disponibilidad: Maximizar la robustez, es necesario reducir al mínimo el tiempo de inicio de una aplicación, que los procesos se cierren siempre adecuadamente y que estos sean robustos antes apagados bruscos.
  • Paridad Dev/prod: Se deben de utilizar herramientas de integración continua (CI) para mantener los entornos de desarrollo, pre-producción y producción lo más similar posible.
  • Logs: La naturaleza de una aplicación cloud debe de ser stateless por lo que los logs deben de guardarse en un syslog central persistente que permita hacer búsquedas y analizar eventos.
  • Tareas de administración:
    Ejecutar las tareas de gestión/administración como procesos batch, análisis, etc. en un entorno idéntico a producción, de este modo evitaremos impactar en el entorno de producción y la operativa normal.

 

Ejemplo: Migración de una aplicación a modo Cloud Native (WordPress) sobre Openstack

A continuación en el siguiente ejemplo voy a mostrar como hacer una instalación de una herramienta que todos conocemos, WordPress, en modo cloud native, soportando alta disponibilidad y autoescalado. En este caso la aplicación se puede adaptar al modo de funcionamiento cloud pero es posible que otras aplicaciones no se puedan adaptar fácilmente y sea necesario que esta se desarrolle desde un principio “cloud native”.

Como hemos hablado antes, uno de los requisitos para construir aplicaciones Cloud Native es que estas sean stateless y no almacenen ningún dato en ellas salvo datos temporales.
En este caso WordPress almacena los datos en dos ubicaciones diferentes:

– MySQL: Se guardan los comentarios, artículos, usuarios y configuración de la aplicación.
Nuestro MySQL evidentemente no podrá ser stateless, por lo que dotaremos a las instancias MySQL de almacenamiento persistente usando un volumen de Cinder. Para dotar de alta disponibilidad este servicio usaremos MySQL Galera cluster separando los nodos en diferentes zonas de disponibilidad o regiones.
– File system: Se alojan los ficheros subidos por los autores de los posts, tales como imágenes, audios, videos, etc.
Para el File system tenemos un problema similar, es un servicio statefull (persistente) ya que tenemos que conservar los datos que residen en el, para solucionar este problema podemos usar un almacén de objetos, en el caso de Openstack usaremos Swift (similar a S3 de Amazon), con esto nos aseguramos que todas las instancias de aplicación WordPress tengan persistencia en sus archivos. WordPress dispone de un [plugin] para usar almacén de objetos y alojar en él lo ficheros persistentes que no se alojan en base de datos.

Autoscaling
Para gestionar el auto-escalado de nuestra aplicación lo más sencillo es usar Heat, este servicio de orquestación de Openstack, similar a Amazon CloudFormation, permite crear un guion de despliegue de todo el entorno mediante plantillas YAML.

El escalado horizontal se realizará creando nuevas instancias de WordPress cuando se superen los umbrales de CPU, memoria o tráfico especificados, distribuyendo la carga entre todos los servidores. Evidentemente para esta tarea hará falta un Balanceador de Carga, en este caso podremos usar Neutron LBaaS. Desde Heat se monitorizará el estado de las instancias mediante Ceilometer y cuando se supere o se baje de un umbral actuará automáticamente creando nuevas instancias y añadiéndolas al balanceador o inversamente en el caso de que la carga disminuya.

Con estos pasos conseguiremos un servidor WordPress stateless que nos permitirá construir un servicio WordPress tolerante a fallos y auto-escalable en función de la carga (CPU, memoria, etc) de nuestras instancias.



En resumen, si vas a pasarte al cloud diseña tus aplicaciones para funcionar correctamente en él y sacarle el máximo partido.

Hasta la próxima.
José Manuel Hernández

>Referencias:
Heroku