La tecnología de contenedores que encontramos ya tan presente en el diseño de arquitecturas de sistemas se podría definir como una de esas tecnologías disruptivas que cada cierto tiempo llegan para revolucionar el sector. Impulsando una serie de cambios más allá de los puramente tecnológicos con un acelerado ritmo de adopción consecuencia de un gran “hype”.
¿Es una tecnología tan innovadora? Bajo mi personal punto de vista, no son una tecnología innovadora, pues si nos remontamos a su origen, por la empresa que introdujo el concepto de contenedores tal y como lo trabajamos ahora Docker Inc. Vemos que se nutren de herramientas disponibles durante años en el Kernel de Linux donde no es nuevo el concepto de crear silos de ejecución para procesos dentro de un Sistema Operativo. Esto no quiere decir que no sea meritorio, pues la grandeza surgió en el concepto, en como ordenar con sentido todas estas “piezas” simplificando, facilitando y de alguna manera estandarizando su uso.
Si tan sencillo era el concepto, ¿por qué no se introdujo mucho antes? Docker entra a escena, justo cuando surge su necesidad, el nacimiento de una tecnología antes de su necesidad es una condena para su evolución. Con la explosión de desarrollos de software que estamos viviendo en los últimos años, donde el número de desarrollos crecen a un ritmo vertiginoso, con un abanico tecnológico cada vez más amplio y el concepto de “agilismo” arraigado no sólo en las metodologías de desarrollo sino también a nivel gestión, ayudando a las empresas a sobrevivir a las necesidades tan cambiantes en un mercado muy dinámico. Es en este momento cuando aparece la necesidad de una tecnología como la de contenedores como palanca clave en esta nueva realidad.
Y ahora sí, ¿qué son los contenedores?
Un contenedor, podría verse como un sistema de paquetización de aplicaciones mediante una virtualización ligera. Consiste en la creación de un entorno de ejecución corriendo sobre un Sistema Operativo ofreciendo una completa portabilidad e inmutabilidad del entorno. Al tratarse de un entorno de ejecución “genérico” podemos emplear estos contenedores para casi cualquier tipo de proceso con su entorno de ejecución y dependencias perfectamente dispuesto, en un concepto mucho más amplio de lo que sería, por ejemplo, un Runtime Environment de Java.
Idealmente en cada contenedor tendremos sólo un proceso en ejecución, pero podemos emplear tantos contendores como necesitemos interoperando entre sí y con el exterior, en un ecosistema completamente modular, permitiendo la creación de sistemas complejos, escalables y completamente portables.
Pongamos un caso de uso típico, para entenderlo mejor. Supongamos que tenemos una aplicación que se compone de los siguientes componentes:
- Servidor Web
- Runtime de PHP
- Servidor de BBDD
Tradicionalmente, para crear un entorno de ejecución de la aplicación usaríamos dos servidores, uno para la ejecución del servicio web y otro para la BBDD. Este enfoque tiene las siguientes implicaciones:
- Tendremos dos servidores para administrar, con sus mantenimientos, actualizaciones, revisiones…
- El despliegue es lento, por muchos sistemas de automatización que tengamos, preparar un servidor actualizado con el aplicativo y su entorno necesario es lento.
- Duplicar el sistema, para disponer de una copia exacta a nivel de servicios y configuración sobre la que realizar tareas de desarrollo, testing… es costoso y lento.
Ahora cambiemos el enfoque hacia una infraestructura desplegada mediante el uso de contenedores, donde dispondremos tres, uno para cada proceso o servicio:
- Los contenedores son un entorno mínimo y comparten elementos del host anfitrión (como el Kernel), con lo que no tienen mantenimiento, sólo nos tendremos que preocupar por mantener correctamente el servicio que ejecutan.
- Una vez hemos definido como tiene que construirse cada contenedor, instanciarlos es rápido y sencillo.
- Duplicar el entorno tantas veces como necesitemos es trivial y podemos hacerlo localmente en los equipos de los desarrolladores hasta los servidores de producción/dev/testing, de manera exactamente igual.
- Permite automatización al tratarse de una infraestructura definida por software, integrándose perfectamente en escenarios de CI/CD, creando y destruyendo entornos para las distintas fases del ciclo.
- Nos permiten un prototipado rápido de aplicaciones y tecnologías, pudiendo probarlas de forma sencilla y rápida, sin la sobrecarga añadida de tener que desplegar servidores y lidiar con configuraciones.
Como vemos, las bondades del sistema son importantes, no obstante, en tecnología nada es “gratis” toda capa que pongamos tiene un coste el cual debe estudiarse según proyecto y cargas de trabajo. Valorando, por ejemplo, si la complejidad extra añadida compensa las mejoras que los contenedores aportan a nuestro proyecto, ya que hay entornos que bien por sencillos, monolíticos, tecnologías aún experimentales a nivel de contendedores… no compensan ni aportan -hoy en día- este cambio de infraestructura. También tendremos que soportar la sobrecarga computacional que, aunque no muy alta existe usando contenedores y en entornos de alto rendimiento no puede despreciarse, haciendo que algunas cargas de trabajo pueden tener sentido desplegarlas en contenedores para un entorno de prototipado/dev/testing pero no para entornos productivos, como podrían ser repositorios de información tipo BBDD.
Por último, mi visión personal de los contenedores.
Son una tecnología innegablemente útil, sobre la que ya podríamos decir que estamos en su versión 2.0 que serían los sistemas que nacieron como orquestación de estos pero que han evolucionado en una tecnología con entidad propia, con Kubernetes como punta de lanza. Sin embargo, como con todas las tecnologías, hay que aplicar el sentido común, que nos permite analizar sus pros y sus contras, ser buenos conocedores de nuestra infraestructura y capacidades para determinar si realmente tenemos la necesidad y si estamos en el momento de emplearla. Sin este sentido común, cualquier tecnología puede resultar contraproducente.
Jerónimo Asensio
Chief Cloud Architect
