Anatomía de un entorno

Normalmente cuando se habla del proceso de contrucción de software se hace de principio a fin, pero esta vez quiero hacerlo al revés: Empezar por el final y así tener en mente desde el primer momento qué queremos construir para, más adelante, ver cómo lo construimos.

Podemos asumir que, en última instancia, lo que estamos haciendo es montar y gestionar un entorno (en concreto el entorno de producción). Aunque para llegar a ello necesitamos montar algún entorno más. Al menos, un entorno de desarrollo nos vendría bien… Así que de esto hablaré en este artículo: ¿qué es un entorno y cómo se define?

Tipos de entorno

En desarrollo web en general trabajamos con, al menos, dos entornos: producción y desarrollo. Muchos también tenemos un tercer entorno generalmente llamado staging. Pero también podemos tener preproducción, testing, demo…

En definitiva, en un proyecto podemos tener potencialmente (casi) infinitos entornos diferentes. Y cada uno de ellos debería tener una única función. Por ejemplo:

• Desarrollo: permitir a los desarrolladores realizar su trabajo de forma cómoda y rápida
• Producción: entregar valor al usuario final
• Staging: permitir al Product Owner (o a cualquier otro rol) validar funcionalidades pendientes de subir

Qué define a un entorno

¿Qué diferencia a un entorno de otro?

Yo suelo definir los entornos como una serie de servicios interconectados entre sí, con una configuración, una infraestructura y unos datos determinados.

Así pues, tenemos los siguientes componentes básicos de un entorno: servicios, configuractión, infraestructura y datos.

Servicios

Son las piezas de software (propio o de terceros) que necesitamos para que el sistema haga lo que tiene que hacer.

Por ejemplo, para una aplicación frontend con su respectiva API podemos encontrar los siguientes servicios:

• API
• Nginx
• PostgreSQL
• Redis
• Aplicación front

Normalmente, al menos uno de estos servicios será un servicio que tendremos que construir nosotros (por ejemplo, el API y la aplicación front).

Configuración

Cada uno de estos servicios puede (o no) estar configurado de diferentes formas. Por ejemplo:

• Para levantar el API necesitaremos configurar un puerto donde escuchar
• La base de datos necesitará un usuario y una contraseña
• Necesitaremos configurar Redis

Secretos

Me parece importante señalar que hay un subtipo de configuración: los secretos.

Esta diferencia es importante porque los secretos se tienen que gestionar de forma diferente: no deberían versionarse nunca y, a ser posible, deberían cambiarse muy frecuentemente. Además, deberíamos restringir el número de personas con acceso a dichos valores, porque recuerda: si un secreto lo conoce mucha gente deja de ser un secreto y se convierte en un cotilleo.

El resto de parámetros deberíamos gestionarlos igual que el resto de nuestro código: versionándolos.

Infraestructura

Todos estos servicios tienen que ejecutarse en algún lado. Da igual que sea en máquinas físicas, en máquinas virtuales o en un dispositivo móvil. En este nivel es donde nos preocupamos sobre la cantidad de disco disponible, la memoria RAM o la CPU que queremos utilizar.

Datos

Por último tenemos los datos. A mí me gusta clasificar los datos de un entorno en función de su necesidad de persistencia.

Esto es relevante porque los datos que necesitan persistir suelen tener mucho mayor tamaño y esto complica su operabilidad. Pensemos, por ejemplo, en el coste de mover código de un servidor de amazon a uno de google, frente al coste de mover datos de un proveedor a otro. Como le escuché una vez a Juan Tomás (desconozco si la cita es original){: .external-link target=”_blank”}, “no hay que menospreciar el ancho de banda de una furgoneta cargada con discos duros”.

Datos persistentes

Son aquellos datos que:

• no nos podemos permitir perder
• no podemos versionar de ninguna forma.

En general, la mayoría de los datos que son generados por los usuarios pertenecen a esta clase

Datos sin persistencia

Son aquellos datos que:

• puedo versionar y/o regenerar automáticamente (datos de prueba para demo, fixtures para tests, tablas maestras…)
• que no me importa perder (los datos de un wizard sencillo, por ejemplo)

Conclusiones

Los entornos tienen cuatro componentes principales: servicios, configuración, infraestructura y datos.

Hay un tipo especial de parámetros de configuración que requiere una gestión diferente, que son los secretos.

Los datos se pueden clasificar según su necesidad de persistencia:

• Un dato es persistente si no puedo permitirme perderlo y no lo puedo versionar
• Un dato no lo considero persistente si puedo perderlo o lo puedo versionar

Con estos conceptos, hemos definido los componentes principales con los que podemos crear entornos. En siguientes artículos, veremos principios de diseño que nos permitan administrar muchos entornos de forma flexible y razonablemente sencilla.