Kubernetes, redes y encontrar el VMware de Cloud Native

Thomas Graf es cofundador y CTO de Isovalente, y creador de una popular tecnología de redes de código abierto (y nativa de la nube) llamada Cilio. Cilium está construido sobre una tecnología Linux a nivel de kernel llamada eGMP.

En esta entrevista, Graf analiza las funciones que desempeñan Cilium y eBPF en el creciente ecosistema de redes nativas de la nube, así como algunas tendencias más amplias en torno a la adopción y evolución de Kubernetes. Explica quién está usando y comprando Kubernetes dentro de las grandes empresas, dónde la infraestructura nativa de la nube aún necesita mejorar y cómo el deseo de estandarización está impulsando la innovación.

---

FUTURO: ¿Cómo deberíamos pensar sobre eBPF y Cilium en el contexto de la informática y las redes, en general, y luego específicamente en el contexto de la ecosistema nativo de la nube?

TOMÁS GRAF: En general, eBPF es la tecnología y es de un nivel extremadamente bajo. Fue diseñado para desarrolladores de kernel, y mi experiencia es en desarrollo de kernel. eBPF es para el kernel, para el sistema operativo, lo que JavaScript es para un navegador. Hace que el sistema operativo sea programable al igual que JavaScript hace que el navegador sea programable. En el pasado, teníamos que actualizar las versiones de nuestro navegador para usar ciertos sitios web. Y luego llegó JavaScript y, de repente, los equipos de aplicaciones y los desarrolladores pudieron crear aplicaciones masivas, hasta el punto en que la aplicación de procesamiento de texto más popular fue reemplazada por una aplicación en el navegador. Condujo a una gran ola de innovación. 

Con eBPF está pasando lo mismo, aunque a nivel de sistema operativo, porque de repente podemos hacer cosas a nivel de kernel o sistema operativo donde vemos todo y controlamos todo, que es muy importante para la seguridad, sin tener que cambiar de kernel. código fuente. Esencialmente, podemos cargar programas en el núcleo para ampliar su funcionalidad y traer consigo nuevas capacidades. Esto también ha desbloqueado una ola masiva de innovación. Los hiperescaladores como Facebook, Google y Netflix están usando esto solos, directamente, con sus propios equipos de kernel. 

Lo que Cilium trae a la mesa es que utiliza esa tecnología eBPF de bajo nivel para proporcionar esencialmente una nueva ola de infraestructura de software, particularmente para la ola nativa de la nube. Piense en esto como una red definida por software y lo que Nicira, que se convirtió en VMware NSX, hizo por la industria de la virtualización. Estamos haciendo lo mismo con la nube nativa, donde se trata de una combinación de proveedor de nube o infraestructura de nube pública, así como infraestructura local. Y estamos resolviendo casos de uso de redes, seguridad y observabilidad con eso en la capa de infraestructura.

Y Cilium Service Mesh, que se acaba de lanzar, ¿es una evolución de estas capacidades?

Lo que está sucediendo actualmente, desde hace aproximadamente un año, es que los dos espacios están chocando. Lo que Cilium ha estado haciendo hasta ahora se centra en las redes, las redes virtualizadas y luego las redes nativas en la nube, pero aún así las redes. Pero luego, desde arriba hacia abajo, los equipos de aplicaciones de Twitter y Google estaban haciendo malla de servicio cosas: primero en la aplicación, y luego en el modelo basado en sidecar, el modelo basado en proxy, que es lo que les gusta a los proyectos Istio entregar. Y ahora estas dos capas se están acercando porque las empresas tradicionales están ingresando al mundo nativo de la nube y tienen requisitos de redes empresariales, pero sus equipos de aplicaciones también quieren una red de servicios. 

Gartner está llamando a esta nueva capa "conectividad de servicio" (veremos si ese término se pone de moda), pero es esencialmente una capa que incluye la pieza de red empresarial y la pieza de malla de servicio que proviene de los equipos de aplicaciones. Y debido a que eso es lo que exigen los clientes, hemos agregado las capacidades al mismo Cilium. Entonces, esencialmente, Cilium va hacia arriba desde el lado de las redes empresariales y las mallas de servicio van hacia abajo hacia más del lado de las redes.

¿Por qué hay tanto enfoque en el nivel de red y malla de servicios de la pila de Kubernetes?

Porque con el deseo de ejecutarse en múltiples nubes y dividir las aplicaciones en contenedores, la capa de conectividad se ha vuelto central. Lo que solía ser quizás la comunicación entre procesos y el middleware ahora es la red, por lo que la red se está volviendo absolutamente esencial para que las aplicaciones se comuniquen entre sí y para que fluyan los datos. 

Y en cloud native, en particular, la nube múltiple se está volviendo absolutamente esencial. Todos los proveedores de la nube tienen sus propias capas de red, pero, por supuesto, adaptadas a sus propias nubes. Tienen ofertas locales, pero no son realmente multinube. Cilium y eBPF traen a la mesa esa capa agnóstica de múltiples nubes. Se comporta exactamente igual en las instalaciones que en la nube pública. Varios de los proveedores de nube pública están usando Cilium bajo el capó para sus ofertas administradas de Kubernetes, y las empresas de telecomunicaciones lo están usando para la infraestructura 5G local. Se trata de hablar ambos idiomas y conectar estos mundos.

Es por eso que hay tanto enfoque en esto: porque una de las formas más fáciles para que los proveedores de la nube fijen a los clientes es poseer esa capa de conectividad. Creo que desde una perspectiva de infraestructura estratégica, al igual que la capa de virtualización era clave, ahora la capa de conectividad y red es absolutamente clave.

La fuente de la innovación [futura] será de código abierto, y los clientes y usuarios que impulsarán la demanda serán empresas un nivel por debajo de los hiperescaladores, empresas que ya son importantes y que siguen siendo muy disruptivas.

Kubernetes es ampliamente aceptado y adoptado en este momento, pero todavía se habla en algunos círculos de que es una exageración. ¿Para quién cree que es Kubernetes y el ecosistema nativo de la nube en general?

Es para equipos de aplicaciones modernos. Creo que se ha dado cuenta de que si desea atraer equipos de aplicaciones modernos y poder tener tiempos de comercialización rápidos, debe proporcionarles una infraestructura nativa de la nube. A menudo vemos prototipos (inicial, pre-MVP, incluso probando el concepto o vendiendo internamente) sin servidor, algo así como Lambda. Y luego en Kubernetes, porque los equipos de aplicaciones pueden poseer la infraestructura directamente. Y luego, a medida que pasa a la producción, van a las distribuciones de Kubernetes locales y empresariales. Pero eso es en realidad una porción relativamente pequeña de toda la infraestructura, tal vez un porcentaje de uno o dos dígitos. 

Sin embargo, claramente será el nuevo estándar. Al igual que la adopción de la virtualización fue muy lenta inicialmente y la gente decía que era exagerada, pero con el tiempo, por supuesto, comenzó a reemplazar la mayoría de las cosas, veremos lo mismo aquí. O al igual que con los lenguajes modernos. La gente decía que Java era excesivo, y probablemente todavía lo sea para muchas aplicaciones, pero hubo un momento en el que se hizo muy difícil desarrollar cualquier aplicación fuera de Java porque eso es lo que la mayoría de los desarrolladores de aplicaciones podían escribir. Lo mismo ocurrirá. ser cierto para los equipos de aplicaciones modernos: esperarán tener Kubernetes cerca para desarrollar de manera más ágil y llevar el producto al mercado rápidamente.

En el lado de la infraestructura, puede ser un poco exagerado, pero si la alternativa es reescribir una aplicación sin servidor a local, esa es una tarea enorme. Entonces Kubernetes es el término medio allí, lo cual es muy atractivo. 

¿Qué pasa con la idea de que Kubernetes todavía necesita una mejor experiencia de desarrollador?

Si observamos el OpenShift original, antes de que se basara en Kubernetes, era este. Estaba aún más cerca del equipo de aplicaciones y fue una experiencia aún mejor para el desarrollador de aplicaciones. Podría empujar a Git y se implementaría automáticamente. Heroku también probó esto, pero basado en SaaS. 

Kubernetes dio un paso atrás y dijo: “Necesitamos mantener algunos aspectos operativos y hacerlo un poco más cercano a lo que esperaría un administrador de sistemas también. No podemos adaptarnos únicamente a las aplicaciones”. Es el término medio: debe ser lo suficientemente atractivo para los equipos de aplicaciones, pero aún debe ser posible ejecutar esa aplicación fuera de un entorno específico y que sea administrada por personas que no sean desarrolladores de aplicaciones.

Diría que el mayor paso entre Docker y Kubernetes fue que Docker tenía que ver con la experiencia del desarrollador. Resolvió esa parte, pero no resolvió la parte del ecosistema de nube pública.

¿Cómo llegamos a este punto? ¿Fue esta la evolución natural de la plataforma como servicio (PaaS) y los contenedores de aplicaciones?

Eran las imágenes de Docker y el aspecto de empaquetado de Docker. La vieja escuela era cómo implementar en máquinas virtuales, y había todo tipo de automatización en torno a eso. Y luego estaba lo que Facebook estaba haciendo con Tupperware: muy personalizado y para una escala realmente grande. Y luego apareció Docker y esencialmente proporcionó esta imagen de contenedor y todos podían tratarla como una máquina virtual en miniatura. Ahora puedo distribuir mi aplicación y en lugar de una imagen virtual de 600 MB, ahora es un contenedor de 10 MB. Pero puedes tratarlo igual, tiene todo lo que necesita. 

Eso desbloqueó la capacidad de traer un orquestador como Kubernetes que aún le permite tratar aplicaciones como mini VM, pero luego también dar un paso más y tratarlas realmente como microservicios. Te permite hacer ambas cosas.

Diría que el mayor paso entre Docker y Kubernetes fue que Docker tenía que ver con la experiencia del desarrollador. Resolvió esa parte, pero no resolvió la parte del ecosistema de nube pública. No tenía, ni necesariamente quería, una estrecha integración con los proveedores de la nube. Kubernetes resolvió eso. 

¿A quién ve ejecutando Kubernetes dentro de las empresas? ¿Son equipos de aplicación individuales?

Hay un cambio interesante que ocurrió con la nube nativa, que es que tenemos el surgimiento del "equipo de plataforma", lo llamaré. No son ingenieros de aplicaciones. Tienen un poco de conocimiento de operaciones de red y tienen bastante conocimiento de seguridad. Tienen conocimientos de SRE y saben cómo automatizar la nube. Proporcionan la plataforma para los equipos de aplicaciones y tratan a esos equipos de aplicaciones como sus clientes.

Los equipos de plataforma son los que compran Kubernetes y tecnologías relacionadas, que utilizan porque tienen la tarea de proporcionar esa infraestructura de próxima generación para hacer felices a los equipos de aplicaciones modernos.

Creo que definitivamente hay un espacio para serverless, en particular para el desarrollo de aplicaciones muy rápido. Pero en las empresas, estamos viendo la nube nativa como la nueva capa sobre la virtualización.

¿Es un comprador nuevo neto o un equipo nuevo neto? ¿O son los equipos de plataforma como algo que existe dentro de lugares como Google o Facebook y ahora se están generalizando?

Son en su mayoría un equipo nuevo. Creo que son, hasta cierto punto, como los equipos de SRE en Google y Facebook. Sin embargo, los equipos de aplicaciones probablemente controlen más la implementación de aplicaciones en las empresas, porque las empresas no tienen esta distinción muy clara entre los ingenieros de software y los SRE como Google y Facebook. Diría que esta evolución es muy similar a la forma en que tenía equipos de virtualización, y luego muchas operaciones de red migraron, evolucionaron o avanzaron desde la red. hardware a estar sobre la red virtualización. Y estos equipos, por ejemplo, comenzaron a operar VMware NSX. Lo mismo está pasando aquí. 

Aunque, no es necesariamente nuevo presupuesto. Vemos que los presupuestos cambian de seguridad y redes a este equipo de plataforma, por ejemplo, a medida que aumenta el gasto en la nube y se gasta menos en hardware de red. A menudo operan con el equipo de seguridad y con el equipo de operaciones de la red para obtener la aceptación, pero en realidad poseen una parte bastante importante del presupuesto.

¿Cómo ves el Fundación de computación nativa de la nube evolucionando, y Kubernetes siempre estará en el centro de esto, ¿o del movimiento nativo de la nube en general?

Kubernetes es lo que provocó el CNCF, y en los primeros años todo se trataba de Kubernetes y la nube pública. Lo que hemos visto desde hace aproximadamente un año es que ahora ya no se trata solo de Kubernetes, en realidad se trata más de la nube nativa. principios. En realidad, esto significa que ya no es necesariamente una nube, ni siquiera una nube privada. A menudo se trata incluso de redes empresariales tradicionales, infraestructura local aburrida, servidores completos y todo eso, pero con los principios nativos de la nube integrados. 

La nueva norma ahora es híbrida e incluye múltiples proveedores de nube pública, así como infraestructura local. Las empresas quieren proporcionar la misma agilidad de desarrollador de aplicaciones, o proporcionar observabilidad con herramientas nativas de la nube modernas, o hacer seguridad con herramientas nativas de la nube modernas, por ejemplo, autenticación, en lugar de solo segmentación o cumplimiento basado en la identidad, todos esos nuevos conceptos nativos de la nube en infraestructura existente. 

Estamos viendo una demanda muy fuerte para seguir conectándonos al viejo mundo y hablar de MPLS, VLAN, sFlow y NetFlow: todo el conjunto existente de requisitos empresariales. Ninguno de ellos se ha ido.

Aproximadamente una década después, el espacio nativo de la nube no parece ser una moda pasajera. ¿Cuánto espacio hay para que siga evolucionando?

Definitivamente hubo un momento en el que fue como, "Oh, Kubernetes probablemente sea de corta duración, y sin servidor será la siguiente capa". O, “Kubernetes es similar a OpenStack. O, “Desaparecerá y será un detalle de implementación”. Y eso no ha sucedido. 

Creo que definitivamente hay un espacio para serverless, en particular para el desarrollo de aplicaciones muy rápido. Pero en las empresas, estamos viendo la nube nativa como la nueva capa sobre la virtualización, y creemos que tiene una vida útil similar a la virtualización. Lo que significa que estamos al comienzo de la migración nativa de la nube.

¿Qué grandes problemas aún deben resolverse a nivel de infraestructura?

Estamos viendo empresas en una situación en la que, de repente, lo quieran o no, necesitan una estrategia de múltiples nubes. Debido a que también tienen una infraestructura local, ahora necesitan una estrategia de nube híbrida además de eso. Y necesitan descubrir cómo hacer seguridad y otras funciones universalmente en esta infraestructura sin encerrarse en una nube pública en particular. 

Entonces, este es el próximo gran desafío: ¿Quién va a ser esa capa agnóstica para múltiples nubes y nativos de la nube, como en lo que se convirtió VMware? ¿Quién va a ser el VMware nativo de la nube?

Creo que se ha dado cuenta de que si desea atraer equipos de aplicaciones modernos y poder tener tiempos de comercialización rápidos, debe proporcionarles una infraestructura nativa de la nube.

Y aunque la adopción nativa de la nube podría haber sido relativamente fácil para las empresas web modernas que fueron las primeras en adoptarlas, el desafío desde su perspectiva es crear nuevas tecnologías que cierren la brecha entre este mundo moderno y las herramientas y los sistemas empresariales existentes.

La parte difícil es que los equipos de aplicaciones modernos están acostumbrados a que la capa de infraestructura evolucione tan rápido como ellos. Y esto obligó a que la capa de infraestructura fuera aún más programable, más ajustable. Es por eso que en realidad vemos una capa de red y una capa de seguridad encima de la capa de red en la nube. Pero ahora tenemos empresas que ingresan y estamos viendo una demanda muy fuerte para seguir conectándose al viejo mundo y hablar de MPLS, VLAN, sFlow y NetFlow: todo el conjunto existente de requisitos empresariales. Ninguno de ellos se ha ido, todas las reglas de cumplimiento siguen siendo las mismas. Y Incluso algunas de las empresas modernas de SaaS ahora enfrentan estos desafíos a medida que crecen y se preocupan por el cumplimiento. y así sucesivamente. 

Desde una perspectiva tecnológica, se trata de cómo conectar ese nuevo mundo nativo de la nube con los requisitos empresariales existentes. Porque muchos de estos problemas estaban ocultos por los proveedores de la nube pública. Los proveedores de nube pública resolvieron los problemas de cumplimiento, pero no abrieron ni publicaron nada de eso; ellos mismos lo resolvieron. Es parte del valor de la nube. Las empresas ahora necesitan reconstruir y comprar eso si no quieren encerrarse en las ofertas de nube pública.

¿De dónde cree que provendrá la próxima ola de innovación nativa de la nube? ¿Sigue proviniendo de una empresa como Google, o hay un nuevo tipo de empresa que lidera el cambio?

Es muy interesante. Diría que probablemente no provenga de Google y Facebook. La fuente de innovación será el código abierto, y los clientes y usuarios que impulsarán la demanda serán empresas un nivel por debajo de los hiperescaladores, empresas que ya son importantes pero que siguen siendo muy disruptivas, como Adobe, Shopify o GitHub. Pero también empresas en riesgo de verse afectadas por la tecnología, como los servicios financieros, los proveedores de seguros y las empresas de telecomunicaciones. Todas estas empresas tienen un interés compartido en estandarizar la infraestructura con modelos de desarrollo e infraestructura repetibles.

Publicado julio 26, 2022