Usted construyó una nube privada a un gran costo y, a pesar del costo inicial, se están logrando ahorros reales. Y a pesar de que pensabas que la nube era justo lo que querían tus equipos de desarrollo, ahora claman por contenedores. Por qué?
Al igual que la mayoría de las empresas, probablemente justificó la inversión en su nube desde una perspectiva de Infraestructura con énfasis en aumentar la utilización del hardware físico. La utilización promedio antes de la virtualización a menudo era inferior al 10%, y la virtualización como habilitadora de la consolidación de la carga de trabajo ha sido una herramienta crítica para garantizar que el dinero gastado en hardware no se desperdicie.
Pero, y es un gran pero, las nubes privadas empresariales típicas ofrecen poco más que ahorros de costos y entrega acelerada (virtual) de máquinas a los equipos de desarrollo que las consumen. Estos son ciertamente valiosos, pero están bastante por debajo de la promesa completa de la nube.
Lo que los equipos de desarrollo realmente buscan es una plataforma con API que puedan usar para conectar directamente sus herramientas automatizadas de ciclo de vida de software. Para citar un líder de desarrollo: "Simplemente no quiero hablar con Infraestructura".
Sin embargo, lo que la infraestructura generalmente les brindaba era tan limitado como el viejo mundo físico: con procesos pesados, automatización limitada del ciclo de vida, los mismos viejos problemas con parches y absolutamente ninguna integración de herramientas.
En resumen, los servidores ahora eran virtuales, pero la mayoría de los viejos problemas para los desarrolladores aún existían, y las funciones de infraestructura continuaron caracterizándose como un bloqueador en lugar de un facilitador del cambio en el mundo del desarrollo.
Ingrese contenedores.
¿Qué son y por qué los usan los desarrolladores??
Para citar Wikipedia, un contenedor es "cualquier dispositivo ... que pueda usarse para contener, almacenar y transportar objetos o materiales."Si bien esto se aplica tanto a las cestas de mimbre como a los contenedores de software, la clave para TI es cómo los contenedores difieren de los servidores virtuales.
Los contenedores permiten a los equipos de desarrollo empaquetar su software, junto con dependencias de software resueltas, en un solo artefacto. Los contenedores requieren un sistema operativo host para ejecutarse, pero se pueden ejecutar varios contenedores en una sola instancia del sistema operativo mientras se mantiene el aislamiento lógico entre sí (ya no se necesita una licencia de sistema operativo por instancia de componente de aplicación para obtener ese aislamiento).
Como los contenedores no necesitan su propio sistema operativo, se pueden iniciar tan rápido como se puede iniciar el software de la aplicación envuelta (sin esperar a que se inicie una instancia del sistema operativo) y, al incluir dependencias de software resueltas, la creación de instancias en un servidor es simplemente una cuestión de copiar el contenedor y ponerlo en marcha. La repetibilidad y la abstracción proporcionadas por los contenedores permiten a los desarrolladores concentrarse en entregar software fácilmente implementable y funcional, mientras que otra persona proporciona una plataforma administrada para que esos contenedores se ejecuten.
El concepto de contenedores no es nuevo. Google ha estado utilizando su propia variedad durante años (dicen que todo en Google se ejecuta en contenedores), Sun introdujo una forma de contenedores en Solaris en 2004/2005, e incluso los contenedores han estado disponibles en Windows a través de productos como Parallels Virtuozzo.
Sin embargo, lo nuevo es el cambio a pensar en los contenedores como una tecnología de desarrollo (en lugar de Infraestructura) y, críticamente, la aparición de software como Docker, que proporciona un formato de contenedor único que puede operar en múltiples tipos de hardware y SO.
El entusiasmo en la comunidad de desarrolladores es alto y la evolución tanto de Docker como de los esfuerzos de estandarización, como la Iniciativa Open Container, continúan a ritmo constante, pero las herramientas de administración para implementaciones de contenedores a gran escala (como Kubernetes) apenas comienzan a surgir para uso general y ciertamente aún no alcanzó el grado de madurez del disponible para la virtualización del servidor.
¿Esto significa que los contenedores deben evitarse por ahora?
No. Los contenedores ofrecen beneficios tanto para la infraestructura (mayor consolidación de la carga de trabajo, pero potencialmente con una reducción en el recuento de licencias del sistema operativo) como para el desarrollo (artefacto desplegable único que se ejecuta donde sea que se coloque y se inicie instantáneamente, especialmente importante para aquellos que crean aplicaciones de escalamiento dinámico) . Los contenedores son complementarios a la virtualización del servidor y no la desplazarán (y no deberían)..
Sin embargo, lo que las empresas deberían hacer es crear asociaciones entre los equipos de infraestructura y desarrollo para poner a prueba el uso de contenedores sobre plataformas de virtualización robustas. Comience con poco, evolucione la plataforma de alojamiento, las herramientas de administración y, de manera crítica, el proceso general en conjunto. Esperar solo significa que los competidores más proactivos obtendrán primero la productividad, el tiempo de comercialización y las ventajas de reducción de costos.
Como consultor principal para Claridad virtual, Chris Buckley ayuda Las organizaciones grandes y complejas modernizan su enfoque de la infraestructura de TI. Al trabajar con las organizaciones de TI para identificar los problemas correctos a resolver desde una perspectiva comercial, Chris lidera a los clientes a través del desarrollo y la implementación de la estrategia de infraestructura.
Únase a las comunidades de Network World en Facebook y LinkedIn para comentar temas que son lo más importante.
