Hace ya un año que escribía sobre contenedores en este mismo blog, ese post los titulé como Containers: «Ready or not here we go». En este post, analizaba como me había sorprendido no encontrar una alta adopción de proyectos basados en contenedores, en los clientes con los que trataba en ese momento.

Sin embargo, la foto actual un año después es muy distinta, podría decir que la mayoría por no decir todos mis clientes, se están pensando o tienen previsto trabajar en el corto plazo con esta tecnología.

Es sorprendente ver como la forma en la que esperabas que sucediesen las cosas no ocurren, cuando escuché hablar de los contenedores, cuando el fenómeno de la virtualización empezó a crecer allá por los comienzos de este milenio. Era sorprendente ver cómo los fabricantes a favor de la Full Virtualization, menospreciaban por completo las capacidades y el vuelco que podía dar a la industria una virtualización basada en la paravirtualización.

Pros and cons de ambas tecnologías

La virtualización completa, o virtualización mediante hipervisor, permite que una delgada capa de software sea la encargada de emular y enmascarar los recursos presentados al sistema operativo. Permitiendo fraccionar y orquestar el acceso de múltiples sistemas operativos al hardware que subyace por debajo. Este tipo de hipervisores pensados para el entorno de data center son conocidos como hipervisores de tipo 1.

Mientras que los contendores, u originalmente conocido como paravirtualización, básicamente lo que permite es, que compartiendo el kernel del sistema operativo subyacente, por encima del mismo se creen dominios donde se despliegue una aplicación especifica. En el caso de los contenedores, hay una pequeña capa de software conocida como motor que permite la gestión en el acceso a los recursos de la capa superior, donde básicamente los recursos encapsulados en este dominio son:

• La aplicación
• Dependencias
• Librerías
• Binarios
• Ficheros de configuración

Docker como sinónimo de contenedor

A día de hoy, el uso extendido de Docker como herramienta para la creación de los contenedores, hace que la mayoría de nosotros asimilemos el termino contendores a Docker, pero no es así hay otra serie de herramientas comerciales como son LXC, LXD, Solaris Zones, RKT o BSD Jails, que nos permiten crear contenedores desde cero al igual que Docker. Igualmente, para los entornos Windows, Microsoft dispone de herramientas como Windows Server Containers and Hiper-V Containers.

En resumen, a las máquinas virtuales se les entrega a través del hipervisor un recurso hardware virtualizado, mientras a los contenedores se les entrega un sistema operativo virtualizado.

El detalle de cómo y cuáles son las capas involucradas en cada aproximación, se pueden ver con mayor detalle en la siguiente figura.

Ventajas y desventajas de los hipervidores:

• Ventajas
  • Gestiona mejor las aplicaciones legacy, crea una foto de los recursos desplegados en el hardware original y los enmacara para la máquina virtual
  • Permite convivencia de diferentes sistemas operativos en el mismo hardware
  • Mayor aislamiento de la VM (virtual machine) a nivel del kernel del SO
• Desventajas
  • Gran consumidor de recursos
  • El tamaño de la máquina virtual suele ser u fichero de configuración de tamaños de GB

Ventajas y desventajas de los contenedores:

• Ventajas
  • Optimiza los recursos hardware de manera muy eficiente
  • Fichero de configuraciones muy ligeros entorno a MB, permite crear, copiar y matar de forma muy eficiente
  • Mejor velocidad de respuesta ante picos de carga de trabajo en la clonación de recursos
  • Mejora el ciclo de vida de los despliegues de aplicaciones
  • Las pruebas y depuración de errores es mucho más sencilla, ya que el contenedor es el mismo en desarrollo que en producción, haciendo realidad la frase más popular entre los desarrolladores, “en mí máquina funciona”.
• Desventajas
  • Todos los contenedores hacen uso del mismo SO, tipo y versión
  • Mayor riesgo de disponibilidad por ataques de kernel, todos los contenedores comparten el mismo
  • Mayor complejidad en la gestión y uso de la red

Cuándo y cómo comenzar a trabajar con contenedores

Como comentaba anteriormente, parecía que la siguiente ola en cuanto a la evolución de la eficiencia de los data centers serían los contenedores, mejor uso de los recursos y mayor eficiencia en relación a los ratios de consolidación.

Pero no fue así, como hemos visto la gestión en cuanto a la complejidad de la red y la imposibilidad de corres más de un sistema operativo por host, hizo que su adopción se estancase en el data center.

Aplicaciones born in the cloud

No así en los proyectos born in the cloud, aquí su adopción ha sido mucho mayor, relacionada con la creación de aplicaciones cien por cien cloud native. Este tipo de aplicaciones, concebidas desde el minuto uno como microservicios que ejecutan localmente una lógica de negocio muy reducida y la aplicación global, se encarga de orquestar las llamadas a cada uno de los mismos, ha hecho que la nube sea el lugar predilecto para correr ese tipo de cargas de trabajo.

La siguiente ola esta siendo la de aquellos que disponen de aplicaciones propias y están en la búsqueda de eficiencias y mejoras en las mismas, por el hecho de avanzar en un enfoque a microservicios y la búsqueda del stateless infinito.

Qué tener en cuenta antes de empezar a trabajar con contenedores

Para ellos, y si te encuentras en este punto, te traigo de nuevo un recetario de como empezar a trabajar con este tipo de tecnología y arquitecuras:

1. Gestión del cambio y análisis de habilidades, revisa las competencias del equipo y el resto de las áreas involucradas en el proyecto, para que todo el mundo sea consciente que se puede hacer y qué no, así como alguna de las funcionalidades y riesgos, que se perderán u encontrareis por el camino.
2. Despliegue como código de la infraestructura: Las implementaciones de contenedores requieren automatización y administración a través de interfaces de línea común (CLI) o interfaz de programación de aplicaciones (API).
3. Fijación de objetivos multinivel: Para medir con éxito el valor comercial de los contenedores, que solamente es una pieza tecnología adicional, las organizaciones deben establecer objetivos realistas.
4. Seleccionar aplicaciones candidatas: Este paso final consiste en seleccionar cuidadosamente qué aplicaciones son candidatas para el proceso de refactorización o decidir si frente a un nuevo proyecto se debe implementar una nueva aplicación en contenedores o en otro tipo de infraestructura.