Command Line Heroes en español. Temporada 1: El Derby de los Containers

El Derby de los Containers

13 de marzo de 2018 | Command Line Heroes Team

Contenedores

Historia de la tecnología

Command Line Heroes • • Command Line Heroes en español. Temporada 1: El Derby de los Containers

Command Line Heroes en español. Temporada 1: El Derby de los Containers

About the episode

Dado que los contenedores simplifican el movimiento de trabajo de una máquina a otra, el auge de esta tecnología abre otras fronteras a los desarrolladores. Sin embargo, a medida que los contenedores ganan popularidad, se gesta una nueva batalla. En esta ocasión, la carrera es por tener el control de la coordinación e involucra a los actores más rápidos y fuertes del sector.

Los contenedores son una de las evoluciones más importantes del movimiento open source. En este episodio, los invitados destacados Kelsey Hightower, defensor de los desarrolladores de Google, y Laura Frank, Docker Captain y Directora de ingeniería de Code Ship, entre otros, explican por qué esta nueva tecnología es la base del futuro.

Command Line Heroes Team Red Hat original show

Transcripción

Bueno. ¿Alguna vez fuiste a una carrera de caballos y los viste alineados y golpeando la tierra? Eso es lo que tienes que imaginarte. Está por comenzar una carrera y el resultado convertirá a uno de estos competidores en el campeón.

Solo que no son caballos. Son los gigantes del mundo de la tecnología. ¿Qué hace tan importante esta carrera? ¿Qué premio podría ser tan valioso que están todos alineados, comiéndose las uñas? Esta es una carrera a por todo para controlar la orquestación de la tecnología de contenedores. Y, bueno, no es como otras carreras. Quien gane esta carrera no será solo el campeón de hoy, sino que se asegurará el puesto como campeón del futuro.

Esto es Command Line Heroes en español, un podcast original de Red Hat. Episodio cinco: El derbi de los contenedores. La última vez vimos el surgimiento de DevOps y cómo un nuevo conjunto de herramientas está ligado a nuevos puntos de vista sobre la función de los desarrolladores. En este episodio, seguiremos el surgimiento de los contenedores y cómo amplían aún más la función de los desarrolladores al permitir nuevos tipos de trabajo sin restricciones.

Y veremos cómo la estandarización de los contenedores trazó la pista de esa carrera hacia la orquestación de contenedores. Esta es una carrera importante y global, que atrae a algunos de los participantes más rápidos y fuertes de la industria. Están listos para salir corriendo hasta la meta. ¿Listos? Y salen.

Ahora, a medida que los caballos salen de la puerta, quizás deberíamos aclarar por qué esta carrera es tan importante.

Un contenedor en realidad es un proceso.

Liz Rice es una evangelista de la tecnología de Aqua Security. Está describiendo lo que hace que los contenedores sean tan útiles: el hecho de que coloquen todo en un ordenado paquete transportable.

Es igual que cualquier otro proceso, excepto que tiene una visión muy restringida del mundo. Por ejemplo, comienzas un contenedor. El proceso recibe su propio directorio raíz y cree que está viendo el directorio raíz completo de toda la computadora, pero en realidad solo está viendo un pequeño subconjunto del sistema de archivos.

Al empaquetar un ejecutable con todas sus dependencias, los contenedores pueden ejecutarse en cualquier computadora portátil o en cualquier máquina virtual en la nube. Viene con sus propios ejecutables, sus propias bibliotecas y dependencias. Está todo "contenido" en un contenedor. Entonces, y aquí sucede la magia, un contenedor va a funcionar exactamente igual en todos los entornos. Esto significa que los desarrolladores pueden compartir aplicaciones sin preocuparse por el viejo problema de "funciona en mi equipo".

Aquí hay una analogía que podría ser útil. ¿Conoces esos servicios que llevan en una sola caja todo lo que necesitas para preparar una comida? ¿Todo bien dividido y en porciones, con la receta y todo? Bueno, imagínate si uno de esos servicios te llevara no solo los ingredientes cortados, sino también una cocina y todos los cubiertos. Todo lo que necesitas en una pequeña caja en la puerta de tu casa. Eso es un contenedor. Las máquinas virtuales también te dan una oferta preempaquetada, pero es ahí donde tenemos que dejar la analogía de la caja de alimentos y pasar a algo más específico.

Muchas personas tienen la impresión de que los contenedores son una especie de virtualización liviana, máquinas virtuales livianas, y realmente no lo son. Son muy diferentes a las máquinas virtuales. Una máquina virtual tiene todo un sistema operativo para ella sola, mientras que un contenedor comparte el sistema operativo, es decir, todos los contenedores en una máquina comparten el mismo sistema operativo.

En definitiva, los contenedores y las máquinas virtuales van a funcionar de forma conjunta. Los contenedores no reemplazan a las máquinas virtuales. La virtualización continuará aumentando la eficiencia en un sistema de datos y sigue siendo crucial para la consolidación del servidor.

Pero el surgimiento de los contenedores abre una nueva puerta que antes estaba cerrada. Piénsalo de este modo: si solo usáramos máquinas virtuales para ejecutar todos los servidores emulados, el costo sería enorme. Una máquina virtual puede tener un tamaño en gigabytes, mientras que un contenedor podría ser de 20 megabytes. Una máquina virtual podría tardar varios minutos en arrancar. Ese no es un buen ritmo si intento implementar aplicaciones basadas en la web. Hacía mucho que se necesitaba una alternativa más rápida y liviana a la virtualización completa de máquinas.

Veamos un poco de historia. Hubo una transición hacia un tipo de protocontenedor en 1979. Los desarrolladores que trabajaban en UNIX V7 diseñaron la llamada al sistema raíz, que posibilitó entornos que contenían solo ciertos programas. Ese avance marcó el rumbo hacia los contenedores modernos, pero el verdadero salto hacia adelante se produjo décadas después.

En 2008, un proyecto llamado LXC o Linux Containers, les dio a los desarrolladores una forma de aislar procesos usando las características principales del kernel de Linux. Era una forma de hacerlo tú mismo, pero no fue hasta que la empresa Docker apareció en 2013 que las cosas comenzaron a despegar realmente.

Docker no inventó los contenedores, pero sí hizo que fueran fáciles de usar. Proporcionó una interfaz fácil de usar y un formato de empaquetado de aplicaciones estandarizado. Docker democratizó los contenedores. Los desarrolladores no tenían que ser expertos en Linux para usar contenedores. Docker los hizo accesibles.

Y a medida que más desarrolladores comenzaron a usar Docker, se hizo evidente que se necesitaba algo más. Si tienes uno o dos contenedores, está bien. Puedes administrarlos manualmente. Pero, ¿qué pasa cuando tienes cientos o miles de contenedores? ¿Cómo los administras? ¿Cómo te aseguras de que estén funcionando? ¿Cómo escalas hacia arriba y hacia abajo según sea necesario? Ahí es donde entra la orquestación.

La orquestación de contenedores es como tener un director de orquesta para tus contenedores. Se asegura de que todo funcione en armonía. Y aquí es donde comenzó nuestra carrera. Había varios contendientes corriendo por controlar este espacio de orquestación.

Docker tenía su propia solución llamada Docker Swarm. Era simple y fácil de usar, perfecto para implementaciones más pequeñas. Luego estaba Apache Mesos, que había estado por ahí desde 2009 y era usado por empresas como Twitter y Airbnb para administrar sus centros de datos.

Pero el contendiente que eventualmente ganaría la carrera vino de Google. Se llamaba Kubernetes, y se basaba en el sistema interno de Google llamado Borg, que habían estado usando para administrar sus propios contenedores durante años.

Kubernetes era más complejo que Docker Swarm, pero también era más poderoso. Podía manejar implementaciones masivas y proporcionaba características avanzadas como auto-escalado, auto-reparación, y gestión de configuración. Google lo liberó como código abierto en 2014 y lo donó a la Cloud Native Computing Foundation.

La carrera estaba en marcha. Y para 2017, estaba bastante claro quién había ganado. Docker anunció que soportaría Kubernetes además de Swarm. Microsoft Azure y Amazon Web Services anunciaron soporte nativo para Kubernetes. El ganador era claro.

Pero, ¿qué hizo que Kubernetes fuera tan exitoso? Laura Frank, que es Docker Captain y Directora de ingeniería de Code Ship, nos puede explicar.

Kubernetes tenía esta capacidad de abstraer la infraestructura subyacente de una manera que realmente funcionaba para los desarrolladores. No tenías que preocuparte por en qué máquina específica estaba ejecutándose tu aplicación. Solo le decías a Kubernetes qué querías que sucediera, y se encargaba de hacerlo realidad.

Esta capacidad de abstracción fue clave. Los desarrolladores podían definir lo que querían en archivos de configuración simples, y Kubernetes se encargaba de todos los detalles complicados de la implementación.

También tenía una comunidad increíble. Google había aprendido mucho de su experiencia con Borg, y ese conocimiento se incorporó en Kubernetes desde el principio. Pero más que eso, la comunidad open source realmente abrazó Kubernetes y contribuyó a hacerlo mejor.

La comunidad fue crucial. A diferencia de algunos proyectos que son controlados por una sola empresa, Kubernetes realmente se convirtió en un proyecto comunitario. Empresas como Red Hat, CoreOS, y muchas otras contribuyeron código, ideas, y recursos.

Clayton Coleman, que es Arquitecto de Kubernetes y OpenShift en Red Hat, ha estado involucrado en el proyecto desde los primeros días.

Lo que hizo especial a Kubernetes fue que no era solo una herramienta, era una plataforma. Proporcionaba un conjunto de API y abstracciones que otros podían construir encima. Eso permitió a un ecosistema entero de herramientas y servicios desarrollarse alrededor de Kubernetes.

Y ese ecosistema es lo que realmente hizo la diferencia. No era solo Kubernetes por sí solo, sino todas las herramientas que se construyeron para trabajar con él. Herramientas para monitoreo, logging, networking, seguridad, y mucho más.

También fue importante que Kubernetes fuera diseñado para ser extensible desde el principio. Tenía este concepto de Custom Resource Definitions que permitía a los usuarios extender la API de Kubernetes para sus propias necesidades específicas.

Esta extensibilidad significaba que Kubernetes podía evolucionar y adaptarse a nuevos casos de uso sin tener que cambiar el núcleo del sistema. Fue una decisión de diseño brillante que pagó dividendos enormes.

Pero también había algo más sucediendo. Los contenedores no eran solo una nueva tecnología; representaban una nueva forma de pensar sobre las aplicaciones y la infraestructura. Kelsey Hightower, que es Developer Advocate en Google, lo explica bien.

Los contenedores cambiaron fundamentalmente cómo pensamos sobre el despliegue de aplicaciones. Antes, tenías que pensar mucho sobre el servidor específico donde iba a ejecutarse tu aplicación. Con contenedores, podías pensar en términos más abstractos.

Esta abstracción fue liberadora para los desarrolladores. Ya no tenían que preocuparse tanto por los detalles específicos de la infraestructura. Podían enfocarse más en escribir código y menos en administrar servidores.

Y esto abrió la puerta a conceptos como microservicios y arquitecturas nativas de la nube. De repente, era factible descomponer aplicaciones monolíticas grandes en servicios más pequeños e independientes.

Los microservicios se convirtieron en una tendencia importante. En lugar de tener una aplicación grande y monolítica, podías tener docenas o cientos de servicios pequeños, cada uno ejecutándose en su propio contenedor. Esto hizo las aplicaciones más resilientes y escalables.

También cambió cómo pensamos sobre el desarrollo de software. Con contenedores, es mucho más fácil tener entornos de desarrollo que coincidan exactamente con producción. El viejo problema de "funciona en mi máquina" se volvió mucho menos común.

Y esto llevó a mejores prácticas de DevOps. Los equipos de desarrollo y operaciones pudieron trabajar más estrechamente juntos porque estaban usando las mismas herramientas y abstracciones.

Pero quizás lo más importante es que los contenedores democratizaron muchas capacidades que antes solo estaban disponibles para las empresas más grandes. De repente, una startup pequeña podía usar las mismas herramientas y técnicas que Google o Facebook.

Esta democratización fue un cambio fundamental. Las barreras de entrada para construir y operar aplicaciones a gran escala se redujeron dramáticamente.

¿Correcto? Este es mi fragmento de código, sin que lo veas, todas las plataformas tomarán tu fragmento de código, lo pondrán en un contenedor y lo ejecutarán para ti, pero no necesitan mostrarte todo eso. Entonces, en el futuro, creo que a medida que Kubernetes se vuelve común, nivelará el campo de juego para que proveedores grandes y pequeños o personas que quieren hacer las cosas ellas mismas puedan ofrecer cosas que solo los proveedores de nube podrían haber hecho, debido a la experiencia requerida o la inversión en software necesaria.

Esto probablemente acabará estando en todas partes, pero también estará oculto. Así que desaparecerá a medida que se expanda.

Kelsey Hightower es Developer Advocate en Google.

En el otoño de 2017, Docker anunció que darán soporte a Kubernetes. No habían renunciado a Swarm, pero habían decidido hacer las paces con el evidente ganador de la carrera de orquestación. No estaban solos, Microsoft Azure y AWS anunciaron ambos soporte nativo para Kubernetes. Mientras tanto, las distribuciones de Kubernetes, como OpenShift, siguen evolucionando. Lo que estamos obteniendo es un Kubernetes central que puede ampliar y apoyar nuevos casos de uso, como microservicios o proyectos de integración continua. Clayton Coleman.

Ese ecosistema funcionará mejor con un modelo que se asemeje a Linux y creo que estamos bien encaminados hacia ese resultado. Así que, este, como todos los buenos proyectos de código abierto, tiene éxito cuando todos pueden participar para construir algo mejor que lo que cada uno podría construir individualmente.

Todo esto está sucediendo rápido. Es una carrera, después de todo, y eso es algo que hemos aprendido a esperar del código abierto. La primera vuelta casi termina antes de que hayamos podido siquiera echarle un vistazo a la definición de contenedores. Scott McCarty, de Red Hat.

Bueno, si pensamos cómo eran las cosas hace dos años, sabes, el formato de imagen del contenedor era un gran campo de batalla y diría que si retrocedemos seis meses, la orquestación era un enorme campo de batalla. Y luego, si ves KubeCon 2017 y las semanas anteriores, prácticamente todos los proveedores principales habían anunciado soporte para Kubernetes. Así que, es bastante obvio que Kubernetes había ganado en ese momento.

Un capítulo en la historia de los contenedores está llegando a su fin. Casi tan rápido como comenzó.

Así que Kubernetes se ha convertido en el estándar, y lo bueno es que ahora las definiciones de aplicaciones se han estandarizado. Por lo tanto, cualquiera puede usar objetos de Kubernetes en archivos YAML y definir aplicaciones, es lo que queríamos, literalmente, he deseado esto por 20 años en el manejo de sistemas a gran escala.

El éxito de Kubernetes parece bastante concreto, pero incluso después de que termine la gran carrera, todavía nos quedan algunas preguntas importantes. ¿Los contenedores se convertirán en la opción predeterminada en los próximos años?

¿Van a fomentar más desarrollo nativo en la nube? ¿Y cuáles son todas las herramientas y los servicios que inspirarán estos cambios? Esto es lo que sabemos. A través de la CNCF, la comunidad continuará mejorando Kubernetes y, según la misión de la fundación Linux, también desarrollaremos un conjunto totalmente nuevo de tecnologías de contenedores.

Los contenedores ya están produciendo nuevos niveles enormes de infraestructura y demandando tipos de servicios completamente nuevos. Solo para darte una idea de cuán integrales se han vuelto, y con qué rapidez, Netflix solo está lanzando más de un millón de contenedores cada semana. No es exagerado decir que los contenedores son los componentes fundamentales del futuro.

En toda esta temporada, hemos estado realizando un seguimiento de la evolución del movimiento del código abierto. Hemos visto cómo Linux logró el dominio en primer lugar y cómo las actitudes del código abierto han cambiado el negocio, el flujo de trabajo y las herramientas que usamos todos los días.

Pero los contenedores son una de las evoluciones más importantes en ese movimiento del código abierto. Son móviles, son livianos, son fácilmente escalables. Los contenedores representan lo mejor del código abierto y no es de extrañar que proyectos de código abierto hayan impulsado el desarrollo de la tecnología de contenedores. Es un nuevo mundo. Y ya no nos preocuparemos por pasar de una máquina a otra, o, por entrar y salir de nubes.

La estandarización de los contenedores está ocurriendo más rápido de lo que nadie hubiera previsto. En el próximo episodio, veremos una batalla que todavía está sin resolverse. La guerra de las nubes está revelando pesos pesados de la industria como ninguna otra cosa. Se están enfrentando Microsoft, Alibaba, Google y Amazon, y la fricción entre estos cuatro proveedores de nube se está transformando en una gran tormenta. Perseguiremos ese relámpago junto con algunos de nuestros héroes de la línea de comandos favoritos, próximamente en el Episodio Seis.

Command Line Heroes en español es un podcast original de Red Hat. Para recibir nuevos episodios de forma automática y gratuita, asegúrate de suscribirte al programa. Simplemente busca Command Line Heroes "en espanol" en Spotify, Apple Podcasts, Google Podcasts o donde sea que obtengas tus podcasts. Luego, presiona la tecla de suscribirte para ser el primero en saber cuando hay disponibles nuevos episodios.

Gracias por escucharnos y sigan programando.

Sobre el podcast

Command Line Heroes

During its run from 2018 to 2022, Command Line Heroes shared the epic true stories of developers, programmers, hackers, geeks, and open source rebels, and how they revolutionized the technology landscape. Relive our journey through tech history, and use #CommandLinePod to share your favorite episodes.

El Derby de los Containers