Son de sobra conocidas las ventajas de la virtualización en los entornos de producción: mayor flexibilidad en los despliegues, costes de actuación y mantenimiento reducidos, e incluso un menor gasto energético. Pero pocas veces he visto aplicar la virtualización en el entorno de desarrollo y me surge la pregunta ¿No podemos aprovecharnos de sus ventajas?
Virtualización ELI5
La virtualización permite tener en un equipo físico (en un ordenador) varios sistemas operativos instalados a la vez, funcionando como el resto de programas. Cada una de estas máquinas se conocen como máquinas virtuales. El sistema de virtualización permite cambiar de una máquina virtual a otra como si cambiásemos entre dos aplicaciones. Por ejemplo, podemos tener en nuestra máquina de escritorio Windows 10 otras dos, un Windows 7, y un Ubuntu Linux, cada una con sus propias aplicaciones instaladas.
Esto es posible gracias a servicios como VirtualBox, VMWare, Qemu, entre otros muchos.
La idea que propongo en este post, es usar una máquina virtual distinta e independiente para cada proyecto. Veamos los pros y contras de esta forma de trabajar.
Ventajas
Una de las (muchas ) cosas buenas de trabajar en Future Space es que cada proyecto es diferente al anterior. A menudo cada uno tiene su propio entorno, herramientas y tecnologías, lo que supone un medio ideal para aplicar esta forma de trabajar.
Un entorno limpio para cada desarrollo
A medida que se trabaja para distintos proyectos, tu equipo se va llenando de librerías, aplicaciones y servicios: clientes de git y svn, de base de datos, servidores, etcétera.
Inevitablemente llega un punto de que el sistema se degrada y se hace necesaria una reinstalación del sistema operativo. No sólo eso: también pueden producirse conflictos entre diferentes servicios, o diferentes versiones del mismo servicio.
Instalando el entorno para un proyecto en una máquina virtual, lo aislamos, mantenemos así la máquina física limpia de todo este software.
Entorno de desarrollo similar al de producción
En realidad, los entornos pueden ser idénticos: mismas versiones de sistema operativo, librerías y servicios. Incluso podremos simular el número de procesadores y la memoria disponible en las máquinas de producción (hasta donde nos permita la máquina física).
- El paso a producción es menos traumático: estamos usando las mismas versiones instaladas igual, incluso en el mismo sistema operativo.
- Los problemas en el despliegue e integración del sistema los encontraremos antes en nuestra máquina de desarrollo.
- Es mas fácil replicar los errores que se producen en el sistema en explotación en nuestro entorno de desarrollo.
Incluso, si el entorno final se compone de varias máquinas (front-end y back-end, por ejemplo) podemos replicarlas como máquinas virtuales en nuestra máquina de desarrollo, conectadas a través de una red también virtual.
Máquinas de usar y tirar
¿Necesitas probar si tu aplicación funciona sobre MongoDB y sobre CouchDB? ¿Si tu página web se visualiza correctamente en Internet Explorer 8, y 9, y 10 y en Firefox 47? ¿Es mejor Mantis, Redmine, o YouTrack para el control de incidencias? O incluso: ¿Funcionará tu servio en Red Hat Linux, en Windows, y en Solaris?
No es necesario instalar y configurar todo ese software para probar tus aplicaciones, al menos no con la virtualización. En Internet hay varios repositorios de appilances (literalmente, electrodomésticos) que son máquinas virtuales ya instaladas y configuradas con un software concreto. Descargar y arrancar.
- Microsoft nos ofrece las distintas versiones de su navegador en máquinas virtuales.
- TurnKey Linux nos permite descargar más de cien máquinas virtuales preinstaladas con los productos mas usados del sector.
- Bitnami nos brinda la misma posiblidad, además de instaladores de aplicaciones propios, mas fáciles de usar.
Este post no estaría completo sin mencionar Docker Hub, donde podemos obtener appilances similares para Docker. El uso de contenedores como alternativa a las máquinas virtuales es algo que veremos en un futuro post en este blog.
Guardando la partida
En todos los desarrollos hay pruebas complejas. Más que complejas… farragosas: Abres la aplicación web, introduces unos datos, se ejecuta un proceso y se genera un resultado. Si durante esta prueba, en cualquiera de sus pasos, existe un fallo, cada prueba que ejecutes supondrá volver a repetir el proceso. Una y otra vez.
Puedes guardar el estado de una máquina virtual, realizando una foto (se conoce como snapshot) de su estado en un determinado instante. Tras realizar cualquier operación, podrás restaurar el estado anterior, como si nunca hubiera pasado; los procesos, la memoria, el contenido del disco, vuelven a ser los mismos de la foto. Si guardas el estado de la base de datos justo después de cargar los datos, y antes de ejecutar la prueba, podrás reproducir el problema una y otra vez, sin tener que volver a introducir los datos en la web.
Menos espectacular es el hecho de que con los snapshots, cuando llegues al trabajo cada mañana, podrás retomar el trabajo en el punto donde lo dejaste, con todos los servicios arrancados sin necesidad de dejar el equipo encendido toda la noche.
Máquinas en el congelador
Una vez terminado el desarrollo de un proyecto, queda en un cajón de nuestro disco duro. Pasado un mes, desinstalamos el servidor web porque está consumiendo recursos para nada, y pasados dos meses usamos sus datos para otro proyecto, y los dejamos irreconocibles.
¿Y si al tercer mes, el cliente original nos dice que le falla la aplicación?
Podríamos hacer un esfuerzo por respetar el entorno de un proyecto, sobre todo si está en mantenimiento, pero es cuestión de tiempo que necesitemos el único puerto 80 de nuestra máquina, o el espacio que nos ocupan los ficheros de pruebas.
Si el entorno de un proyecto, junto con todos sus recursos y documentación se encuentra aislado en una (o varias) máquinas virtuales, basta con guardar una copia de respaldo cuando se finaliza un desarrollo y ya podemos liberar el espacio en nuestro disco. Cuando la volvamos a necesitar podemos restaurar y arrancar esa máquina virtual, y tener el entorno operativo tal y como lo dejamos.
Compartir máquinas virtuales
Llega un nuevo integrante al equipo de desarrollo y en vez de alegrarnos por la ayuda, pensamos en el tiempo que vamos a perder. Vamos a tener no sólo que ponerle al día en qué es el proyecto, como funciona, cómo desarrollamos, sino que vamos a tener que instalarle el entorno de desarrollo, su propia base de datos para pruebas, los ficheros de datos, el servidor web… Los técnicos somos así.
Desarrollando sobre máquinas virtuales, bastaría con que le clonáramos nuestra máquina virtual de desarrollo, la de base de datos, etc., para que el nuevo esté operativo en cuestión de horas, en lugar de en días.
Pruebas destructivas
Recuerdo que en un proyecto, hace años, el cliente nos pidió un “botón del pánico” en una aplicación. Este botón borraba por completo la base de datos del sistema, incluso físicamente. Si no hubiese tenido la base de datos virtualizada, hubiera tenido que reinstalar el servidor con cada prueba de esta funcionalidad.
También podemos realizar pruebas menos radicales: En un entorno virtualizado es más fácil realizar pruebas de desconexión de red, de falta de espacio en disco, de ejecución con recursos hardware limitados.
Inconvenientes
Desafortunadamente, pocas cosas en este negocio son gratis, y el uso de máquinas virtuales para el desarrollo tiene alguna contrapartida.
Conocimiento de las herramientas de virtualización
Para montar y configurar estos entornos, naturalmente, es necesario conocer las herramientas de virtualización. Esto puede complicarse ya que, aunque las herramientas en sí son bastante sencillas, replicar un entorno complejo es… bueno, complejo.
Mayor requerimiento de hardware
El rendimiento de una máquina virtual es, por lógica, peor que el que ofrecería instalada directamente en el equipo físico. Realmente no es mucho peor, pero si que es algo apreciable. Sobre todo lo que requiere esta forma de trabajar es una buena cantidad de memoria RAM en nuestro equipo, especialmente si vamos a tener varias máquinas virtuales arrancadas de forma simultánea.
Espacio en disco desaprovechado
Uno de los mayores problemas en el uso de máquinas virtuales es que se desaprovecha mucho espacio en disco. Una máquina virtual (al igual que una máquina física) suele requerir (como mínimo) unos 20 o 30 GB de espacio en disco, en algunos casos más. Y mucho más aún si usamos los snapshots. Este espacio, esté o no ocupado en la máquina virtual, es el que ocupan los ficheros de la máquina virtual en el disco de la máquina física.
Hoy en día, el espacio en disco es barato, pero esto no deja de ser un inconveniente: Se desperdicia también espacio en las copias de respaldo de las máquinas virtuales, y el movimiento de máquinas virtuales entre máquinas físicas es mucho mas lento, al tener que transferir ficheros mas grandes.
Una mejora en el entorno de trabajo
A mi modo de ver, las ventajas de trabajar sobre máquinas virtuales en proyectos de desarrollo compensan de largo sus desventajas, si nuestro trabajo es mantener durante años el mismo servicio… quizá no. Pero si necesitamos trabajar en proyectos distintos, incluso simultáneamente, tener entornos aislados en máquinas virtuales distintas es una forma eficiente de enfrentar los proyectos de desarrollo.
