A pesquisa anual mais recente da Cloud Native Computing Foundation (CNCF) inclui uma declaração ousada sobre o WebAssembly (Wasm): "Os contêineres são o novo normal e o WebAssembly é o futuro".

Essa declaração pressagia muitas coisas, não apenas sobre o roteiro e desenvolvimento do WebAssembly, mas também sobre seu lugar atual na computação. Segundo a CNCF, 37% das organizações de usuários finais já têm alguma experiência na implantação de aplicativos com o WebAssembly. Embora muitos desses usos sejam para testar os méritos do Wasm, o WasmEdge e o WAMR são os principais runtimes utilizados, de acordo com o relatório da CNCF.

"O WebAssembly é o futuro porque está sendo cada vez mais utilizado para tecnologias de serverless, containerização e plug-ins, e espera-se que tenha um impacto significativo em aplicações web, serverless, jogos e containerização", disse Taylor Dolezal, chefe de ecossistema da CNCF, em resposta por e-mail ao The New Stack.

Mas para onde está indo a adoção do WebAssembly e como será seu roteiro e lugar futuro na computação? Vamos analisar a integração do Wasm e seu futuro em contêineres, edge e outras aplicações, linguagens de programação e serverless.

Futuro Presente

É possível argumentar que o Wasm não é sobre o futuro, mas já é muito presente quando se trata de seu uso em todos os principais navegadores da web para os quais foi originalmente criado. No entanto, embora o Wasm tenha alcançado a maturidade para navegadores, mais trabalho precisa ser feito para seu uso em aplicativos de backend, como seu uso e implantação em dispositivos edge, antes que ele se torne parte do futuro nessa área.

De fato, não é tão simples quanto adicionar o Python ao Wasm e, em seguida, executar o pacote por meio do Wasi, que hospeda o tempo de execução do Wasm. Para aplicativos de backend para os quais o Python é especialmente adaptado, como aprendizado de máquina e análise de dados, sua aplicação em Wasm está muito ligada a uma série de dependências de terceiros que estão apenas agora sendo desenvolvidas e compiladas.

Atualmente, ainda não existe uma oferta ou plataforma de WebAssembly Platform as a Service (PaaS) que possa ser facilmente usada para aplicativos de backend. Em outras palavras, a aplicação do Wasm além do navegador está apenas emergindo.

"Há muito terreno a ser coberto em termos de suporte confiável e eficiente para casos de uso de produção", disse Torsten Volk, analista da Enterprise Management Associates, ao The New Stack. "O que exatamente ainda está faltando descobriremos ao longo do caminho. É aí que projetos de código aberto e fornecedores comerciais entram para fechar essas lacunas e fornecer a melhor experiência possível para desenvolvedores e DevOps".

Distinguindo o WebAssembly do lado do servidor (ss-Wasm) do WebAssembly para aplicativos de navegador, o ss-Wasm tem muito potencial, mas o caminho para a adoção do ss-Wasm é longo e "muito disso ainda precisa ser mapeado", disse Wiqar Chaudry, CEO e fundador da Xymbia, que oferece uma plataforma de colaboração de projetos, ao The New Stack.

"Há duas medidas muito simples para fazer esse caso: Existe uma clara proposta de valor econômico para o Wasm ao criar software? Isso reduz custos, ajuda empresas e desenvolvedores a ganhar mais dinheiro ou ajuda a desbloquear algum outro tipo de valor não realizado?" disse Chaudry, que também está envolvido no projeto Wasmer, atualmente como conselheiro.

"A segunda é sua proposta de valor técnica. Ele atrai desenvolvedores suficientes e resolve dores técnicas suficientes para que eles assumam a sobrecarga de usar o Wasm como parte de sua pilha?"

Conhece WASI?

Atualmente, WASI tem se mostrado como o melhor candidato para estender o alcance do Wasm além do navegador. Descrito como uma interface de sistema modular para WebAssembly, está provando ser apto para ajudar a resolver as complexidades de executar runtimes Wasm em qualquer lugar onde haja uma CPU devidamente configurada - que tem sido um dos principais pontos de venda do WebAssembly desde a sua criação.

"Acredito que o recurso-chave que desbloqueia o WebAssembly como tecnologia de propósito geral é o suporte à Interface de Sistema WebAssembly (WASI)", disse Matt Butcher, co-fundador e CEO da Fermyon Technologies, ao The New Stack. "O WASI permite que os desenvolvedores usem idiomas familiares do sistema em seu código, como abrir arquivos e ler variáveis ​​de ambiente, mas sem comprometer o modelo de segurança do WebAssembly. À medida que o suporte ao WASI se torna generalizado, veremos uma explosão de casos de uso para o WebAssembly."

No entanto, WASI ainda está amadurecendo. "A primeira versão do WASI abriu nossos olhos para o potencial do WebAssembly. A segunda versão, preview 2, será lançada em alguns meses", disse Butcher. "A adição de redes na preview 2 abrirá uma infinidade de novos usos."

O WebAssembly usará componentes e WASI para abstrair bibliotecas de aplicativos comuns em componentes plugáveis comuns, disse Liam Randall, CEO e co-fundador da Cosmonic. Componentes como mensagens de publicação e assinatura ou servidores SQL específicos são entregues aos aplicativos como abstrações em vez de acoplamentos estreitos a bibliotecas específicas, disse ele.

"Quando os contêineres surgiram, eles eram menores, mais rápidos para iniciar e deram aos desenvolvedores uma área de superfície menor para configurar e manter do que as máquinas virtuais", disse Randall. "Os módulos WebAssembly continuam a tendência e são menores, mais rápidos para iniciar e aproveitam componentes para reduzir a quantidade de código que os desenvolvedores escrevem e mantêm.

"Mais importante ainda, o modelo de componente é uma nova metodologia de aplicativo que permite a segurança orientada por capacidade e torna mais fácil para os operadores de plataforma executar aplicativos com segurança."

O uso do Wasm do WASI para APIs de integração de nível de sistema adiciona ainda mais viabilidade como tempo de execução universal, disse Dolezal: "A capacidade do WebAssembly de hospedar código não confiável dentro de um ambiente seguro também é um benefício significativo."

Relacionamento de Contêineres

Os contêineres certamente são a "nova normalidade", especialmente no espaço nativo da nuvem, como disse o relatório do CNCF. O Wasm pode substituir os contêineres em alguns casos de uso, mas, em geral, a adoção do WebAssembly e dos contêineres está configurada para crescer em conjunto.

"Eu realmente acredito que o Kubernetes e o Wasm são produtos complementares, em que um, o Kubernetes, cuida do provisionamento e escalonamento da infraestrutura, enquanto o outro, o Wasm, entrega a aplicação, incluindo sua execução, em cima dessa infraestrutura", disse Volk.

O caminho da adoção do Kubernetes pode servir como um modelo possível para como e quando o Wasm provavelmente verá uma adoção em massa. "O Kubernetes é amplamente adotado porque o acesso ao Kubernetes e às ferramentas para usá-lo, escalá-lo e suportá-lo está amplamente disponível", disse Chaudry. "Veríamos menos adoção e uso se o Kubernetes não estivesse tão prontamente disponível como o AKS, EKS ou GKE. O WebAssembly seguirá a mesma trajetória".

Ele também afirmou que o Wasm só resolve alguns dos problemas que os contêineres resolvem: "Os contêineres são mais complexos e têm um overhead operacional mais alto. Os trade-offs entre os dois tornam plausível que os dois cresçam em conjunto."

Quando o DockerHub começou a oferecer suporte a uma nova especificação de armazenamento de artefatos, a comunidade Wasm percebeu que, em vez de reinventar a roda, agora era possível armazenar runtimes Wasm em registros da Open Container Initiative, como o Docker Hub, disse Butcher.

Neste mês, por exemplo, o Spin 0.8 da Fermyon começou a oferecer suporte a registros OCI. "Embora inicialmente não tivéssemos certeza se os registros OCI seriam o mecanismo de distribuição correto, uma evolução nos padrões combinada com o suporte no Docker Hub mudou nossa opinião", disse Butcher. "Estamos comprometidos em distribuir aplicativos WebAssembly usando registros OCI e podemos fazê-lo hoje."