El Derby de los Containers

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 que tenemos hoy.

Otro paso importante fue el de los contenedores Linux en 2008. Ahora, teníamos una virtualización a nivel del sistema operativo. Por fin podíamos ejecutar varios contenedores utilizando un único kernel de Linux y eso eliminó la necesidad de máquinas virtuales completas. Esto significa que los costos de infraestructura comienzan a bajar. No todos vieron el potencial de los contenedores de inmediato.

La creación de contenedores fue realmente una idea revolucionaria. Era algo completamente nuevo.

Laura Frank es la vicepresidenta de Ingeniería en Aula Education.

Solo un grupo muy pequeño de personas comprendía los detalles y podía operar la tecnología. Y lentamente con el tiempo, a medida que más gente conoce la idea y que más personas comienzan a trabajar en ella y que el conocimiento se disemina en equipos y organizaciones de ingeniería y en comunidades, este se vuelve más disponible.

Laura piensa que, debido a esa similitud con las máquinas virtuales que describimos antes, el potencial de los contenedores se perdió un poco.

Creo que por donde estaba en mi carrera y para el tecnólogo general, la creación de contenedores, si uno no era administrador de sistemas o había estado muy involucrado en Linux, seguía siendo un concepto nuevo con el que me familiaricé brevemente. Lo entendí como “Ah, esto es como el patrón para el que usaría una máquina virtual, puedo hacer un entorno desechable totalmente aislado y luego limpiar todo”.

Sin embargo, los contenedores harían mucho más que mantener las cosas limpias. Iban a revolucionar una industria. Y con el aumento de las comunidades y los proyectos de código abierto, pronto se hizo posible la estandarización de contenedores.

La interfaz se volvió muy simple.

Scott McCarty trabaja en Red Hat como gerente principal de productos de contenedores. Es lo suficientemente veterano que recuerda trabajar en una época no solo anterior a los contenedores, sino también anterior a las máquinas virtuales.

Trabajé en un minorista en línea en el puntocom 1.0 y teníamos miles de máquinas físicas e implementábamos la misma pila de software una y otra vez en muchos servidores diferentes y probábamos todo tipo de metodologías. Fue realmente el mismo problema cuando pasabas de sistemas operativos sin formato a máquinas virtuales y luego a contenedores Linux, contenedores Solaris, aún tenías que gestionar la configuración en todas esas máquinas virtuales, o construcciones que parecían instancias del sistema operativo.

Una vez que los contenedores se estandarizaron, todo eso comenzó a cambiar.

Había un montón de formas muy estándar de lidiar con las aplicaciones ahora empaquetadas, y creo que eso es fundamentalmente lo que realmente cambió todo. Simplemente hizo que sea muy fácil de usar y, además, tenía la ventaja de ser más pequeño y más rápido que las máquinas virtuales.

A partir de los avances que ofrecieron los contenedores Linux, estas nuevas comunidades y proyectos de código abierto llevaron a los desarrolladores de la mano. Algunas de nuestras ansiedades sobre el backend desaparecieron. De repente, los contenedores y los microservicios que facilitaron se veían muy atractivos. Una vez que surgió un lenguaje de contenedores común, las barreras cayeron y la tecnología de contenedores cambió la forma en que trabajábamos. También cambió la velocidad con la que podíamos aprender sobre nuevas tecnologías.

La comunidad de desarrolladores vio cuán rápidos, económicos y fáciles se habían vuelto los contenedores, mucho más fáciles que los sistemas operativos estándar que usábamos antes. La tasa de adopción fue bastante impresionante. Pero recuerda: la aparición de un estándar de contenedores fue realmente el precalentamiento para la verdadera carrera: la orquestación.

Los caballos se alinean, se oye el disparo y al fin salen corriendo para disputarse el campeonato. No por los contenedores en sí, sino por las herramientas que los implementarían y gestionarían.

Esto es Command Line Heroes en español.

En la carrera por convertirse en el motor estándar de orquestación de contenedores, ¿quién ofrecería una plataforma que gestione todos esos contenedores? Al principio, había dos concursantes que se disputaban el podio. Mesos, impulsado por Apache, y Swarm, impulsado por Docker. Pero, ¿qué es esto? Un recién llegado irrumpe en la pista. Era Google. Linux había establecido la Cloud Native Computing Foundation o CNCF, e impulsando el nuevo motor de orquestación de código abierto de Google, Kubernetes.

Ahora, podríamos decir que Mesos y Swarm tenían ventaja respecto a Kubernetes, ¿verdad? Estaban respaldados por Apache y Docker, que ya llevaban un tiempo en esta carrera. Pero Kubernetes tenía algo que los otros caballos no tenían. Y Clayton Coleman puede decirnos cuál fue ese ingrediente secreto. Clayton es arquitecto de Kubernetes y OpenShift en Red Hat.

Desde el comienzo de Kubernetes, Google fue muy hábil en abrir el proyecto y facilitar la contribución y participación en él. Había un enfoque muy fuerte en crear algo que le hiciera más fácil la vida a la mayoría de los desarrolladores y operadores. Creo que Kubernetes y la comunidad en torno a Kubernetes pudieron encontrar un punto ideal lo suficientemente bueno para la mayoría de las personas y suficientemente extensible como para resolver algunos de los casos de uso más extremos.

En los primeros días, Kubernetes involucró a ingenieros de Red Hat, CoreOS y Google. Luego, cuando Kubernetes llegó a la versión 1.0, personas en startups y grandes empresas empezaron a adoptarlo y a construir sobre él. Y aquí está la cuestión. Ese crecimiento nunca estuvo fue dictado por Google ni por nadie más.

Por eso, la analogía que me encanta usar en este caso es Linux. Linux no comenzó cuando Linus escribió el kernel y les contó a todos los usuarios cómo escribir el set de compiladores GCC o cómo crear NGINX o Apache.

Por eso, la analogía que me encanta usar en este caso es Linux. Linux no comenzó cuando Linus escribió el kernel y les contó a todos los usuarios cómo escribir el set de compiladores GCC o cómo crear NGINX o Apache. En cambio, el equipo de kernel se centró en construir un sistema operativo central muy efectivo y en trabajar con otras comunidades de código abierto como el proyecto GNU para llevar las herramientas que funcionaban en otros Unix a Linux. Y por eso, en muchas de las herramientas que ejecutamos hoy no hubo contribuciones del equipo central de Linux.

Pero Linux en su conjunto es mucho más amplio que solo el kernel, y pienso que ese patrón es algo para lo que creemos que Kubernetes está bien posicionado para aprovechar. Así que, a medida que construimos una comunidad y nos enfocamos en determinar el alcance de Kubernetes, intentamos pensarlo como un Kubernetes central, que se trata del kernel de un sistema operativo de clúster distribuido.

Kubernetes demostró ser increíblemente bueno en crear una comunidad en un mundo de código abierto. Al igual que vimos en el Episodio Dos con el ascenso de Linux, el ganador de las carreras de hoy con frecuencia es aquel que sabe cómo convocar a la comunidad.

De hecho, si bien Google pudo haber comenzado Kubernetes, ahora pertenece a todos los desarrolladores y es gestionado por la Cloud Native Computing Foundation. Esta es tecnología hecha por nuestra comunidad, para nuestra comunidad.

Pero, ¿de qué manera una compañía enorme con fines de lucro terminó llevándose tan bien con otros? Kelsey Hightower es un técnico que trabaja en Google en todo lo que tiene que ver con contenedores.

Cuando uno piensa en la posición de Google, tienen mucha experiencia en hacer sistemas distributivos y ejecutar cosas en muchos muchos servidores alrededor del mundo, así que da la impresión de que tenían una muy buena posición para hacer Kubernetes y ganar, y hacerlo muy bien. Entonces, cuando piensas en la relación entre Kubernetes y el código abierto, ¿cómo ves esa relación?

Creo que cuando se trata de herramientas de infraestructura e incluso lenguajes de programación, no hay opción. No puede haber una herramienta exclusiva, incluso si es excelente. La mayoría de la gente probablemente ni siquiera la mire si no es de código abierto.

Y creo que el motivo por el que la mayoría de las personas adopta tecnologías como herramientas de infraestructura como Kubernetes es que puedes tener el control y decir: “Nos quedaremos con esta versión por cuatro o cinco años” o “debemos modificarla para nuestras necesidades específicas”. Una vez que llegas a ese punto, es muy difícil convencer a una empresa para que diga: “Oye, serán $200 por servidor y no puedes ver el código fuente, así que espera a que lo modifiquemos nosotros”.

Eso ya no existe. Por lo tanto, no sé si realmente se puede hacer infraestructura sin que sea de código abierto. Y luego la segunda parte del código abierto sería la comunidad que se puede acoplar a él, y creo desde el primer momento Kubernetes lo logró.

Volvamos a la competencia. Porque no era solo Kubernetes como tú mismo dijiste, estaba Swarm de Docker, estaba Mesos de Apache...

Bueno, creo que cuando la gente habla de la batalla, no sé si la batalla era realmente entre Mesos y Docker, creo que la batalla era entre personas que no tenían nada. Digamos que vienes de los guiones Bash caseros, todavía estás luchando por intentar llegar a donde debes estar, y el mercado de personas que no usan herramientas de orquestación es mucho más grande que las personas que ya han elegido, digamos, Mesos o Swarm.

Así que esa es la batalla y continuará siéndolo. Entonces, realmente se trata de ayudar a los usuarios finales ahora. ¿Mesos, Kubernetes o Docker Swarm se convierten en la opción de preferencia para las personas que buscan obtener una mejor solución? Eso se puede debatir, pero te diré, las personas como yo, los ingenieros que trabajan en esto, si haces a un lado el marketing y algunos de los proveedores, las personas que trabajan en esto, yo uso la frase: “diferentes compañías, los mismos equipos”.

Muchas de las herramientas que construimos para nosotros terminan en otros productos de una u otra manera. ¿Correcto? Una buena idea es una buena idea. Entonces, no hay razón para decir: “Ah, eso es lo que están haciendo en Mesos, ignorémoslo”. Eso es bastante tonto. Desde el punto de vista de la ingeniería y de la comunidad, hacemos una polinización cruzada de estas ideas. Ese tipo de competencia es casi necesaria para que todos pensemos de manera independiente, salgan a la superficie las mejores ideas y elijamos cuáles adoptaremos que aborden a los usuarios de la manera correcta.

Por lo tanto, aún es temprano en términos de todo esto de la competencia y, nuevamente, no cuesta nada de dinero. ¿Entiendes lo que digo? No le estamos vendiendo esto a nadie directamente, es realmente más un juego de plataforma abierto para todos donde luego los usuarios elegirán lo que satisfaga sus necesidades y es donde creo que Kubernetes ha hecho un gran trabajo en términos de comunidad, al ser abierto y resolver problemas.

Eso fue muy hermoso. Realmente me gusta esta idea de jugar en el mismo equipo independientemente de dónde se encuentre ese equipo. ¿Cuál consideras que es el futuro de los contenedores y de la orquestación, e incluso de Kubernetes?

Bueno, hice una presentación en KubeCon sobre lo excelente que son todas estas herramientas. Son todos ladrillos Lego, tenemos Kubernetes, y puedes elegir otro producto para seguridad, elegir otro producto para redes, pero en definitiva, como desarrollador, lo que quieres realmente es verificar tu codificación y esperar que ese código aterrice frente a tu cliente de alguna manera. Y creo que Kubernetes y los contenedores se convertirán en el sustrato o simplemente las piezas de la plataforma para cosas de alto nivel como Serverless.

¿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.