Evolução dos Padrões Wasm: Construindo o Modelo de Componentes

Há vários novos esforços de padronização ocorrendo no espaço WebAssembly (Wasm), incluindo o que acreditamos ser uma nova maneira de escrever aplicativos de software. Ao descrever este novo modelo, gostaria de mergulhar em um pouco da história do Wasm como uma forma de descrever para onde estamos indo.

O design do WebAssembly (Wasm) começou em 2015, anos antes de se tornar oficialmente a 4ª linguagem da web em 2019. Embora muitos tecnólogos estejam familiarizados com o Wasm como uma tecnologia de navegador, o próprio Wasm não depende de JavaScript ou APIs da web.

O precursor de Wasm, asm.js , ganhou destaque em 2013. Um subconjunto de JavaScript altamente otimizável para navegadores e que pode atuar como um destino de compilação para linguagens como C e C++. Uma das minhas palestras favoritas de todos os tempos, “The Birth & Death of JavaScript” cobre um futuro fictício inspirado em asm.js Observe as semelhanças entre o futuro que finalmente pavimentamos com as previsões de Wasm e Gary assistindo a sua palestra na PyCon 2014.

Costumo chamar asm.js de o maior hack de todos os tempos (da maneira mais amorosa). Quem teria pensado que uma linguagem de script de alto nível poderia ser A")" um alvo de compilação e B")" tão incrivelmente rápido? Em 2012, portei várias bibliotecas C++ para asm.js e senti que havia desbloqueado o código secreto para um universo portátil.

A tecnologia provou várias coisas. Primeiro, existe a necessidade e o desejo de trazer outras linguagens para a web, mas os desenvolvedores não queriam parar por aí. Os tipos de aplicações portadas eram computacionalmente e graficamente exigentes, desde ferramentas de visualização de dados (como os componentes em que trabalhei no SAS) até jogos construídos com Unity e Unreal Engine (UE3 foi portado em 4 dias ).

É por isso que, quando o grupo da comunidade W3C WebAssembly e o repositório de design WebAssembly correspondente foram criados em 2015, fornecedores de navegadores como Mozilla, Google , Microsoft e Apple estavam entre os primeiros contribuintes para o esforço e os primeiros a ver uma oportunidade tangível. O projeto exigia uma linguagem com um formato binário que pudesse ser usado como um destino de compilação portátil, otimizado para tamanho para permitir downloads rápidos e suporte para compilação de streaming que permite que o módulo baixado tenha instanciação quase instantânea. Mais importante, esses módulos devem facilitar [ambientes de execução] sandbox como qualquer código arbitrário executado em navegadores deve.

Por que estava além do navegador ?

Muito do que foi aprendido nas implantações do lado do navegador forneceu pistas sobre as várias maneiras pelas quais o Wasm poderia realizar seu potencial além do navegador. A “nuvem” compõe um conjunto heterogêneo de arquiteturas de computação, sistemas operacionais e restrições de sistema em uma rede mundial de máquinas.

Considere algumas das principais propriedades do Wasm como um destino de compilação portátil que é rápido, sandbox e facilmente distribuído graças ao formato binário compacto. Essas propriedades do Wasm o tornam a unidade de computação distribuível perfeita para a nuvem. Além disso, as empresas desejam criar aplicativos para diferentes ambientes, mas não querem refatorar todas as vezes. Wasm remove essas barreiras.

Quando soube do asm.js , estava em busca de uma solução para levar nosso aplicativo Flash existente para HTML5. Este aplicativo ActionScript/Flex foi uma versão reescrita de sua contraparte Java, que era uma porta de versões anteriores da mesma lógica de negócios escrita em C. Esta história pode parecer louca para você se você não trabalhou em grandes empresas, mas você pode encontrar esse tipo de portabilidade entre cada época da computação em todas as organizações que tiveram a sorte de sobreviver ao teste do tempo.

O Wasm permite total portabilidade para qualquer tempo de execução compatível com Wasm, incluindo navegadores, tempos de execução criados especificamente para FaaS ou algo projetado para ser executado em pequenas arquiteturas para IoT. Na web, os módulos Wasm são capazes de usar o código “cola” JavaScript para acessar APIs da web como WebGL, rede e dispositivos para fazer coisas além da computação pura. No final das contas, um programa Wasm realmente só opera em valores numéricos, ou dito de outra forma, um módulo Wasm é um monte de i32s em um sobretudo. Para fazer coisas interessantes, um módulo Wasm precisa ser capaz de chamar funções do tempo de execução do host.

WASI: a fronteira do Wasm do lado do servidor

Na mesma época em que o WebAssembly 1.0 se tornou um padrão da Web recomendado, um novo subgrupo dentro do grupo de trabalho W3C WebAssembly foi criado para explorar uma interface de nível de sistema para WebAssembly conhecida como WASI (WebAssembly Systems Interface). O grupo tem trabalhado na criação de um conjunto de interfaces padronizadas desde então.

O WASI existe para fazer o WebAssembly funcionar bem em qualquer lugar, não apenas no navegador, mas o principal recurso definidor do WASI é seu modelo de segurança baseado em capacidade. A segurança baseada em capacidade existe desde os anos 60 ( Dennis & Van Horn, 1966 ), mas Dan Gohman arquitetou uma nova visão disso com base nas ideias do Cloud ABI .

Compreensivelmente, essa tecnologia logo atraiu a atenção de empresas interessadas em executar o Wasm fora da web. Empresas como Fastly, Intel, Red Hat e Mozilla viram uma chance de colocar o Wasm para trabalhar na nuvem, em dispositivos e na borda. Essas empresas foram os membros fundadores da Bytecode Alliance (BA), uma organização sem fins lucrativos para construir bases de software seguras para Wasm usando padrões como WASI. Muitas outras organizações logo se juntaram à BA, incluindo os principais players da indústria de software e agora ela tem mais de 30 membros e está crescendo!

Nos últimos dois anos, fizemos um grande progresso na criação das ferramentas necessárias para executar o Wasm em aplicativos nativos da nuvem . A comunidade aprendeu muito com essas primeiras experiências e isso nos influenciou a criar um novo padrão que agora chamamos de Modelo de Componentes. O Modelo de Componente está em um nível inferior ao WASI, funciona bem com o WASI, mas não depende do WASI. Este é o resultado de nossa visão de um ecossistema de software que não se baseia apenas em uma unidade portátil de computação, mas algo totalmente novo com módulos WebAssembly combináveis, interoperáveis ​​e virtualizáveis ​​de plataforma.

Vamos quebrar isso:

• Capacidade de composição: permite a reutilização de código modular de maneira independente da linguagem.

• Virtualização de plataforma: a capacidade de colocar em camadas as peças específicas da plataforma que um componente precisa para executar em um determinado ambiente. Uma proposta anterior para o recurso de virtualização e capacidade de composição da plataforma era chamada de vinculação de módulos.

• Interoperabilidade: com componentes que podem ser compostos e virtualizados, precisamos de uma maneira de trocar informações entre os componentes. Começamos com uma proposta chamada tipos de interface, mas agora também é uma característica chave da proposta de modelo de componente.

  
  

Esta é a história de como o Modelo de Componentes começou a tomar forma. Cada uma das propostas anteriores foi agora refinada neste padrão abrangente. Esperamos ver a próxima grande iteração estável dos Padrões WASI e do Modelo de Componentes ainda este ano.

Padrões WASI - onde estamos agora ?

Abaixo, nós o levamos através de uma história plotada de Wasm, WASI e o desenvolvimento do Modelo de Componente.

2019 : Alvo de compilação puro, adicionando interfaces iniciais que conectam syscalls ao host. Em muitos aspectos, parecia que estávamos caminhando para uma versão WebAssembly do POSIX. Conseguimos escrever uma CLI realmente simples e executá-la com o Wasmtime em uma área de trabalho ou em uma função sem servidor.

2020 : As APIs WASI são focadas nos tipos de coisas que qualquer programa CLI pode precisar, por exemplo, relógio do sistema ou um sistema de arquivos. O tempo de execução Lucet Wasm da Fastly se fundiu com o Wasmtime (um projeto BA).

2021 : Claro, todos esses elementos continuam a evoluir e melhorar. Em 2021, começamos a ver o desenvolvimento de novas interfaces WASI específicas de casos de uso, por exemplo wasi-nn para quando a aceleração de hardware é necessária para inferência. Este também é o ano em que Luke Wagner começou a definir o Modelo de Componentes.

2022 : começamos a ver novas APIs de nível superior para fazer com que os módulos Wasm funcionem bem em ambientes de nuvem, onde recursos como trabalhar com um armazenamento de valor-chave ou serviços de mensagens pub/sub são necessários. Finalmente, depois de muito trabalho, os soquetes WASI foram introduzidos. 2023 : Estamos trabalhando para alcançar marcos de estabilidade para o modelo de componente e os padrões WASI.

Olhando para a jornada de 2019, você pode começar a ver como os padrões se diversificaram à medida que os casos de uso proliferaram e os usuários começaram a escolher o que precisam e o que não precisam. De um bloco onipresente a um conjunto crescente de blocos de construção menores projetados para operar uns com os outros dentro de uma estrutura flexível: o Modelo de Componentes.

O que é o Modelo de Componentes ?

Nesse modelo, os desenvolvedores podem escolher partes de seu aplicativo, implementadas em diferentes linguagens, como diferentes proposições de valor. À medida que os desenvolvedores começam a criar bibliotecas de componentes Wasm, outros desenvolvedores podem tratá-los como a maior caixa de 'LEGO' do mundo.

Em um momento de círculo completo, acreditamos que novas inovações surgirão quando o Modelo de Componentes começar a influenciar a maneira como escrevemos aplicativos da web. Isso faz sentido quando se considera que a web é um daqueles ambientes legais, mas restritos, com usuários muito impacientes - um terreno fértil para novos experimentos.

Por exemplo, espero que os componentes facilitem ainda mais o design de um sistema de plug-in de idioma neutro para um aplicativo da Web. Se houver uma peça necessária para um tempo de execução de linguagem como o Python, vários componentes que aproveitam esse tempo de execução de linguagem podem usá-lo. Compare isso com o mundo de hoje, onde temos apenas módulos Wasm (não componentes) e estes são normalmente construídos com todas as suas dependências de tempo de compilação em um único binário. Se um aplicativo grande oferecer suporte a plug-ins de terceiros, é provável que cada plug-in Wasm tenha dependências duplicadas, levando a um aumento de tamanho e memória e downloads mais lentos.

Com um futuro sistema de componentes Wasm para a web, onde um único aplicativo pode ter sua escolha de componentes escritos em qualquer idioma, um aplicativo precisará apenas baixar exatamente o que precisa e interagir com componentes como qualquer outro módulo ES com uma importação. Neste mundo, o melhor componente chegará ao topo. O melhor pode significar a API mais rápida ou mais limpa, mas o mais importante é que sua característica definidora não será o idioma de origem. Que vença o melhor componente!

Construindo uma base técnica estável para WASI e componentes

Uma grande parte de tornar os padrões WASI e o Modelo de Componente reais é o papel que o BA desempenha na criação de uma estrutura técnica utilizável: os SDKs, ferramentas e componentes principais; todos construídos de forma consistente e segura e acessíveis a todos como exemplos de boas práticas.

Da mesma forma, o papel do Comitê Diretivo Técnico (TSC) da BA será crítico no fornecimento de governança técnica e suporte para todos os projetos da BA. Trabalhamos ao lado do pessoal que projeta o melhor conjunto de padrões possível nos grupos de trabalho W3C WebAssembly e WASI, o que significa que colaboramos com eles para garantir que tudo funcione na prática. Os grupos W3C WebAssembly e WASI estão focados na finalização desses padrões, e o BA está focado em torná-los consumíveis dentro da comunidade o mais rápido possível para estabelecer um ciclo de feedback ativo.

Outra parte importante do estatuto da BA é permitir a interoperabilidade de linguagem e ambiente. O BA fornece ferramentas para gerar ligações de idiomas para muitos idiomas diferentes, mas um aspecto de como alcançar o nirvana de interoperabilidade de idiomas é que precisamos de registros e gerenciadores de pacotes em vários ecossistemas de idiomas para interoperar com componentes Wasm. É por isso que estamos trabalhando na criação de um protocolo de registro (chamado warg) como parte do SIG-Registries que permite que qualquer registro que implemente o protocolo publique, consuma, armazene e compartilhe componentes Wasm.

Talvez a parte mais crítica de qualquer pilha de software Wasm seja o tempo de execução do Wasm, e o BA hospeda dois! Wasmtime é escrito em Rust e geralmente é a plataforma de teste para experimentar novas propostas WASI e WebAssembly. O WebAssembly Micro-Runtime ( WAMR ) é escrito em C e suporta muitas arquiteturas, incluindo as minúsculas como ESP32. Ambos os tempos de execução atuam como ótimas implementações de referência de um tempo de execução Wasm. Os SDKs e as ferramentas para construir um módulo Wasm estão alinhados com os padrões Wasm, portanto, qualquer tempo de execução Wasm compatível com os padrões (incluindo aqueles não hospedados pelo BA) pode ser construído sobre essas bases de software.

Considerando todos os novos e empolgantes padrões que evoluem por meio do WASI e do Modelo de Componente e das implementações da Bytecode Alliance, espero que 2023 seja um ano empolgante!

Comece a usar a Cosmonic gratuitamente hoje: Inicie agora!

Por Bailey Hayes | Diretor da Bytecode Alliance TSC e Cosmonic