Wasm: 5 coisas que os desenvolvedores devem estar rastreando

Sabemos que o Wasm funciona bem no navegador. Agora é hora de ficar animado com as possibilidades de Wasm no lado do servidor.

Como o WebAssembly (Wasm) baseado no navegador ganha interesse como uma tecnologia de back-end, os desenvolvedores estão se movendo de “Hmm, que soa interessante” para “Vamos ver o que o Wasm pode realmente fazer além de navegadores, jogos de vídeo e streaming de conteúdo. ”

Ao mesmo tempo, o próprio Wasm está começando a se transformar e mudar. Tudo isso faz com que seja um bom momento para dar outra olhada na tecnologia WebAssembly. Como você avalia Wasm para novos usos, aqui estão cinco coisas que você deve estar tendo em mente.

Interface

Wasm foi originalmente projetado para o navegador, e sem uma interface do sistema para melhorar sua postura de segurança geral. Os autores do Wasm com foco na web original não queriam que os aplicativos pudessem solicitar recursos, da mesma forma que os applets Java são contidos dentro de um navegador.

Os desenvolvedores back-end que utilizam Wasm desejam uma interface que lhes permita portar e utilizar programas já existentes, bem como paradigmas de programação comuns, como Python, Ruby e servidores web. Surge então a WebAssembly System Interface, conhecida como WASI, que consiste em um conjunto de APIs semelhantes ao POSIX que oferecem funcionalidades de sistema operacional, como sistemas de arquivos, rede e criptografia. O WASI possibilita melhorias na execução e portabilidade de softwares pré-existentes, além de facilitar a criação de novos programas escritos com paradigmas já conhecidos, como o uso de arquivos e portas.

Houve um monte de empurrar e puxar entre aqueles que pensam que Wasm deve permanecer puro e aqueles que querem uma interface de sistemas tipo POSIX. Na verdade, é um assunto muito contestado na comunidade a montante. Alguns na comunidade de servidores back-end têm proposto um tipo de compromisso, sugerindo que aqueles que querem usar Wasm como era originalmente pretendido deve fazê-lo, mas que a interface poderia ser adicionado em cima para aqueles que querem. Eu? Acho que WASI é necessário para o lado do servidor ter sucesso.

Desempenho

Em alguns testes de desempenho de referência, Wasm demonstra resultados impressionantes. Embora a execução seja rápida e eficiente, é importante considerar os números de referência com cautela. Por exemplo, no recente teste de benchmark Vercel, o desempenho do Wasm foi notável. Em uma avaliação computacionalmente intensiva na seção de e-digit, o Wasm foi significativamente mais veloz do que Java. No entanto, utilizando o compilador Rust nativo escrito em C, executando em hardware direto, ainda é cerca de quatro vezes mais rápido do que o Wasm. Além disso, em alguns dos outros subtestes Vercel, o Java apresentou uma velocidade muito superior à do Wasm.

Concedido, o desempenho completo de uma aplicação vai ser algum smattering de um número de diferentes benchmarks, mas é importante notar que Wasm não é um slam dunk performance-wise. Isso será especialmente verdadeiro se mais elementos – como WASI – forem colocados no topo da Wasm. Além disso, fique atento para a coleta de lixo, e como isso pode afetar o desempenho.

Segurança

Como mencionado anteriormente, Wasm tem limitações em termos de segurança do sistema. Ao flexibilizá-lo, como ao implementar a interface WASI, você está aumentando as vulnerabilidades. Com a popularidade crescente do Wasm, mais recursos serão adicionados a ele, o que pode resultar em mais oportunidades para erros humanos ou ações maliciosas. A questão da multi-tendência é de particular interesse, pois levanta questões sobre a segurança em comparação com contêineres e máquinas virtuais. Será que o Wasm encontrou um ponto de equilíbrio seguro entre essas duas opções? A manutenção desse equilíbrio entre funcionalidade e segurança é crucial, e os desenvolvedores que consideram ampliar o uso do Wasm precisarão acompanhar e participar desse debate.

Portabilidade

Um dos maiores sorteios da Wasm é a sua portabilidade multiplataforma. Wasm é um formato binário neutro que pode ser empurrado em um recipiente e executado em qualquer lugar. Esta é a chave em nosso mundo de hardware e software cada vez mais poliglota. Os desenvolvedores odeiam compilar vários formatos diferentes porque cada arquitetura adicional (x86, Arm, Z, Power, etc.) adiciona à sua matriz de teste e matrizes de teste explosivas é um problema muito caro. QE é o gargalo para muitas equipes de desenvolvimento.

Com o WebAssembly (Wasm), é possível desenvolver aplicativos, compilá-los uma vez, testá-los e implantá-los em várias plataformas de hardware e software, abrangendo desde a nuvem híbrida, passando pela borda e chegando até o data center e as nuvens públicas. Um desenvolvedor usando um Mac poderia compilar um programa em um binário Wasm, testá-lo localmente e, em seguida, implantá-lo com confiança em diversas máquinas diferentes.

Todas essas máquinas já terão um tempo de execução Wasm instalado neles, uma que é a batalha testada para essa plataforma particular, tornando os binários Wasm extremamente portáteis, muito parecido com Java. E quando você compilar um programa para baixo a esse binário Wasm você pode enviá-lo para um registro do recipiente, puxá-lo para baixo em outra máquina que tem um tempo de execução Wasm, e depois executá-lo em qualquer lugar – se o host é um Mac M1 ou M2, ou um sistema x86, ou qualquer coisa.

Quando você olha como Arm e RISC estão tirando, você percebe que nosso mundo poliglota só vai se tornar mais poliglota nos próximos cinco anos, se não mais cedo. Containers mais Wasm parece uma grande vitória multiplataforma.

Lavagem e Kubernetes

Outra área de debate em torno de Wasm é se os binários Wasm devem ser executados nativamente, ao lado de recipientes, ou dentro de recipientes. A beleza é, não importa, desde que todos adoptemos o formato OCI Container Image. Se você executar um Wasm binário nativamente em um tempo de execução Wasm, ou se esse tempo de execução Wasm é executado dentro de um recipiente OCI (lembre-se, eles são apenas processos extravagantes), você pode criar uma imagem que pode então ser implantada em várias arquiteturas.

Uma única imagem economiza espaço em disco e simplifica o tempo, além de evitar que sua matriz de teste fique fora de controle, como já mencionado anteriormente. Ao executar Wasm dentro de um recipiente, você obtém uma defesa em profundidade com um impacto de desempenho mínimo. Ainda é necessário estudar os benefícios de executar binários Wasm lado a lado com recipientes, porém, de qualquer forma, devemos ser capazes de manter o valor do ecossistema Kubernetes. Agendar recipientes Wasm será simples, pois todos eles serão armazenados em um registro OCI e poderão ser facilmente baixados no Kubernetes (ou Podman ou Docker) para execução.

Conclusão

Sabemos que o Wasm funciona bem no navegador. Agora é hora de ficar animado sobre como Wasm poderia trabalhar no lado do servidor. Eu acho que estamos todos ainda aprendendo sobre o que Wasm pode se tornar, mas em particular, eu estou mais animado com o potencial multi-plataforma. Poderia Wasm, combinado com recipientes, realmente entregar a promessa de portabilidade final? Eu acho que é possível, mas como tecnólogos, teremos que esperar e ver, e guiá-lo para onde precisamos que ele vá.

A lavagem ainda está emergindo – e principalmente não testada – no back-end. Será importante continuar a vigiar o progresso do Wasm e pensar em como pode beneficiar cada uma das nossas organizações. O desempenho será tão bom quanto o metal nu? Será que o Wasm manterá segurança suficiente, mesmo com uma nova interface de sistemas, para permitir multi-tendência? Vamos descobrir juntos ao longo dos próximos meses e anos!

Na Red Hat, Scott McCarty é gerente sênior de produtos para o RHEL Server, indiscutivelmente o maior negócio de software de código aberto do mundo. Scott é um veterano de startup de mídia social, um timer antigo e-commerce, e um tecnólogo de pesquisa do governo intemperado, com experiência em uma variedade de empresas e organizações, de sete startups de pessoas para 12.000 empresas de tecnologia de funcionários. Isso culminou em uma perspectiva única sobre o desenvolvimento, entrega e manutenção de software de código aberto.

Lo siento, pero necesitaría que me proporciones un texto específico para poder parafrasearlo. ¿Puedes darme algo más concreto para trabajar?

O New Tech Forum oferece um local para explorar e discutir tecnologia empresarial emergente em profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na nossa escolha das tecnologias que acreditamos ser importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita garantia de marketing para publicação e reserva o direito de editar todos os conteúdos contribuídos. Envie todas as perguntas para newtechforum@infoworld.com.