De un tiempo a esta parte puedo estimar con escaso margen de error la calidad de un equipo de desarrollo por el grado de innovación en sus herramientas de despliegue de entregables. Algunos dicen que el nuevo documento de Google sobre Borg es el sucesor de aquellos ya clásicos sobre BigTable y MapReduce.
Hace no mucho desarrollábamos y ejecutábamos en El Servidor o, como mucho, en La Granja de Servidores (que eran de dos a diez). Las aplicaciones corrían sobre un servidor web, una base de datos, algún bus de integración y poco más. Pero ahora no es para nada raro que incluso una PyME tenga una decena de instancias de máquinas virtuales alojadas en algún proveedor. Y para las empresas medianas y grandes podemos estar hablando de centenares o miles de máquinas virtuales. Además, la infraestructura software se ha vuelto más compleja, almacenes atributo-valor para las imágenes, caches, soporte de sistemas de ficheros distribuidos, colas, servidores LDAP, … Replicar el entorno de producción con fines de desarrollo/testeo es un verdadero desafío, cuando no imposible, debido a la dependencia de servicios web de terceros.
El desafío de la distribución de aplicaciones no es nuevo. La primera versión de Microsoft Systems Management Server data de 1994. Aunque entonces se trataba de instalar y mantener actualizado Office en los PCs de los usuarios, más que de distribuir aplicaciones en los servidores.
Ya he escrito anteriormente que, en mi opinión, el lenguaje de programación no importa demasiado. Existen ejemplos de sitios web muy exitosos desarrollados en PHP/Zend, Python/Django, Ruby/RoR, Java/JSP o incluso C#/ASP.NET como Stackoverflow. Comunmente se cita que Facebook está desarrollado en PHP, pero para poder ejecutarlo eficientemente en las decenas de miles de servidores que necesitan tuvieron que desarrollar su propio compilador de PHP sobre la máquina virtual HHVM y una variante de PHP con tipado estático llamada Hack. La aplicación de Facebook se compila a un único binario «ballena» que se distribuye vía BitTorrent a los servidores.
Docker, Borg y Mesos son un intento de estandarizar una solución a este problema de la distribución masiva de aplicaciones en una granja con mayor número de servidores de lo que razonablemente se pudiere gestionar manualmente o con algunos simples scripts.
Previamente disponíamos de Vagrant y Puppet. Ambas fantásticas herramientas para la definición y creación de máquinas virtuales sobre VMWare o VirtualBox. La única pega de estás herramientas es que están orientadas a crear máquinas virtuales enteras. Se pueden definer variantes de la misma máquina virtual base, pero no son herramientas orientadas a la distribución de aplicaciones de software a través de un conjunto de máquinas virtuales que ya existen.
Docker
Docker es un software libre que pretende facilitar que la distribución y ejecución de aplicaciones en un conjunto de servidores se asemeje al transporte de contenedores marítimos estandarizados.
Docker fué liberado en marzo de 2013, pero creo que la primera versión relevante fue la que se liberó un año después. La diferencia es que la versión de 2014 explota la nueva funcionaldidad LXC incluída en el kernel de Linux 2.6.24 que permite aislar completamente procesos dentro de la misma máquina virtuales, dotándoles de su propia memoria, CPU, punto de montaje en disco, recursos de red, etc. Los contenedores de Docker no necesitan de un hipervisor, por consiguiente, se pueden empaquetar más eficientemente dentro de un host físico que usando una máquina virtual por cada aplicación.
Los contenedores se almacenan en repositorios de los cuales pueden ser descargados por los servidores de la granja. También es posible crear grupos de contenedores para gestionar dependencias.
Daniel J Walsh cuestiona la seguridad de los contenedores en su artículo Bringing new security features to Docker, señalando que algunos subsitemas del kernel como SELinux, /sys , /proc/sys, etc. y dispositivos /dev/mem , /dev/sd* pueden ser potencialmente vulnerables a ataques maliciosos de código en los contenedores. Tampoco es posible por ahora firmar el contenido de los contenedores y certificar su origen.
Borg
El documento publicado en abril describe la tecnología que Google lleva utilizando para gestionar sus datacenters desde hace más de una década. Es posible que la tecnología sea ya incluso obsoleta, al menos para Google donde están trabajando en la nueva versión de Borg bautizada como Omega.
Borg no usa máquinas virtuales, en teoría para mejorar la eficiencia, pero es posible también debido a que cuando empezaron a usarlo la tecnología de virtualización no estuviese aún suficientemente madura.
Los servidores de Borg se agrupan en celdas, una celda típica contiene alrededor de 10.000 servidores. Las celdas, a su vez se agrupan en clusters. Cada cluster está contenido dentro de un único datacenter y contiene usualmente una celda principal y varias celdas auxiliares más pequeñas.
Cada celda ejecuta una actividad (job) que se compone de tareas (tasks). Cada tarea es un único ejecutable con linkado estático. En cada máquina existe un alloc para cada tarea que puede ejecutar, el alloc describe las cuotas de recursos computacionales de la máquina que la tarea puede ejecutar.
En cada máquina se ejecuta de forma permanente un borglet encargado de gestionar la tareas y en cada celda se ejecutan varios borgmasters que gestionan las actividades mediante un sistema de colas. Los datos para cada tarea se almacenan por quintuplicado y se gestionan mediante un sistema Paxos.
En Borg, las actividades se dividen en dos grupos: baja latencia y procesos por lotes. Las actividades de baja latencia (como el email) reciben el 70% de los recursos mientras que aquellas que pueden tardar un tiempo arbitráriamente largo en responder reciben el 30%.
Mesos
A falta de una versión liberada de Borg, es posible utilizar Mesos el cual incluye soporte para contenedores Docker. Se puede concebir Mesos como un kernel distribuido accesible via APIs en C++, JVM, Python, y Go. La arquitectura de Mesos es similar a la de Borg. En cada máquina hay un slave daemon equivalente a un borglet y en cada cluster hay un master daemon que se corresponde con el borgmaster. Y también hay actividades (llamadas frameworks en Mesos) que están compuestas por tareas basadas en los ejecutores de Hadoop. No voy a entrar en los detalles técnicos sobre cómo Mesos hace asignación de recursos de grano fino descritos hace ya casi un lustro, simplemente reseñaré que la estrategia de asignación de recursos a las actividades influye considerablemente en el rendimiento y los interbloqueos de tareas concurrentes.
Proyectos como Spark, Storm, o Jenkins son ejemplos de aplicaciones muy diversas que pueden beneficiarse del uso de Mesos.
En combinación con Mesos es posible utilizar Marathon o Kubernetes. En muchos aspectos Mesos y Kubernetes se solapan funcionalmente en su intento de proporcionar al desarrollador un cluster de máquinas Linux que se comportan como un único sistema. Pero el acercamiento es sutilmente diferente. Kubernetes proporciona la abstracción pod (una agrupación de contenedores Docker), así cómo etiquetado de los pods para descubrimiento dinámico de servicios, balanceo de carga, y control de replicación. Mesos proporciona asignación fina de recursos para los pods a través de los nodos del cluster. En Kubernetes viene con un scheduler predeterminado mientras que en Mesos es preciso usar alguno como Yarn.
Beneficios de las nuevas tecnologías
• Utilización más eficiente de los recursos.
• Menores tiempos de latencia.
• Menor cap-ex del equipamiento.
• Menos licencias (VMs).
• Despligue más rápido y fácil de servicios a gran escala.
• Clusters de uso combinado para testeo y producción.
Post relacionado: Cosas que necesitas saber sobre el despliegue en La Nube.
Artículo relacionado: A Beginner-Friendly Introduction to Containers, VMs and Docker (Preethi Kasireddy).