Desde hace unos cuantos años, bastantes años, que en el mundo informático, de una u otra manera se habla de virtualziación. Si lo pensamos desde el lado más puro, hasta el sistema operativo es una virtualización de las capas de hardware contenidas en niveles inferiores. Y en un sentido más genérico, o en un sentido más enduser, virtualziación para muchos de nosotros significó poder tener máquinas virtuales con diferentes sistemas operativos corriendo en la misma compu, al mismo tiempo, compartiendo los mismo recursos, recalentando el procesador, hirviendo la ram en los calores de 1000 goblins adolescentes… Me fuí, vuelvo; para muchos era, por ejemplo, poder probar una nueva distro de Linux en un entorno controlado, o tener una versíon de Windows andando sobre una máquina virtual en un Debian, para poder así usar Office.
De estas ideas de virtualización nacen las ideas de los containers, y de Docker.
Hace cinco años, Solomon Hykes ayudó a fundar un negocio, Docker, que buscaba hacer containers fáciles de usar. Con el lanzamiento de Docker 1.0 en junio de 2014, el rumor se convirtió en un estruendo. Y, con el paso de los años, sólo se ha vuelto más fuerte.
Desde que Docker democratizó los containers de software hace cinco años, todo un ecosistema creció alrededor de la contenedorización y en este período de tiempo comprimido ha pasado por dos fases de crecimiento distintas. En cada una de estas dos fases, el modelo de producción de sistemas de containers evolucionó para adaptarse al tamaño y las necesidades de la comunidad de usuarios, así como al proyecto y al creciente ecosistema contribuyente.
Revisemos cómo llegamos a donde estamos hoy.
Los containers se remontan al menos al año 2000 y a las Cárceles de FreeBSD. Oracle Solaris también tiene un concepto similar llamado Zonas, mientras que empresas como Parallels, Google y Docker han estado trabajando en proyectos de código abierto como OpenVZ y LXC (Linux Containers) para que los containers funcionen correctamente y de forma segura.
De hecho, pocos de ustedes lo saben, pero la mayoría de ustedes han estado usando containers durante años. Google tiene su propia tecnología de código abierto de containers lmctfy (Let Me Contain That For You). Cada vez que utilices alguna de las funciones de Google (búsqueda, Gmail, Google Docs, etc.), recibirás un nuevo contenedor.
Docker, sin embargo, está construido sobre LXC. Como con cualquier tecnología de contenedor, en lo que respecta al programa, tiene su propio sistema de archivos, almacenamiento, CPU, RAM, etc. La diferencia clave entre containers y VMs es que mientras el hipervisor abstrae un dispositivo completo, los containers abstrae el núcleo del sistema operativo.
Esto, a su vez, significa que una cosa que los hipervisores de VM pueden hacer que los containers no pueden es usar diferentes sistemas operativos o núcleos. Así, por ejemplo, puede utilizar Microsoft Azure para ejecutar ambas instancias de Windows Server 2012 y SUSE Linux Enterprise Server al mismo tiempo. Con Docker, todos los containers deben utilizar el mismo sistema operativo y el mismo núcleo.
Por otro lado, si lo único que desea hacer es conseguir que la mayoría de las instancias de aplicación del servidor se ejecuten en la menor cantidad de hardware, no le importará en absoluto la ejecución de múltiples VMs de sistemas operativos. Si lo que quieres son varias copias de la misma aplicación, te encantarán los containers.
Esta medida puede ahorrar a un centro de datos o proveedor de cloud computing decenas de millones de dólares anuales en costes de energía y hardware. No es de extrañar que se apresuren a adoptar a Docker tan rápido como sea posible.
En resumen, esto es lo que Docker puede hacer: Puede conseguir que más aplicaciones se ejecuten en el mismo hardware que otras tecnologías; facilita a los desarrolladores la creación rápida de aplicaciones contenidas listas para ejecutarse; y facilita mucho la gestión y el despliegue de aplicaciones. Si lo ponemos todo junto, puedo ver por qué Docker se montó en el ciclo de la publicidad tan rápido como recuerdo haber visto la tecnología de una empresa.
Además, por una vez la realidad está a la altura de las expectativas. Francamente, no puedo pensar en una sola compañía de cualquier tamaño que no esté al menos buscando mover sus aplicaciones de servidor a containers en general y a Docker en particular.
En 2013-2014 los pioneros comenzaron a utilizar containers y a colaborar en una base de código abierto monolítica, Docker y otros pocos proyectos, para ayudar a que las herramientas maduren.
Luego, en 2015-2016, los containers se adoptaron masivamente en la producción para aplicaciones nativas de la nube. En esta fase, la comunidad de usuarios creció para soportar decenas de miles de implementaciones que fueron respaldadas por cientos de proyectos de ecosistemas y miles de contribuyentes. Es durante esta fase que Docker desarrolló su modelo de producción hacia un enfoque basado en componentes abiertos. De esta manera, permitió aumentar tanto la superficie de innovación como la de colaboración.
Lo que surgió fueron nuevos proyectos de componentes Docker independientes que ayudaron a estimular el crecimiento del ecosistema de socios y de la comunidad de usuarios. Durante ese período, se innovó rápidamente en componentes de la base de código de Docker para que los fabricantes de sistemas pudieran reutilizarlos de forma independiente mientras construían sus propios sistemas de containers: runc, HyperKit, VPNKit, SwarmKit, InfraKit, containerd, etc…
Ya para 2017 los containers se convierten en una corriente dominante, extendiéndose a todas las categorías de computación, servidores, centros de datos, nubes, escritorios, IoT y móviles. Cada industria y mercado vertical, finanzas, salud, gobierno, viajes, manufactura. Y cada caso de uso, aplicaciones web modernas, aplicaciones de servidor tradicionales, aprendizaje de máquinas, sistemas de control industrial, robótica. Lo que muchos de los nuevos participantes en el ecosistema de containers tienen en común es que construyen sistemas especializados, dirigidos a una infraestructura, industria o caso de uso particular.
El Proyecto Moby es un proyecto relativamente nuevo de código abierto para avanzar en el movimiento de contenedorización de software y ayudar al ecosistema a integrar los containers. Proporciona una biblioteca de componentes, un marco para ensamblarlos en sistemas basados en containers personalizados y un lugar para que todos los entusiastas de los containers experimenten e intercambien ideas.
El Proyecto Moby:
El Proyecto Moby, es un nuevo proyecto de código abierto para avanzar en el movimiento de contenedorización de software. Ofrece un “Lego set” de docenas de componentes, un marco para montarlos en sistemas basados en containers personalizados y un lugar para que todos los entusiastas de los containers experimenten e intercambien ideas. Piense en Moby como el “Lego Club” de los sistemas de containers.
Moby se compone de:
Una biblioteca de componentes de backend en containers (por ejemplo, un constructor de bajo nivel, una instalación de registro, gestión de volúmenes, redes, gestión de imágenes, containerd, SwarmKit, ….).
Un marco para ensamblar los componentes en una plataforma de contenedor independiente, y herramientas para construir, probar y desplegar artefactos para estos ensamblajes.
Un conjunto de referencia, denominado Moby Origin, que es la base abierta para la plataforma de containers Docker, así como ejemplos de sistemas de containers que utilizan diversos componentes de la biblioteca Moby o de otros proyectos.
Moby está diseñado para constructores de sistemas, que quieren construir sus propios sistemas basados en containers, no para desarrolladores de aplicaciones, que pueden utilizar Docker u otras plataformas de containers. Los participantes en el proyecto Moby pueden elegir entre la biblioteca de componentes derivados de Docker o pueden elegir “traer sus propios componentes” (BYOC) empaquetados como containers con la opción de mezclar y combinar entre todos los componentes para crear un sistema de containers personalizado.
Docker utiliza el Proyecto Moby como un laboratorio abierto de I+D, para experimentar, desarrollar nuevos componentes y colaborar con el ecosistema en el futuro de la tecnología de containers. Toda nuestra colaboración en código abierto se trasladará al proyecto Moby. Docker es, y seguirá siendo, un producto de código abierto que le permite construir, enviar y ejecutar containers. Se mantiene exactamente igual desde la perspectiva del usuario. Los usuarios pueden seguir descargando Docker desde el sitio web docker.com. Vea más información sobre los papeles respectivos de Docker y Moby en el sitio web de Moby.
Docker busca con esto, que su tecnología sea la principal usada en todos los ámbitos de los que venimos hablando.
Para los clientes esto significa que los costos bajan.
