Las nuevas aplicaciones – 12 factores

4 septiembre, 2015 — Deja un comentario

Uno de los cambios que están transformando el mundo de IT, es la nueva forma de desarrollar algunas aplicaciones. Lo que algunos han dado en llamar las “aplicaciones nativas en la nube”, aqui podéis leer una gran explicación del gurú de mi empresa Chad Sakad @sakacc (presidente de preventa mundial de EMC).

Para comprender qué diferencia este tipo de aplicaciones, la mejor explicación está en http://12factor.net/ y a continuación una breve y traducida versión de esas características:

  1. Código Base: debe existir un único código controlado con un sistema de versionado de código como puede ser GitHub, y que se despliega varias veces. En algunos casos extremos de las grandes de compañias de IT hay ejemplos de sistemas que se despliegan cientos o miles de veces al día. Con esto se logra que todo el equipo de desarrollo y sistemas trabajen siempre sobre el mismo código evitando potenciales problemas de falta de sincronización entre equipos
  2. Dependencias: Las dependencias de paquetes de código deben ser declaradas explícitamente y aisladas. De este modo se simplifica la configuración de nuevos desarrolladores sobre el código a trabajar, y de paso se verifica constantemente que paquetes deben estar desplegados en los entornos de ejecución.
  3. Configuración: cada conjunto de ficheros que afectan a la configuración de un entorno deben estar gestionados por el entorno. Esto facilita su control y la expansión de las aplicaciones entre diferentes entornos cuando se escala horizontalmente (scale-out).
  4. Servicios de backend: trabajar con cualquier tipo de servicio de backend con independencia de su localización. Con independencia de si un servicio accedido por la aplicación es una base de datos local o un API distribuida en una nube pública, la aplicación debe diseñarse para trabajar sin ningún cambio con diferentes recursos. Un buen ejemplo surge en la web oficial: si una base de datos local falla, la aplicación podría balancearse para trabajar con otra en una nube pública, modificando ficheros de configuración, pero sin tocar nada de la aplicación, aumentando de forma radical la resilencia, que ya no radica en el entorno (HW sobre el que funciona la mencionada base de datos) sino sobre la flexibilidad de la aplicación.
  5. Construye – Distribuye – Ejecuta: las buenas prácticas de los “12 factores” fuerzan a que se separen las 3 etapas de construcción del código (cuando se compila una versión concreta del código versionado con sus dependencias), la distribución (cuando se combina una construcción concreta con las variables de una configuración determinada de entorno) y la ejecución de todo lo anterior, de modo que jamás se podría modificar el código una vez pasada la fase de construcción. Así la seguridad del funcionamiento del código en ejecución nunca dependerá de cambios en la construcción, a no ser que se genere un nuevo ciclo completo, nunca más tener cambios en producción que nadie sabe quien escribió…
  6. Procesos: la aplicación construida siguiendo los 12 factores se ejecutará desde un proceso sin estado y que con comparte recursos con ningún elemento externo, ya sea un proceso manual en un portátil de trabajo o un conjunto de servidores, así se garantiza que ningún proceso externo pueda afectar a la ejecución de una aplicación, de modo que se comporte de forma diferente de una ejecución a otra. Si se requiere del almacenamiento de cachés temporales, se puede trabajar con sistemas software de almacenamiento temporal que harán de servicio de backend.
  7. Enlazar puertos: una aplicación correctamente desarrollada siguiendo los 12 factores está auto-contenida, y por lo tanto no debería emplear ningún tipo de contenedor como puede ser un servidor web o equivalente. Para paliar esta dependencia se debería ligar la aplicación con un puerto e importar las librerías existentes para ejecutar desde la aplicación las funcionalidades del contenedor desechado. Y si se da servicio a otras aplicaciones, estás deberían referenciar a la ligada al puerto de escucha como un servicio externo (siguiendo los factores 2 y 3).
  8. Concurrencia: dado el factor 6 y la arquitectura de procesos aislados y sin compartición de recursos, en caso de necesitar escalar aplicaciones, el modelo de scale-out es el adecuado, generando más procesos de los necesarios en cada momento.
  9. Desechabilidad (si es que existe esa palabra): ligado a todo lo anterior, los procesos deben poder crearse y destruidos en poco tiempo y de forma transparente, ya sea ante la finalización de la tarea o por un fallo en el sistema. Es de nuevo la aplicación quien debe garantizar el funcionamiento de si mismo, y no la infraestructura subyacente.
  10. Paridad entre desarrollo y producción: si vamos a realizar un modelo de despliegue continuo en el que varias veces a la semana, o al día, o a la hora modificamos código y lo desplegamos, está claro que los diferentes entornos de trabajo deben ser lo más parecidos posibles, para evitar el efecto maravilloso de que algo funcione en test o pre-producción y no funcione para nuestros clientes en el entorno final. Dado que se funciona en un modelo de procesos aislados autocontenidos, existen diferentes soluciones que nos permiten “igualar” nuestros entornos de trabajo, empezando por la palabra de moda de los “contenedores”.
  11. Logs: los logs, como elementos vitales para el seguimiento del funcionamiento de una aplicación, deben ser tratados como flujos de eventos que dependiendo del entorno y fase de trabajo se tratarán de diferentes modos. Puede que los veamos por un monitor en un entorno local, o que los tratemos como fuentes de datos para nuestro Data Lake de Big Data en entornos productivos de los que queramos aprender.
  12. Procesos administrativos: cualquier tarea de gestión y administración de la aplicación (aplicar un parche, migrar datos, etc) debe ser tratado como un proceso de ejecución más, manteniendo la misma regulación de versiones, configuraciones etc. Al final no deja de ser una práctica básica de la filosofía de DEVOPS.

 

Y si has llegado hasta aqui, la amenaza de que profundizaremos en alguno de los conceptos lanzados en medio de esta parrafada 🙂

No hay comentarios

¡Se el primero en comenzar la conversación!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s