O que o WebAssembly significa para o servidor e GenAI?

Solomon Hykes, um dos cofundadores do Docker foi citado dizendo “Se WASM+WASI existisse em 2008, não precisaríamos criar o Docker. Isso é o quão importante é. WebAssembly no servidor é o futuro da computação.”

Em uma postagem anterior do blog “WASM, seu caminho para a nuvem”, explorei o que Wasm significava para arquiteturas nativas de nuvem, juntamente com algumas informações básicas sobre a história e quando ele entrou no chat para nuvem. Agora, pretendo explorar por que o Wasm é importante para o servidor.

É claro que isso pode significar muitas coisas, incluindo por que a pegada e o desempenho dos aplicativos Wasm são importantes, por que isso é importante para a IA generativa e como os aspectos de segurança e multiarquitetura são essenciais para um servidor mais feliz. Vamos mergulhar.

As belas qualidades do WASM

Wasm oferece benefícios conceituais semelhantes aos contêineres. Os binários Wasm são multilíngues, portáteis, de alto desempenho e seguros. Essas características entusiasmaram a indústria de tecnologia quando contêineres e micronúcleos entraram em cena na última década. Vamos explorar por que essas características dos aplicativos Wasm representam uma nova onda de entusiasmo.

Portabilidade

A portabilidade permite que um aplicativo seja implantado, movido e transferido entre ambientes, o que é fundamental para as arquiteturas multicloud e multicluster atuais. Wasm alcança portabilidade oferecendo um formato binário que permite que o código seja executado em uma variedade de arquiteturas. Esta é uma área onde vale a pena distinguir entre a portabilidade do Wasm e a compatibilidade de contêineres. Com imagens de contêiner, o tipo de arquitetura de CPU, distribuição e versão de um sistema operacional são importantes. Por exemplo, se você quisesse construir um contêiner para uma arquitetura de sistema específica, você teria que invocar o método --platform sinalizador no processo de construção e marque-o adequadamente para cada arquitetura na qual você gostaria de executar o contêiner.

Os sistemas operacionais também são levados em consideração. Por exemplo, não há como executar contêineres do Windows no Linux sem virtualização porque os contêineres do Windows precisam do kernel específico do Windows, do host Hyper-V ou do suporte ao serviço de computação de host (HCS). Esta é uma das áreas onde Wasm tende a brilhar. Os aplicativos Wasm são compostos de “módulos” (consulte Modelo de componente WebAssembly), e esses módulos são compilados em um bytecode (formato binário). Este formato binário o torna muito mais portável do que linguagens específicas como JavaScript, Python ou Rust.

Exemplo de aplicação WASM

Usaremos uma estrutura de aplicativo Wasm da Fermyon chamada spin para ajudar a demonstrar isso. Fermyon lançou recentemente o SpinKube durante a KubeCon EU Paris 2024 como um projeto sandbox da Cloud Native Computing Foundation (CNCF). Ele pode permitir praticamente o mesmo caso de uso que mostraremos aqui; verifique isso separadamente. Spin aproveita o modelo de componente junto com o tempo de execução Wasmtime. Wasmtime usa o módulo de componente junto com WebAssembly System Interface (WASI), que permite que aplicativos Wasm sejam executados no servidor em vez de na web. WASI fornece acesso a recursos do sistema operacional, como sistemas de arquivos, redes e muito mais, de maneira semelhante ao POSIX.

Este exemplo mostrará como construir um aplicativo Wasm baseado em Rust produzindo o .wasm binário usando o alvo Wasm + WASI do Rust wasm32-wasi e simplesmente executá-lo no Ubuntu Linux 23.10 e no Windows 11 sem modificação.

> Observe que não entraremos no ambiente Spin and Rust completo aqui. Para obter mais informações, confira o início rápido do Spin ou experimente você mesmo neste laboratório.

Primeiro, o aplicativo Rust é definido como um manipulador e resposta HTTP simples.

Em seguida, adicionamos o alvo Rust Wasm+WASI ao ambiente de desenvolvimento.

A seguir, construa o .wasm binário.

Isto produz o .wasm binário na pasta de compilação de destino.

Agora podemos executar o módulo Wasm no servidor Ubuntu.

Em seguida, acesse o aplicativo, que fornece uma resposta HTTP simples.

Em seguida, carregue nosso módulo Wasm no repositório de pacotes GitHub (ghcr).

Agora em nossa área de trabalho do Windows 11, podemos executar o módulo Wasm do PowerShell com um comando sem qualquer modificação nas plataformas.

Eu quero ser claro; este exemplo simplista não é totalmente diferente da execução de código no Linux e no Windows. Porém, mesmo com este exemplo simples, não houve necessidade de instalação de nenhuma dependência específica de aplicativo ou biblioteca, apenas o Spin, que sabe como executar os binários Wasm, já que não precisamos reconstruí-lo. Este exemplo é realmente para destacar a portabilidade e a utilidade do formato binário no Linux e no Windows; as aplicações podem, obviamente, tornar-se mais complexas.

Segurança

O Wasm melhora a segurança geral e a pegada do vetor de ataque, executando cada módulo do Wasm em seu próprio ambiente de área restrita, isolado do tempo de execução do host. Isso significa que um aplicativo Wasm em execução não tem visibilidade para o sistema operacional host fora de como o tempo de execução e quaisquer recursos do sistema só podem ser acessados ​​por meio do WASI.

Wasm também fornece um conceito de memória linear que fornece uma matriz contígua de memória com um tamanho máximo. Esta é uma região de memória isolada para uso do módulo Wasm. O uso indevido dessa memória pode causar a ocorrência de traps (exceções) que são relatadas na pilha no tempo de execução. Isso fornece vários aspectos de segurança de memória para a região isolada de memória disponível para o aplicativo em comparação com a memória disponível no tempo de execução, o que ajuda a evitar, mas não a eliminar, certos bugs de segurança de memória, como buffer overflows e ponteiros inseguros. A maioria dos detalhes está além do escopo deste artigo.

Wasm é um projeto em rápida evolução e, à medida que as especificações e a implementação crescem ao longo do tempo, isso não elimina possíveis bugs ou preocupações de segurança em tempos de execução; no entanto, o design do Wasm para isolamento e sandboxes configura positivamente a postura geral de segurança.

Desempenho

Wasm também oferece um desempenho impressionante, e isso é importante porque mesmo que algo fosse hiperportátil se não fosse um mecanismo de computação eficiente, não seria tão útil. Wasm é inerentemente mais compacto do que alternativas em navegadores como JavaScript. Isso ocorre porque o Wasm é compilado em um binário contendo bytecode em vez de algo como JavaScript, que é interpretado. O resultado, por exemplo, é que um aplicativo Rust nativo integrado em um contêiner pode ser muito maior e mais lento na inicialização do que um módulo binário Wasm baseado em Rust.

Confira a diferença de tamanho deste módulo Wasm do servidor HTTP Rust em comparação com um contêiner que faz a mesma coisa construído a partir da imagem ferrugem:1.77.

Módulo Rust Wasm

Usando a imagem do contêiner ferrugem:1.77:

Usando a imagem do contêiner ferrugem:1.77-slim:

Usando a imagem do contêiner ferrugem:1.77-slim:

Existem maneiras de usar compilações de vários estágios ou imagens de rascunho para obter tamanhos de imagem menores e reduzir o tamanho para dezenas de MB; no entanto, provavelmente não será assim que muitos desenvolvedores começam. Deve-se notar que usando essas técnicas, poderíamos produzir uma imagem muito menor abaixo, porém, ela ainda é cinco vezes maior que o binário Wasm sozinho

Usando a construção de vários estágios com imagem de contêiner ferrugem:alpine:

A memória linear também torna o acesso à memória geralmente mais eficiente, juntamente com outros aspectos, como threads paralelos para aumentar o consumo de CPU. O desempenho é e será uma característica importante de aplicações executadas em nuvens públicas e privadas, incluindo casos de uso como serverless e IA.

O que isso significa para o servidor

Portabilidade, segurança e desempenho explicam por que a tecnologia de contêiner Linux prosperou nas arquiteturas de data center atuais, e o Wasm pode estender esses benefícios para aplicativos além do navegador executado no servidor. Vejamos alguns exemplos.

Aplicativos em nuvem

Os aplicativos Wasm que usam estruturas para o servidor, como WASI, Wasmtime e WasmEdge, podem se beneficiar de muitas das mesmas cadeias de ferramentas de desenvolvedor que os contêineres usam como rampa de acesso, como mostramos acima. Isso significa que há uma progressão natural para as equipes de desenvolvimento começarem a experimentar o Wasm no servidor. Usar as ferramentas nativas da nuvem existentes não é a única maneira de executar aplicativos Wasm, mas torna mais fácil para as equipes que desenvolvem aplicativos baseados em nuvem com contêineres e Kubernetes começarem a implementar módulos Wasm. A portabilidade e o desempenho desses módulos Wasm também podem melhorar a densidade e os tempos de início das aplicações.

Edge, IoT e sem servidor

O formato dos aplicativos Wasm, sendo portáteis e pequenos, os torna ideais para cargas de trabalho computacionais descentralizadas na borda. Os aplicativos Wasm ocupam menos espaço, o que é perfeito para muitos casos de uso de borda e Internet das Coisas (IoT) que lidam com capacidade computacional limitada. O desempenho e os tempos de inicialização rápidos dos binários Wasm também o tornam um candidato ideal para computação sem servidor, onde a inicialização a frio pode ser minimizada para funções sem servidor.

IA generativa

GenAI e seus casos de uso estão rapidamente se tornando uma das tecnologias mais focadas na maioria das empresas e com razão. GenAI tem muitos casos de uso atraentes e tem havido muito trabalho recente nas comunidades nativas da nuvem e do Kubernetes, bem como na empresa, para permitir cargas de trabalho de IA para os consumidores.

Se você quiser se aprofundar, dê uma olhada nisso guia de design como um exemplo.

GenAI possui várias arquiteturas e componentes dependendo do caso de uso, porém muitas dessas pilhas compartilham componentes comuns.

Dois componentes principais da pilha GenAI são modelos como Llama 2, Mistral, GPT-4 e outros que rodam em GPUs junto com os componentes de inferência, que lidam com a comunicação com um modelo e lidam com solicitações de inferência. Inferência é a tarefa operacional que executa dados por meio de um modelo para concluir uma tarefa.

Por exemplo, se você fizer uma pergunta como “Conte-me uma piada sobre cachorros” ao ChatGPT da OpenAI, ele pegará a pergunta e executará uma etapa de inferência para fornecer uma resposta.

As etapas de inferência são um exemplo em que o Wasm pode se encaixar perfeitamente. Veja este exemplo do Fermyon usando sua estrutura Spin, onde os módulos Wasm são usados ​​em uma arquitetura sem servidor. O exemplo de aplicativo Wasm pode ser definido como:

Isso mostra como o Wasm pode ser usado na estrutura Spin e na nuvem. Você pode ler sobre isso aqui para saber como aproveitar as vantagens do pequeno espaço ocupado, do desempenho e da segurança do Wasm significa melhorias na densidade, possíveis otimizações de custos e casos de uso mais amplos para onde os módulos Wasm e a IA podem ser executados na borda. O Wasm também pode ser considerado um tempo de execução universal para a implantação de componentes de IA, tornando mais fácil para pesquisadores e desenvolvedores executar modelos por meio de tempos de execução do Wasm que são altamente portáteis.

Conclusão

Wasm para o servidor, na minha opinião, veio para ficar para o servidor e crescerá nos próximos anos. A portabilidade, o desempenho e a segurança que a indústria adora nos contêineres se estendem à arquitetura e à implantação de aplicações WebAssembly no servidor. Com o suporte crescente do Wasm na cadeia de ferramentas do ecossistema nativo da nuvem e as conexões óbvias com casos de uso como edge, IoT, serverless e GenAI, não há dúvida de que o Wasm será importante para o servidor.

A postagem O que WebAssembly significa para o servidor e GenAI? apareceu primeiro em The New Stack.