Hace poco, estábamos trabajando con una iglesia en una nueva página web y nos encontramos con una situación que distaba mucho de ser óptima. Su infraestructura se había configurado inicialmente de tal forma que su servidor web de desarrollo se encontraba en la misma
máquina virtual que su instancia de Rock en producción. Queríamos dedicar un momento a explicar por qué esto no es una buena idea, por si alguien más se planteara seguir el mismo patrón.
Las razones por las que conviene separar los entornos de desarrollo y de producción se pueden clasificar en dos categorías: los recursos compartidos y las configuraciones complejas. Veamos cada una de ellas con detalle.
Recursos compartidos
La principal preocupación a la hora de ejecutar tanto el entorno de producción como el de desarrollo en un único servidor gira en torno a los recursos del servidor. Los entornos de desarrollo se crean porque se quiere realizar
en ellos tareas que no se querrían llevar a cabo en el entorno de producción. Por su parte, los entornos de producción son fundamentales para las operaciones diarias de tu organización. Estas dos funciones son, en esencia, incompatibles.
Durante un proyecto web, incluimos un paso para evaluar si el entorno actual tiene capacidad suficiente para soportar la carga del nuevo sitio web. Dado que su socio actual no
mantiene un mapa de arquitectura para la iglesia, no había indicios de que se estuviera aplicando esta mala práctica.
Sí que nos llegaron a comentar que existían algunas preocupaciones en relación con el rendimiento del registro de asistentes durante los fines de semana.
Ten en cuenta este último punto: hay problemas de escalabilidad relacionados con el rendimiento del check-in. La evaluación del estado actual y de las posibles soluciones se complica mucho más al saber
que una máquina virtual está desempeñando dos funciones. Si vuelves a consultar los registros de rendimiento de Azure y observas el uso de la CPU y la memoria durante los periodos de registro, no hay forma de saber si la carga procedía de la
instancia de IIS de producción o de la de desarrollo. Quizás alguien estaba utilizando o probando algo en la máquina de desarrollo al mismo tiempo.
Configuración compleja
Por si los recursos compartidos no fueran motivo suficiente para considerar que se trata de una mala idea, también hay que tener en cuenta la configuración necesaria para ejecutar dos instancias de Rock en la misma máquina virtual. Esto se reduce principalmente
a los enlaces de IIS necesarios para separar el tráfico que llega a una dirección IP, pero que es atendido por dos o más instancias de IIS. En esta configuración, cada nombre de host debe
tener dos enlaces (uno para HTTP y otro para HTTPS).
Con una instalación normal de IIS, todo el tráfico se envía a una única instancia de IIS. Esto facilita la incorporación de nuevos nombres de host (por ejemplo, para un nuevo micrositio que acabes de añadir). Solo tienes que ajustar tu DNS
y ya puedes estar seguro de que Rock recibirá ese tráfico. Cuando ejecutes varias instancias, también tendrás que añadir dos nuevas reglas de enlace a la instancia de producción de IIS.
Aunque estos ajustes no son nada del otro mundo, tampoco son algo que uno espere encontrar y suponen otro punto de fallo.
Conclusión
Separar los entornos de producción y desarrollo es fundamental para garantizar un entorno Rock estable y predecible. Esto es especialmente cierto si se tiene en cuenta que una máquina virtual de Azure con capacidad de ampliación
capaz de ejecutar un entorno de desarrollo puede conseguirse por unos 30 dólares al mes.
En Triumph siempre nos apasiona hacer las cosas teniendo en cuenta las mejores prácticas. También nos apasiona igualmente compartir estas mejores prácticas con la comunidad del rock para
contribuir a su formación y ayudarles, como forma de devolverles lo que nos han dado.