adam121 - Fotolia
¿Cuál es el futuro del despliegue de contenedores?
El despliegue de contenedores continúa evolucionando con la ayuda de modelos VM, microservicios y DevOps. Aprenda cómo la arquitectura de contenedores puede afectar sus objetivos de negocio.
Los contenedores no son un concepto nuevo; los primeros pasos hacia los contenedores Linux fueron tomados en 1979. Desde entonces, ha habido alrededor de una docena de nuevos pasos evolutivos en el despliegue de aplicaciones de contenedores, y aún no hemos terminado. Los contenedores también están interactuando con tecnologías de apoyo, como DevOps, y las que compiten, como las máquinas virtuales (VM), para crear una presión evolutiva sobre todas las tecnologías involucradas. El contenedor del futuro será muy diferente al de hoy, pero todavía es posible para los usuarios seguir las tendencias y aprovechar al máximo cada paso en el camino.
Todas las arquitecturas de contenedores se diferencian de las arquitecturas de VM porque están diseñadas para virtualizar el hardware y al menos el software básico de plataforma, no solo el hardware. Esto significa que las aplicaciones de contenedor comparten el sistema operativo y algunos elementos de middleware, mientras que los modelos de VM requieren que todo el software se duplique para cada VM. El enfoque de contenedor reduce la sobrecarga, permitiendo que más aplicaciones se ejecuten por servidor.
Empezando con la implementación del contenedor
El despliegue temprano del contenedor supuso que los usuarios y las aplicaciones se comportaban bien y no requerían protección mutua o seguridad. Esto permitió errores o malicia para crear problemas de estabilidad y seguridad. Por lo tanto, en la primera década de la evolución del contenedor, el foco se centró en mejorar el aislamiento de los contenedores. Esto comenzó con varios conceptos de "cárcel" que se enfocaron principalmente en aislar los sistemas de archivos de los contenedores y evolucionaron a la marca Solaris Containers, que aprovechó una función mejorada del sistema operativo Solaris llamada Zones para aislar aún más los contenedores.
Google introdujo varias arquitecturas de contenedores a partir de 2006, y éstas tenían la capacidad de particionar y asignar recursos de hardware, almacenamiento y red a los contenedores, proporcionando a los usuarios un mayor control sobre la forma en que los contenedores podrían influir no solo en la seguridad, sino en el desempelo de otros que comparten el mismo servidor. Estas mejoras fueron introducidas gradualmente en el propio Linux, y eso impulsó la evolución de los contenedores modernos.
El proyecto de contenedores Linux LXC y el trabajo LMCTFY de Google, que lanzó la orquestación de Kubernetes, saltaron en este punto (a principios de esta década) y fueron estas iniciativas las que culminaron en Docker. Docker fue diseñado para tomar el marco técnico de contenedores (aislamiento y control de recursos) y operacionalizarlo. Kubernetes y Docker, el estándar de la orquestación y el estándar de la arquitectura para los contenedores, se están fusionando cada vez más, así que es mejor pensar en ellos como un solo acercamiento. La combinación es el líder de facto en el mercado de la contenerización hoy (rkt de CoreOS es una variante Docker), pero no el final de la evolución. Dos nuevos caminos se han abierto para los contenedores, y éstos construirán el camino al futuro.
Despliegue de contenedores y nube
El primero de ellos es la explosión de los servicios de contenedores de nube pública. Google, Amazon y Microsoft ofrecen servicios de contenedores que facilitan la extensión de uso de contenedores privados en la nube, la mayoría de las veces para aplicaciones de nube híbridas. Kubernetes se está convirtiendo en un estándar de facto para la orquestación de estas aplicaciones, aunque otros modelos de orquestación de contenedores también están disponibles. Desde el enfoque de orquestación de servicios de contenedores basados en la nube, parece claro que el enfoque de la evolución de la arquitectura de contenedores es cada vez más la gestión del ciclo de vida de las aplicaciones, el lado operativo del despliegue de contenedores.
La segunda vía es una especie de convergencia con VMs. Todos los proveedores tradicionales de VM, tanto de nube pública como de software privado, tienen cierto respaldo para contenedores. El enfoque de la mayoría es permitir la implementación de máquinas virtuales que, a su vez, se convierten en hosts de contenedores y el soporte para un modelo de administración unificada de contenedores y máquinas virtuales en un entorno de este tipo. Eso creó un enfoque de tecnología, de nuevo en DevOps o en la orquestación, y detrás de eso en la gestión del ciclo de vida de la aplicación en general. Dado que este enfoque en el ciclo de vida de la aplicación es común de nuestro camino de servicio de contenedores públicos hacia el futuro, parece claro que el futuro de las arquitecturas de contenedores se desarrollará mediante un mayor soporte para la operacionalización de la implementación, ampliación y redistribución de aplicaciones, y la organización de recursos y componentes de aplicaciones en un solo conjunto de recursos.
El contenedor del futuro será muy diferente al de hoy.
Este único objetivo evolutivo no quita la confusión de la evolución de las arquitecturas de contenedores, particularmente a corto plazo. Hoy en día, hay dos comunidades distintas de usuarios que conducen los contenedores: aquellos que están desarrollando aplicaciones específicamente para entornos de despliegue de contenedores, y están buscando maneras de mejorar las aplicaciones a través de características de contenedor adicionales; y aquellos que buscan implementar software en componentes de terceros o software desarrollado internamente en contenedores para mejorar el rendimiento operacional y la disponibilidad. Cada una de estas comunidades está impulsando un futuro diferente para el software de contenedores.
Arquitectura de contenedores y DevOps
El grupo centrado en el desarrollo se está enfocando en hacer que los contenedores hagan lo que un sistema independiente y el software de plataforma harían, convertir los contenedores en una réplica fiel de un servidor dedicado a nivel de programación. Aquí es donde funcionan cosas como el manejo de bases de datos, las conexiones entre procesos en el nivel lógico (lenguaje de programación) y la integración de middleware. Un comité de defensores de contenedores de este grupo parece tener una mentalidad de "arreglarlo"; han aceptado los contenedores, y solo quieren que funcionen.
El grupo de operacionalización se centra en facilitar la implementación y la gestión operativa del ciclo de vida de las aplicaciones. Este grupo está realmente mirando más allá de lo que un contenedor hace a lo que un sistema de contenedores podría necesitar y hacer. Orquestación o DevOps ha sido el enfoque principal aquí, y el trabajo con la operacionalización de la aplicación ha demostrado ahora que muchas de las metas del grupo centrado en el desarrollo también se pueden satisfacer utilizando herramientas operativas. Eso es bueno porque significaría que los caminos evolutivos de los contenedores están convergiendo.
A largo plazo, es la operacionalización la que moverá las arquitecturas de contenedores hacia el futuro. Contenedores, microservicios, computación en la nube y otras tendencias modernas se combinan entre sí y con los objetivos de negocio para crear políticas de TI. Esa política, aunque priorice estos elementos técnicos, se mantendrá o disminuirá en función de la eficiencia operacional, por lo que, con el tiempo, las tendencias de contenedores se convertirán en un punto focal para las tendencias operacionales de las aplicaciones. Planee para eso ahora, y estará por delante del juego.
