O futuro do WebAssembly pelos olhos de um engenheiro veterano do Kubernetes

Na etapa de Pasadena do Kubernetes Community Days (co-localizado com o SCaLE 20x), tive a chance de conversar com cerca de 100 entusiastas do Kubernetes , para dar minha perspectiva sobre o WebAssembly, pelas lentes de um veterano do Kubernetes.

Devo qualificar isso dizendo que tenho pele neste jogo em particular. Estou no Kubernetes desde o início - começando cedo com o Docker (0.6-ish) e trabalhando com Kubernetes desde 1.2 - construindo plataformas Kubernetes antes de serem uma coisa. Fui o principal mantenedor do Helm por 4 anos e co-criador do Bindle e do Krustlet - um esforço inicial para fazer o WebAssembly funcionar bem com o Kubernetes. Uma maneira longa de dizer que entendo totalmente, entendo os pontos fortes e os pontos problemáticos dos contêineres e do Kubernetes.

Eu também venho do espaço WebAssembly, profundamente envolvido nos últimos 3 anos ou mais. Com os pés em ambos os campos, aqui está minha opinião sobre o que essas duas iniciativas abertas são boas e como a interseção poderia - e deveria - parecer.

O Kubernetes e o Docker mudaram o jogo porque permitiram que engenheiros e desenvolvedores de plataforma dividissem o monólito em microsserviços e aplicativos, gerenciáveis ​​isoladamente do restante da infraestrutura. O WebAssembly vai um nível mais profundo, permitindo-nos dividir aplicativos individuais em componentes combináveis ​​que podem ser trocados, gerenciados e configurados separadamente para seus arredores. Wasm é, essencialmente, tudo o que queremos em código do lado do servidor: seguro por padrão, portátil, poliglota (particularmente no navegador), rápido, eficiente e altamente escalável.

Então, como Kubernetes e Wasm se cruzam? Primeiro, vamos abordar o boato da mídia social e acabar com alguns mitos.

Mito nº 1: Wasm matará contêineres.

Não. Definitivamente não. Ninguém vai reescrever o Redis para funcionar no navegador quando ele funciona bem em contêineres. Existem muitos casos em que o Kubernetes é a solução certa. Existem vários aplicativos corporativos grandes (Drupal, Redis, nginx) que existem há muito tempo e que não serão transferidos para o Wasm tão cedo.

Mito nº 2: devo seguir em frente e executar o Wasm em meus contêineres, certo?

Não estamos dizendo que você não deveria, mas pode não ser o ponto de partida certo e você pode apenas adicionar camadas extras de complexidade. Você tem a sobrecarga de iniciar o contêiner do Docker (que não é multiplataforma), adicionada à sobrecarga de iniciar o WebAssembly. Provavelmente não vale a pena a sobrecarga de desempenho, especialmente com todas as ferramentas disponíveis que mencionarei mais tarde]

Mito nº 3: Wasm não é compatível com o Kubernetes.

É sim! Esta é uma história "Better Together". Tudo é evolutivo com computadores. Só porque criamos VMs não significa que não precisamos de hardware físico. E só porque Wasm apareceu, não significa que não precisamos de contêineres. Para ver isso em ação, leia como nossos amigos da Adobe estão transformando sua arquitetura Kubernetes com Wasm .

Como nos primeiros dias do Kubernetes, estamos naquela fase em que as coisas estão quebrando e evoluindo muito rapidamente. A rede ainda é difícil no lado do servidor no nível bruto do Wasm. Em breve, obteremos suporte a soquetes e as coisas estão se movendo rapidamente. Cadeias de ferramentas de linguagem e código de desempenho de baixo nível também são cruciais, mas ainda não estão lá. É um momento emocionante, no entanto. Os padrões WASI (não-browser Wasm) percorreram um longo caminho, mesmo nas últimas semanas - mais sobre isso depois.

Por que Wasm ?

A verdade é que o Kubernetes tem seus limites, principalmente na borda . Embora muito progresso tenha sido feito (grande mensagem para projetos como o K3s), há apenas um limite para as coisas. O Kubernetes deve ser executado em clusters que geralmente fazem parte da mesma região geográfica. Quando algo está sendo executado em uma torre de celular, estação de energia ou loja física, o Kubernetes não escala muito bem. Vimos isso quando conversamos com os membros da nossa comunidade. O Wasm é verdadeiramente uma arquitetura multiplataforma e é muito pequeno, tornando-o um candidato melhor para o edge.

Custo e utilização também são fatores importantes . Conversamos com várias empresas da Fortune 100 e a utilização do servidor Kubernetes fica em torno de 25 a 35% da capacidade total, com algumas subindo para 50 a 60%. Muitos reduziram suas equipes internas do Kubernetes porque é muito caro. Wasm nos permite embalar muito mais em um espaço menor e obter uma melhor utilização dele.

A segurança também é um grande benefício do Wasm. Os contêineres são bastante seguros, mas há muitas nuances que criam complexidade, principalmente para desenvolvedores. Por padrão, um módulo WebAssembly não pode fazer nada, a menos que você conceda a ele o privilégio de fazê-lo.

O que podemos fazer com Kubernetes e Wasm agora ?

Com tudo isso dito, o que é realmente possível fazer com Wasm e Kubernetes agora? Vamos revisar três dos maiores cenários em que você pode aproveitar o Wasm imediatamente.

runwasi no container CNCF

Uma maneira muito legal de usar o Wasm é verificar o maravilhoso projeto runwasi que faz parte do ecossistema containerd do CNCF. Essencialmente, runwasi permite que você execute um tempo de execução do WebAssembly por meio do containerd shim dentro do Kubernetes. Essa é uma opção muito melhor do que tentar executar o Wasm dentro de um contêiner, já que ele executa o WebAssembly diretamente, exatamente como faria se você girasse um contêiner em um pod.

Malhas de serviço, alguém ?

O Envoy e outras malhas já têm a capacidade de escrever plug-ins usando o WebAssembly. Com eles, você pode escrever filtragem personalizada e outros modelos de plug-in usando qualquer linguagem que compila para WebAssembly.

wasmCloud

Sabemos que as empresas já estão vendo valor em reunir o Kubernetes com o Wasm em vários casos de uso diferentes. Mas o wasmCloud leva isso para o próximo nível devido à sua capacidade de conectar computação diferente em uma topologia de rede plana. Minha segunda demonstração mostrou como é fácil mover o mesmo código em três nós diferentes, cada um em um local diferente. Nesse caso, meu Mac em Pasadena, um cluster Digital Ocean K8s em Nova York e wasmCloud. Sem refatoração, mesmo código, em qualquer local. Em seguida, a plataforma Cosmonic (construída em wasmCloud) trará o tipo de abordagem de serviço completo para Wasm que as empresas precisarão à medida que avançam para a produção.

Quer experimentar o wasmCloud em uma plataforma gerenciada?

Comece a usar a Cosmonic gratuitamente hoje. Lançar agora!

Modelo de componente

Finalmente, e mais emocionante, as coisas estão se movendo rapidamente neste espaço. Confira a palestra WASM I/O de Bailey Hayes e Dan Chiarlone, que mostrou o quão longe chegamos na definição dos padrões WASI e do Modelo de Componente - foi a primeira visão de como realmente queremos que o futuro seja. Você pode acompanhar o progresso aqui e se juntar à Bytecode Alliance para ouvir as últimas novidades.

- Por Taylor Thomas , líder de engenharia da Cosmonic

Se você estiver interessado em aprender mais, tiver dúvidas ou quiser bater um papo, conecte-se conosco no Discord ou no Slack .