El futuro de WebAssembly a través de los ojos de un ingeniero veterano de Kubernetes

En la etapa de Pasadena de Kubernetes Community Days (ubicada junto con SCaLE 20x), tuve la oportunidad de hablar con aproximadamente 100 entusiastas de Kubernetes , para dar mi perspectiva sobre WebAssembly, a través de la lente de un veterano de Kubernetes.

Debería calificar esto diciendo que tengo piel en este juego en particular. He estado en Kubernetes desde el principio, comenzando temprano con Docker (0.6-ish) y trabajando con Kubernetes desde 1.2, construyendo plataformas Kubernetes antes de que fueran una cosa. Fui mantenedor principal de Helm durante 4 años y cocreador de Bindle y Krustlet, un esfuerzo inicial para hacer que WebAssembly funcione bien con Kubernetes. Una forma larga de decir que lo entiendo totalmente, entiendo las fortalezas y los puntos débiles de los contenedores y Kubernetes.

También vengo del espacio WebAssembly, profundamente involucrado durante los últimos 3 años más o menos. Con los pies en ambos campos, esta es mi opinión sobre para qué sirven estas dos iniciativas abiertas y cómo podría y debería ser la intersección.

Kubernetes y Docker cambiaron las reglas del juego porque permitieron a los ingenieros y desarrolladores de plataformas dividir el monolito en microservicios y aplicaciones, manejables de forma aislada del resto de la infraestructura. WebAssembly va un nivel más profundo, permitiéndonos dividir aplicaciones individuales en componentes componibles que pueden intercambiarse en caliente, administrarse y configurarse por separado de su entorno. Wasm es, esencialmente, todo lo que queremos en el código del lado del servidor: seguro por defecto, portátil, políglota (particularmente en el navegador), rápido, eficiente y altamente escalable.

Entonces, ¿cómo se cruzan Kubernetes y Wasm? Primero, abordemos la fábrica de rumores de las redes sociales y rompamos algunos mitos.

Mito #1: Wasm matará los contenedores.

No. Definitivamente no. Nadie va a reescribir Redis para que funcione en el navegador cuando funciona bien en contenedores. Hay tantos casos en los que Kubernetes es la solución adecuada. Hay una serie de aplicaciones empresariales grandes (Drupal, Redis, nginx) que existen desde hace mucho tiempo y que no se trasladarán a Wasm en el corto plazo.

Mito n.º 2: debo seguir adelante y ejecutar Wasm en mis contenedores, ¿verdad?

No estamos diciendo que no debas hacerlo, pero puede que no sea el punto de partida correcto y que solo agregues capas adicionales de complejidad. Tiene la sobrecarga de iniciar el contenedor Docker (que no es multiplataforma), agregada a la sobrecarga de iniciar WebAssembly. Probablemente no valga la pena la sobrecarga de rendimiento, especialmente con todas las herramientas disponibles que mencionaré más adelante]

Mito #3: Wasm no es compatible con Kubernetes.

¡Sí, lo es! Esta es una historia de "Mejor Juntos". Todo es evolutivo con las computadoras. El hecho de que se nos ocurran máquinas virtuales no significa que no tengamos la necesidad de hardware físico. Y solo porque apareció Wasm, no significa que no necesitemos contenedores. Para ver esto en acción, lea cómo nuestros amigos de Adobe están transformando su arquitectura Kubernetes con Wasm .

Al igual que en los primeros días de Kubernetes, estamos en esa fase en la que las cosas se rompen y evolucionan muy rápidamente. La creación de redes sigue siendo difícil en el lado del servidor en el nivel de Wasm sin procesar. Pronto obtendremos soporte de socket y las cosas se están moviendo rápidamente. Las cadenas de herramientas de lenguaje y el código de rendimiento de bajo nivel también son cruciales, pero aún no están ahí. Sin embargo, es un momento emocionante. Los estándares WASI (Wasm sin navegador) han recorrido un largo camino, incluso en las últimas semanas; hablaremos más adelante.

¿Por qué Wasm ?

La verdad es que Kubernetes tiene sus límites, particularmente en el perímetro . Aunque se han hecho muchos progresos (un gran reconocimiento a proyectos como K3), las cosas solo pueden llegar hasta cierto punto. Kubernetes está diseñado para ejecutarse en clústeres que, en la mayoría de los casos, forman parte de la misma región geográfica. Cuando algo se ejecuta en una torre celular, una central eléctrica o una tienda física, Kubernetes no escala muy bien. Hemos visto esto cuando hablamos con los miembros de nuestra comunidad. Wasm es verdaderamente una arquitectura multiplataforma y se ejecuta en un tamaño muy pequeño, lo que lo convierte en un mejor candidato para el perímetro.

El costo y la utilización también son factores importantes . Hemos hablado con varias empresas de Fortune 100 y su utilización del servidor Kubernetes se sitúa en torno al 25-35 % de la capacidad total, con algunas hasta el 50-60 %. Muchos han reducido sus equipos internos de Kubernetes porque es muy costoso. Wasm nos permite empacar mucho más en un espacio más pequeño y aprovecharlo mejor.

La seguridad también es un beneficio importante de Wasm. Los contenedores son bastante seguros, pero hay muchos matices que crean complejidad, especialmente para los desarrolladores. De forma predeterminada, un módulo WebAssembly no puede hacer nada a menos que le otorgue el privilegio para hacerlo.

¿Qué podemos hacer con Kubernetes y Wasm ahora mismo ?

Sin embargo, dicho todo esto, ¿qué es realmente posible hacer con Wasm y Kubernetes en este momento? Revisemos tres de los escenarios más grandes en los que puede aprovechar Wasm de inmediato.

runwasi en contenedor CNCF

Una forma realmente genial de usar Wasm es ver el maravilloso proyecto runwasi que es parte del ecosistema de contenedores de CNCF. Esencialmente, runwasi le permite ejecutar un tiempo de ejecución de WebAssembly a través de un contenedor dentro de Kubernetes. Esta es una opción mucho mejor que intentar ejecutar Wasm dentro de un contenedor, ya que ejecuta WebAssembly directamente, tal como lo haría si hiciera girar un contenedor en un pod.

Mallas de servicio, ¿alguien ?

Envoy y otras mallas ya tienen la capacidad de escribir complementos mediante WebAssembly. Con estos, puede escribir filtros personalizados y otros modelos de complementos utilizando cualquier lenguaje que se compile en WebAssembly.

wasmCloud

Sabemos que las empresas ya están viendo el valor de unir a Kubernetes con Wasm en una serie de casos de uso diferentes. Pero wasmCloud lo lleva al siguiente nivel debido a su capacidad para conectar computación dispar en una topología de red plana. Mi segunda demostración mostró lo fácil que es mover el mismo código a través de tres nodos diferentes, cada uno en una ubicación diferente. En este caso, mi Mac en Pasadena, un clúster Digital Ocean K8s en Nueva York y wasmCloud. Sin refactorización, mismo código, cualquier ubicación. A continuación, la plataforma Cosmonic (basada en wasmCloud) traerá el tipo de enfoque de servicio completo a Wasm que las empresas necesitarán a medida que pasan a la producción.

¿Quiere probar wasmCloud en una plataforma gestionada?

Comience con Cosmonic gratis hoy. ¡Lanzar ahora!

modelo de componente

Finalmente, y lo más emocionante, las cosas se están moviendo rápido en este espacio. Echa un vistazo a la charla de E/S de WASM de Bailey Hayes y Dan Chiarlone, que mostró lo lejos que hemos llegado en la definición de los estándares WASI y el modelo de componentes: fue la primera visión de cómo realmente queremos que sea el futuro. Puede seguir el progreso aquí y unirse a Bytecode Alliance para escuchar lo último a medida que sucede.

- Por Taylor Thomas , líder de ingeniería en Cosmonic

Si está interesado en obtener más información, tiene preguntas o le gustaría chatear, conéctese con nosotros en Discord o Slack .