¿Puedo instalar Docker en el servidor?Así empezó todo. Con una llamada de un desarrollador preguntándome si podía instalar Docker en un servidor de test que le había aprovisionado unos días antes. Esa llamada fue el preludio de una reunión infraestructura-desarrollo en la que surgió el tema que nos ocupa: ¿máquinas virtuales o contenedores?
Conceptos
Antes de evaluar qué opción es mejor y por qué, hablemos brevemente sobre qué es una máquina virtual y qué es un contenedor, para entender así sus diferencias.
Una máquina virtual es una imagen de un sistema operativo que se ejecuta sobre otro sistema operativo, creando un sistema invitado (guest) totalmente aislado del sistema operativo huésped (host).
Tanto el sistema operativo host como los sistemas operativos guest (máquinas virtuales) usan los recursos físicos (RAM, CPU, disco...) del servidor físico donde se encuentran. La porción de esos recursos que puede usar cada máquina virtual se configura en el hipervisor.
Un contenedor, por su parte, es un paquete cerrado de software que incluye una aplicación y todas aquellas dependencias que la aplicación necesita para poder desempeñar su función.
Los contenedores, a diferencia de las máquinas virtuales, están diseñados para interactuar con el sistema operativo sobre el que se despliegan - por ejemplo, interactúan con el kernel de Linux - por lo que anteriormente, un contenedor de Linux solo se podía ejecutar sobre sistemas operativos Linux y un contenedor de Windows solo se podía ejecutar sobre sistemas operativos Windows. Sin embargo, desde el año pasado, Microsoft permite ejecutar contenedores de Linux sobre Windows, previo despliegue de un entorno Linux mínimo sobre la máquina Windows (más información y detalles del proceso aquí).
En resumen, una máquina virtual es un sistema operativo completo, aislado del sistema operativo huésped, y un contenedor es un paquete de código que interactúa con el sistema operativo huésped y que incluye todas las dependencias que necesita para ejecutarse correctamente.
Antigüedad
La principal reticencia a la hora de usar contenedores es la antigüedad de la tecnología. Su consolidación en la industria. Si tomamos como ejemplo las máquinas virtuales, nos encontramos con que los famosos ESX de VMware se lanzaron al mercado en 2001 mientras que Docker - uno de los nombres que más suena cuando se habla de contenedores - existe desde 2013. No obstante, no debemos olvidar que los contenedores como aislamiento de aplicaciones ya existían desde antes de la aparición de Docker. Concretamente, LXC (Linux Containers) se lanzó en 2008.
Si bien es cierto que la virtualización de VMware existe desde hace casi 20 años, la tecnología de contenedores tiene ya más de 10 años a sus espaldas. No estamos ante una moda surgida el año pasado. Los contenedores son una tecnología que llegó para quedarse, y compañías de la talla de VISA, Desigual o PayPal, las cuales usan Docker en producción en estos momentos, lo demuestran.
¿Máquinas virtuales o contenedores?
Ahora sí, con los conceptos ya claros, podemos hablar de qué es mejor. Y la respuesta es: depende. Depende de nuestras necesidades.
Si necesitamos servir una página web, la respuesta para mi es muy clara: contenedores.
Si necesitamos ejecutar un programa .exe en un Windows Server, necesitamos que otra aplicación se conecte a este servidor a recoger unos logs y necesitamos una tercera aplicación, que corre sobre otro sistema operativo, para que monitorice el espacio en disco de los sistemas operativos anteriores, yo me decantaría por usar tres máquinas virtuales distintas.
Bajo mi punto de vista, los contenedores nos pueden ser útiles para albergar aplicaciones que corren bajo una misma plataforma, como pueden ser aplicaciones web, ya que nos permiten reaprovechar código, nos facilitan una alta disponibilidad que nos sería más difícil de conseguir con máquinas virtuales, nos permiten autoescalado (si la demanda por el servicio sube y se requieren más recursos en un momento dado se pueden autodesplegar contenedores rápidamente) y nos aseguran que una aplicación funcionará en cualquier máquina, como ventajas principales.
Aplicaciones monolíticas vs microservicios
Si hablamos de aplicaciones web, debemos hablar de microservicios, aplicaciones monolíticas y la relación de ambos con las máquinas virtuales y los contenedores.
La primera vez que escuché la expresión "aplicaciones monolíticas" fue en SUSE Expert Days 2018 (llego tarde, lo se), donde SUSE explicó su apuesta por los contenedores como método preferente de despliegue de aplicaciones web, por encima de opciones de hipervisor en Linux como KVM o Xen.
En una máquina virtual típica, podemos tener corriendo una página web sobre, por ejemplo, Apache y MariaDB. Esto es un ejemplo de aplicación monolítica. Si usáramos microservicios, podríamos dividir el código de la web en mini aplicaciones independientes entre sí que fueran llamadas según fueran siendo requeridas por la aplicación web. Y es en estas mini aplicaciones o mejor dicho, micro servicios, donde entran en juego los contenedores, pues cada microservicio se ejecuta en un contenedor independiente que se levanta solo cuando es necesario, y por tanto, solo consume recursos cuando es necesario, además de poder ser usado por varias aplicaciones web sin tener que tener el mismo código repetido en todas las aplicaciones.
Retorno de la inversión
Tomemos como ejemplo los entornos de antaño, con una máquina física por servidor. Hoy en día sería inviable que una compañía tuviera 500 máquinas físicas funcionando en su datacenter. Sin embargo, fácilmente puede una compañía tener 500 máquinas virtuales corriendo.
¿Por qué?
Porque el coste de electricidad, componentes, mantenimiento, etc. se dispararía en el caso de tener tantas máquinas físicas, mientras que esas máquinas virtualizadas tienen un coste asumible.
¿Qué ocurriría si sustituyéramos algunas máquinas virtuales por contenedores?
Lo que ocurriría es que el coste económico se reduciría aún más, puesto que se evitaría tener que mantener levantada una máquina virtual por cada aplicación, es decir, se podrían juntar varias aplicaciones en un mismo servidor, sin prescindir del aislamiento entre ellas ni de su alta disponibilidad.
Pongamos un ejemplo. Un sistema Linux Enterprise cualquiera requiere unos 15 GB de disco y 8 GB de RAM de media para funcionar de forma óptima. Si tenemos, digamos, 100 máquinas virtuales, estamos destinando 800 GB de RAM y 1,5 TB de disco solo para mantener levantados los sistemas operativos. Si las aplicaciones que corren sobre esos sistemas se contenerizasen, podríamos evitar gastar gran parte de esos recursos, ya que se podrían ejecutar muchos contenedores sobre unos pocos sistemas operativos y se podrían ir levantando y terminando contenedores en ellos según se requiriese.
Este ahorro de recursos, es decir, de dinero, se puede notar en un entorno on-premise, pero es especialmente destacable en un entorno cloud público, donde se paga directamente por recurso asignado a una máquina. En un AWS Summit, Amazon habló de cómo el uso de contenedores en vez de instancias podía llegar a reducir las facturas de AWS a la mitad.
Conclusión
Si estamos sirviendo muchas páginas web que usan la misma tecnología (mismo CMS, mismo servidor web, mismo tipo de base de datos, etc.), lo más recomendable sería ejecutar esas páginas en contendores. Así, se aprovecharían mejor los recursos de hardware y se facilitaría el ciclo de puesta en producción de las aplicaciones, ya que el código que corre en un contenedor en el PC del desarrollador funcionará igual en su PC que en el servidor de producción, entre otras ventajas.
Si, por el contrario, tenemos un entorno heterogéneo, con muchos sistemas operativos distintos y necesidades muy variadas, lo mejor, bajo mi punto de vista, es mantenerlo en máquinas virtuales separadas. Y, en todo caso, contenerizar aquellas aplicaciones que sea posible ejecutar desde contenedores, para aprovechar sus ventajas.