WebAssembly sem servidor para desenvolvedores de navegadores

WebAssembly (frequentemente abreviado para Wasm) foi criado para o navegador da web. Mas muitas vezes, uma tecnologia cresce além das intenções dos seus criadores. Wasm é um excelente exemplo. E um lugar onde Wasm se mostra promissor é na nuvem. É uma plataforma fantástica para executar funções sem servidor.

Neste artigo, daremos uma olhada na intenção do design do Wasm e como ele melhorou o navegador. Depois veremos como Wasm deu o salto para uma tecnologia genérica.

Por fim, daremos uma olhada em um problema específico na nuvem – execução de funções sem servidor – e veremos como o Wasm pode resolver esse problema.

Mova-se para miniaplicativos, Flash e Silverlight!

Em 2015, a Mozilla apresentou o WebAssembly ao mundo. Nesta postagem do blog, Luke Wagner descreveu o WebAssembly desta forma:

“WebAssembly… define um formato e modelo de execução portátil, eficiente em tamanho e tempo de carregamento, projetado especificamente para servir como um alvo de compilação para a web.”

O objetivo era construir um formato binário que pudesse ser executado em todos os principais navegadores da web. As características desse formato permitem que muitas linguagens diferentes, de C a Python, sejam executadas no navegador. O código é escrito em uma das linguagens suportadas, compilado no formato Wasm e depois executado no navegador. O código JavaScript controla a execução do Wasm e pode até interagir com o Wasm chamando funções dentro da biblioteca Wasm.

Esta não foi a primeira vez que algo assim foi tentado. Alguns outros idiomas foram adicionados (e posteriormente removidos) do navegador. Os miniaplicativos Java foram os primeiros. O VBScript teve uma vida breve nos navegadores da Microsoft. Silverlight e Adobe Flash também surgiram e desapareceram. Mas desta vez, o pessoal da Mozilla fez algumas coisas de forma diferente:

Em vez de oferecer suporte a uma linguagem, eles definiram um formato binário no qual as linguagens existentes poderiam compilar.

Em vez de seguir sozinha, a Mozilla uniu forças com Google, Microsoft, Apple e outros. E comprometeram-se a fazer o trabalho sob os auspícios do W3C.

Em vez de se concentrar em aumentar a interface do usuário (como Flash, Silverlight e Java fizeram), Wasm se concentrou no uso da biblioteca e no compartilhamento de código.

Os casos de uso que a equipe do Wasm procurou resolver não eram widgets e reprodutores de streaming, mas sim a portabilidade de código de outros locais para o navegador. Por exemplo, considere aquela velha biblioteca C que obedientemente realizou algum trabalho importante durante anos, mas que todos têm medo de tocar por medo de quebrá-la. Isso poderia ser compilado no Wasm para aproveitar o novo uso no navegador? Ou considere aquele problema complexo que exige computação altamente eficiente, como processamento gráfico. Código de alto desempenho pode ser expresso mais facilmente em uma linguagem como Rust. Wasm permite que os desenvolvedores escrevam código na linguagem de sua preferência e, em seguida, use-o dentro dos limites do navegador.

Superando Intenções

Ao longo da história da computação, inventamos tecnologias para resolver um problema restrito, apenas para depois percebermos que a ferramenta tem uma aplicação mais ampla. A internet foi construída para a comunicação do Departamento de Defesa dos EUA. A web era para troca de trabalhos de física. Java era para computação embarcada. JavaScript, hoje a linguagem mais popular do mundo, era inicialmente uma linguagem de “brinquedo” para exibir alertas no navegador. Cada uma dessas tecnologias passou de uma solução de nicho para uma ferramenta de uso geral.

Wasm está naquele momento agora.

Foi bem sucedido no navegador. Mas as pessoas estão encontrando vários outros usos para o Wasm. De conjuntos de ferramentas de compilador a funções definidas pelo usuário em um banco de dados, o Wasm está surgindo em alguns espaços notáveis.

• SingleStore usa Wasm para funções definidas pelo usuário dentro de seu banco de dados.
• O pessoal da linguagem Zig anunciou recentemente que “aniquilou” 80 mil linhas de código C++ usando Wasm para auto-hospedar o compilador.
• Docker anunciou suporte para execução do Wasm dentro do Docker Desktop, enquanto a Microsoft agora oferece suporte para execução do Wasm dentro de clusters Kubernetes.

Mas há um caso de uso que considero particularmente interessante. WebAssembly parece ser uma excelente opção para computação em nuvem. Para entender o porquê, vamos começar examinando uma das principais tecnologias da nuvem atual: funções sem servidor.

Funções sem servidor v1

As funções sem servidor, às vezes chamadas de Funções como Serviço (FaaS), têm como objetivo fornecer uma maneira fácil de criar pequenos serviços em nuvem. É mais fácil entender uma função sem servidor comparando-a com um servidor. O software do servidor Web escuta solicitações HTTP em um soquete, analisa cada solicitação e, em seguida, trata as solicitações. Durante a vida útil do processo de um servidor web, ele pode lidar com centenas de milhares de solicitações HTTP separadas. O servidor HTTP típico também deve gerenciar conexões SSL, processos do sistema, pooling e simultaneidade de threads e uma variedade de outras tarefas de nível inferior, todas a serviço do atendimento de solicitações HTTP.

Uma função sem servidor é projetada para eliminar o máximo possível dessa “servidor”. Em vez disso, o desenvolvedor que escreve uma função sem servidor deve ser capaz de se concentrar em apenas uma coisa: responder a uma solicitação HTTP. Não há rede, configuração SSL e gerenciamento de pool de threads de solicitação – tudo isso é gerenciado pela plataforma. Uma função sem servidor é iniciada, responde a uma solicitação e depois é desligada.

Esse design compacto não apenas reduz a quantidade de código que precisamos escrever, mas também reduz a complexidade operacional da execução de nossas funções sem servidor. Não precisamos manter nossas bibliotecas HTTP ou SSL atualizadas, porque não gerenciamos essas coisas diretamente. A plataforma sim. Tudo, desde o tratamento de erros até atualizações, deveria ser — e, de fato, é — mais fácil.

Dado esse foco incansável na simplicidade, não é de admirar que 4,2 milhões de desenvolvedores afirmem ter escrito pelo menos uma função sem servidor. A Amazon relata que eles executam 10 trilhões (sim, isso é 10 trilhões!) funções sem servidor por mês.

Por mais atraente que seja o paradigma de programação, as primeiras iterações de funções sem servidor sofreram de várias desvantagens. Eles demoraram para começar. A experiência de empacotar uma função sem servidor e implantá-la foi complicada. A depuração e a solução de problemas foram difíceis. No entanto, a razão por detrás destes problemas é ao mesmo tempo fácil de compreender e surpreendente.

Essa nova ideia brilhante de funções sem servidor estava sendo executada na pilha de tecnologia errada – máquinas virtuais pesadas. Tempos de execução e gerenciadores de pacotes por linguagem. A infraestrutura em nuvem construída para uma classe diferente de computação estava sendo reaproveitada para uma tecnologia para a qual, em retrospectiva, era inadequada.

Acontece que a tecnologia de que precisávamos para transformar o sistema sem servidor de bom em ótimo estava no navegador. Só precisávamos extrair o Wasm de lá e plantá-lo na nuvem.

O que Wasm faz sem servidor

Se estivermos tentando melhorar o estado das funções sem servidor, existem alguns bits de alta prioridade que precisam ser melhorados. Precisamos que o ambiente sem servidor seja extremamente rápido e ultra seguro e queremos que ele oculte o máximo possível dos detalhes do “servidor”. Ou seja, no momento em que começarmos a pedir aos usuários que escolham o sistema operacional ou o tipo de CPU, estaremos forçando o usuário a tomar decisões sobre o servidor, em vez de decisões sem servidor. E quando se trata de implantar funções sem servidor, binários menores em formatos de pacote bem definidos tornam muito mais fácil fazer lançamentos.

É aqui que a herança do Wasm o torna perfeito para funções sem servidor. Quando falamos sobre o Wasm como “construído para o navegador”, estamos realmente falando sobre alguns recursos principais que tornam o Wasm uma boa opção para o modelo de navegador:

• Tempo de inicialização rápido. Ninguém quer esperar o carregamento de uma página.
• Arquitetura cruzada, sistema operacional cruzado. Já se foi o tempo em que “o Internet Explorer é necessário para visualizar esta página”.
• Binários compactos. Quando movemos nosso código pela Internet, não queremos enviar arquivos grandes.
• Caixa de areia segura. Um navegador executa código não confiável diariamente. Contamos com o navegador para nos proteger contra bugs e hackers.

Acontece que esses quatro recursos são características desejadas para uma plataforma de funções sem servidor. Queremos um tempo de inicialização com latência zero. Não queremos saber nem nos preocupar com a arquitetura ou sistema operacional no qual nossa função é executada. (Essa é a alegria de ser sem servidor, certo? Não precisamos nos preocupar nem um pouco com o servidor subjacente!) Queremos que nossos binários sejam compactos para que possamos empacotá-los e carregá-los rapidamente. E queremos saber se é seguro executar nossa função em uma nuvem multilocatária.

Uma plataforma de funções sem servidor executada em Wasm facilitaria a construção de uma grande variedade de aplicativos, incluindo aplicativos HTTP altamente responsivos, e a implantação deles com alto grau de confiança. Este é exatamente o caso de uso que nós da Fermyon tínhamos em mente quando construímos a estrutura Spin de código aberto.

Conclusão

Muitas de nossas tecnologias essenciais começaram em um nicho e se transformaram em ferramentas de uso geral. O Wasm está passando por essa transição agora, à medida que encontramos novos aplicativos além do navegador da Web. As funções sem servidor já tiveram muito sucesso. Mas para avançar, a tecnologia precisa de bases mais rápidas e robustas. Wasm é exatamente uma dessas tecnologias.

A postagem WebAssembly sem servidor para desenvolvedores de navegadores apareceu pela primeira vez em The New Stack.