Si os movéis en el mundo de tecnologías relacionadas con IT y sobre todo en la parte de desarrollos, configuraciones de entornos y deployments de las aplicaciones podéis ver que el mundo se ha hecho muy heterogéneo últimamente. Ocurre igual que el ritmo en el mundo de la“informática”, que pasa cada vez más rápido. Muchos proveedores van sacando versiones nuevas de sus productos más a menudo. Por un lado esto trae muchas posibilidades nuevas pero también, por otro lado, puede complicar bastante la vida a los desarrolladores y a los departamentos de administración sistemas.
Esto pasa porque prácticamente cada release nuevo requiere ciertos requerimientos en el nivel de sistema operativo, Framework .NET, librerías o servicios de otros productos o/y proveedores. Muchas veces hay que mantener incluso varias versiones de ciertos productos y esto puede ser aún más complicado de conseguir, debido a conflictos entre versiones de librerías en una máquina o mejor dicho en una instancia del sistema operativo.
Desde hace muchos años podemos solucionar estos problemas en forma bastante eficiente usando virtualización en nivel de máquina. Hoy por hoy existen muchas herramientas, muchas de ellas además permiten uso de algunas o de todas sus funcionalidades en forma gratuita. Según las necesidades de cada uno tenemos que escoger uno o varios productos. Los más conocidos quizás sean VMWare con ESXi, vSphere, Workstation y otros productos relacionados, Microsoft con HYPER-V, Oracle con VirtualBox.
Y aunque hemos dicho que virtualización en nivel del sistema operativo permite cierta eficiencia en sentido de montar varios entornos de desarrollo o trabajo aislando todo en nivel de la máquina, en muchas situaciones esta eficiencia no llega a ser suficiente. ¿Qué quiere decir esto? Pues muchas veces necesitamos aislar solo ciertos servicios, y ocurre que montar una máquina para una serie de servicios ligeros tiene muchos impactos negativos. Unos de los más obvios son costes licencia (sistema operativo), uso inadecuado de recursos (como por ejemplo memoria RAM, HDD, CPU), tiempo necesario para instalar o provisionar la máquina etc. En este momento viene otra alternativa. Alternativa que se llama en general “contenedores”.
Aunque parece que contenedores es una tecnología nueva por el boom que se ve actualmente, en realidad no se trata de una novedad. La idea de contenedores existe desde hace muchos años en el mundo de los sistemas operativos Linux. Sin embargo el momento más importante vino en el año 2013 cuando
Solomon Hykes comenzó el proyecto Docker como una alternativa (o mejor dicho como una evolución) del sistema de contenedores que estaba disponible en aquel momento.
Este proyecto se convirtió rápidamente en un proyecto de código abierto y tuvo mucho éxito. Éxito que se pudo ver reflejado en el gran número de usuarios y contribuyentes. Probablemente el mayor contribuyente de todos es Red Hat. Aunque esta situación ha cambiado durante el último año con el interés de Microsoft en incorporar esta tecnología a Windows.
Microsoft ha hecho un trabajo enorme y muy importante durante el último año con la adopción de la tecnología contenedores en sus sistemas operativos propios. El primer sistema operativo que debería permitir uso contenedores Docker en forma nativa debería ser Windows Server 2016. Y es muy probable que luego venga el soporte para el sistema operativo tipo desktop (Windows 10 o sus sucesores). Ya están disponibles las “Technical Previews” y se pueden ir probando posibilidades de estas tecnologías directamente en Windows Server.
Las ventajas de virtualización mediante Docker las podemos mostrar en un ejemplo práctico. Hay que decir que actualmente esto no es posible pero suponemos que en futuro lo será. Por eso consideremos este ejemplo cercano a nuestro mundo Dynamics NAV como un ejemplo “virtual”.
Nosotros, como partner de Microsoft, necesitamos mantener varias versiones NAV para clientes actuales y también ir avanzando con las versiones nuevas. Para conseguir esto muchas veces necesitamos montar varias máquinas virtuales. O podemos instalar varias versiones (algunas con hotfixes) en una pero esto muchas veces tiene efectos no deseados.
Docker nos podría permitir solucionar este problema de una forma bastante eficiente. Desde el punto de vista de Docker cada entorno de un cliente podría ser como una serie de contenedores. Cada contenedor con un componente concreto. En nuestro caso sería un contenedor con SQL Server (además con la versión que usaría el cliente) + un contenedor con Dynamics NAV Server (otra vez una versión adecuada desde el punto de vista de nuestro cliente). Estos contenedores están vinculados por un fichero específico y permiten comunicación entre ellos mismos. Además se levantan por encima de la capa del sistema operativo y serán totalmente transparentes para el resto del sistema operativo. Esto es así porque los contenedores corren en un sandbox especial. La comunicación entre contenedores y el mundo que esté fuera de estos contenedores está basada en comunicación por uno o varios puertos o también por carpetas compartidas.
Levantar un contenedor es un proceso muy rápido, normalmente no tarda más que unos segundos, incluso en caso de la mayoría de contenedores los tiempos van sobre un segundo. ¿Queremos comparar estos tiempos con arranque de una máquina virtual? Es obvio que aquí ganará Docker.
Otra ventaja es que al levantar un contenedor no necesitamos instanciar una o varias CPU’s como en el caso de la máquina virtual. Además, y eso es aún más importante – no necesitamos instanciar ni memoria RAM en las cantidades de 4, 8 o más GB’s para dar apoyo al sistema operativo y luego para nuestros servicios. El sistema operativo ya tiene su memoria RAM asignada y nosotros podemos ir levantando contenedores dentro de esta máquina. Tenemos que tener en cuenta que aplicaciones con consumo de memoria RAM necesitarán la asignación de memoria también, por eso el sistema operativo debe estar bien dimensionado. Pero podemos olvidar los recursos necesarios para el sistema operativo.
Aquí quiero decir que las ventajas no terminan en el tema de ahorro recursos HW. Imaginemos que tenemos un cliente y estamos preparando una serie de desarrollos nuevos. Y queremos enseñarle lo que hemos hecho. Hoy hay que subir todas las partes, componentes etc. y hacerle una demo. Este proceso puede ser bastante complicado y muchas veces hay que repetir varios pasos por varios motivos. En caso de usar Docker podemos literalmente mover el contenedor del entorno desarrollo a casa cliente y enseñárselo en su entorno propio. Y realmente todo debería funcionar prácticamente igual como en el entorno de desarrollo.
Creo que es más que obvio que Docker permite ahorrar muchos costes relacionados con HW, con licencias por uso sistema operativo. También permite ahorrar los tiempos de provisionar e instalar máquinas. Da mucha flexibilidad porque dentro de una máquina permite levantar varios contenedores de varias versiones de varios productos sin afectar el resto del sistema operativo o contenedores de otros grupos. Permite agrupar varios contenedores.
Pienso que el mundo de Docker y todo lo que está llegando por fin a los sistemas operativos de Microsoft durante este último año nos permitirá replantear toda la infraestructura interna, relacionada con el tema de deployment de funcionalidades a clientes, mantenimiento de nuestros productos y mucho más. Creo que no estaría mal poner al final de este artículo una frase del Docker que refleja todo el objetivo de este producto o plataforma: Build, Ship, Run.
