Autor: M. en C. Alejandro Cruz Rojas Sígueme en LinkedIn
Introducción
Este artículo es la segunda parte del artículo “Diseño de Software as a Service: Los 12 factores” que abordó el origen y metas generales de este grupo de principios y posteriormente describió en mayor detalle, los factores 1 y 2. Puede acceder al documento descrito en alguno de los siguientes enlaces:
- Diseño de Software as a Service: Los 12 factores
- Diseño de Software as a Service: Los 12 factores (linkedin)
¿De qué habla el factor 3?
El factor 3 propone que la configuración (a nivel aplicación) resida en cada ambiente.
Podemos considerar que la configuración a nivel aplicación:
- Es todo aquello que probablemente varíe entre ambientes (desarrollo, pruebas, producción, etc.)
- Incluye (entre otros):
- referencias a recursos físicos como base de datos y directorios del sistema operativo
- credenciales
- direcciones de red de servicios subordinados o colaboradores (APIs, servicios de infraestructura, servicios de terceros)
- No incluye la configuración interna de la aplicación, dado que este tipo de configuración no varía entre ambientes. (Por ejemplo, la interconexión entre los módulos de código, o determinadas preferencias o parámetros de operación de la aplicación).
Ahora bien, podemos plantearnos algunas preguntas:
- ¿Qué alternativas tenemos para manejar la configuración?
- ¿A qué se refiere exactamente el factor 3 con eso de que la configuración debe residir en cada ambiente?
- ¿Cuál es el beneficio?
- ¿Cómo se puede implementar?
¿Cual es el reto de la configuración?
El primer aspecto relevante es que los recursos a los que se conecta una aplicación, como son las bases de datos o las URLs para interactuar con servicios propios o de terceros (entre otros), son distintos en cada ambiente. Por ejemplo:
- En el ambiente local de desarrollo, cada desarrollador puede crear su propia base de datos local y acceder a ella con credenciales simplificadas.
- En un ambiente de QA (o pruebas) se utiliza una base de datos configurada específicamente para ejecutar pruebas y representar escenarios de ejecución específicos.
- En el ambiente productivo se utiliza una base de datos con datos reales y con infraestructura de protección adecuada (autenticación profesional, encriptado, etc.).
El segundo aspecto que vale la pena analizar, es que cada vez más, se busca que el paso de los empacados (dlls, jars, wars, etc.) entre los ambientes, sea automatizado. Hay una creciente tendencia a implementar procesos de integración o entrega continua. Un mal manejo de la configuración dificulta seriamente cualquier iniciativa en dirección de la automatización de esos flujos.
Un tercer aspecto que deberíamos considerar son los errores involuntarios. Supongamos que un empacado pasa de un ambiente a otro apuntando a recursos equivocados y ese hecho no es detectado oportunamente. Es probable que se convierta en una fuente de inconsistencias y de errores difíciles de detectar.
Opciones de Manejo de la Configuración
Podemos implementar distintas estrategias de manejo de configuración:
- Usar código alambrado
- Usar archivos de configuración
- Usar archivos de configuración que incluyan perfilamiento de ambiente
- Usar configuración alimentada por variables de ambiente
1. Código Alambrado
Consiste en codificar las direcciones de los recursos directamente en el código. Es la vía más simple de implementar, pero tiene serias desventajas y también es la estrategia más riesgosa:
- El código y la configuración están revueltos: Hay que revisar el código y ubicar en dónde están las referencias a los recursos cada vez que cambia de ambiente.
- Es muy insegura: Las Urls de los recursos son visibles para cualquiera que tenga acceso al código. Si contamos con un repositorio de código compartido, todos los que tengan acceso tendrán datos para acceder a recursos que debieran ser secretos.
- El paso entre ambientes se complica: Cada paso entre ambientes implicará modificar referencias directamente en el código, su compilación y empacado. La probabilidad de introducir errores se aumenta significativamente. El proceso es difícil de automatizar.
2. Uso de Archivos de configuración
Podemos usar archivos de propiedades o archivos específicos propuestos por los frameworks que se utilicen en el proceso de desarrollo. La mayoría de frameworks utiliza un gestor de empacados (cómo Maven, npm, nuget, etc.) que usa un archivo específico para almacenar la configuración en un formato abierto como xml, json, yaml, etc.
Esta estrategia es mucho mejor que la anterior:
- El código y la configuración quedan perfectamente separados. Cuando se deba cambiar la referencia a algún recurso, será simple saber dónde hacerlo y no se correrá el riesgo de modificar accidentalmente el código de la aplicación.
- El paso entre ambientes se hace más simple. Cada ambiente puede tener su versión propia de los archivos de configuración, con las referencias a los recursos que ese ambiente requiere. La otra alternativa es modificar la configuración al pasar de un ambiente a otro.
- Mayor seguridad. Las referencias a los recursos de cada ambiente solamente son conocidas por quienes están autorizados a administrar tal ambiente.
3. Uso de archivos de configuración que incluyen perfiles
Esta estrategia es una variante de la anterior. La mayoría de frameworks de desarrollo y de empacado soportan la inclusión de grupos de propiedades asociadas a un perfil. Podemos tener, por ejemplo, los perfiles “desarrollo”, “pruebas”, ”QA” y “producción” y crear secciones dedicadas a cada uno de esos perfiles en la configuración, en las que se declaren las configuraciones específicas a usar con cada perfil. Por ejemplo, la url de la base de datos principal existiría en cada una de las secciones declaradas, aunque con valores distintos en cada caso.
Esta estrategia tiene las siguientes características:
- Mayor facilidad para mover empacados entre ambientes: Al pasar un empacado de una ambiente a otro se debe configurar cual es el perfil activo para que el empacado tome los valores correctos.
- Seguridad relativa: Todos los involucrados que tengan acceso a la configuración podrán ver las referencias a todos los ambientes.
- La aplicación queda acoplada a todos los ambientes: La configuración contiene todas las referencias necesarias de cada ambiente, por lo que el ciclo de vida de cada ambiente quedará asociado al ciclo de vida de la configuración.
4. Uso de configuración alimentada con variables del sistema
En esta estrategia podemos crear un proceso (o usar un framework) que al arrancar la aplicación tome los valores de variables del sistema específicas, para alimentar los valores de las referencias a los recursos usados por la aplicación.
Esta estrategia es la propuesta por el factor 3. Tiene las características que siguen:
- Fácilmente automatizable: Un proceso sistematizado de integración (o entrega) continua puede ejecutar el empacado mediante un archivo de comandos (como un Shell de Linux/Unix o un Powershell de Windows), que inicialice las variables de ambiente necesarias. Este archivo de comandos será la configuración de facto del ambiente. Residirá en él y solo será conocido por sus administradores.
- Desacopla la aplicación de los ambientes: El código no conoce las referencias a los recursos físicos usados por cada ambiente. No requiere enterarse de los cambios que haya en ellos por lo que es más simple de migrar entre ambientes y plataformas.
- Es un mecanismo seguro: Nadie tiene conocimiento accidental de las direcciones y credenciales de los recursos que usa una aplicación en cada ambiente.
Flujo de trabajo de integración con una configuración tipo factor 3
La siguiente figura muestra como sería un flujo de trabajo simplificado que aproveche una aplicación que toma los valores de su configuración de las variables de ambiente.
Conclusión
La estrategia de hacer que la aplicación tome los valores de su configuración de las variables de ambiente es una inversión que reditúa ampliamente. Además, vale la pena considerar que muchos de los frameworks de desarrollo modernos ya cuentan con recursos para facilitar esta tarea. (Una opción destacada en la plataforma Java, es Spring Framework).
Puedes echar un vistazo a nuestro diplomado sobre este framework:
Diplomado de Spring Boot y Spring Framework (DPSPR01)
Por ahora, hemos comentado ampliamente el factor 3. Continuaremos con los otros factores en entregas futuras… No te las pierdas 🙂