4 fatores de um mundo nativo do WebAssembly

WebAssembly, abreviado para Wasm, nos oferece uma oportunidade incrível de repensar a maneira como projetamos e operamos a computação que vai além da nuvem e sem servidor. Com o WebAssembly, podemos finalmente chegar a uma abordagem pura de “tarefas a serem realizadas” para a computação. Esta foi a promessa do serverless que nunca foi concretizada.

Quando introduzido pela primeira vez, o serverless prometia executar funções e lógica enquanto abstraía toda a complexidade. Infelizmente, o serverless rapidamente se afastou dessa visão pura. Embora fosse possível usar um serviço sem servidor como o AWS Lambda, os desenvolvedores e as equipes de plataforma que buscavam o DIY sem servidor se depararam com a difícil realidade de implantar, ajustar e manter uma pilha complicada e um conjunto de infraestrutura de suporte necessária para funcionar em escala.

O Serverless deveria cumprir todas as promessas que queríamos do WebAssembly, mas não funcionou dessa maneira. Muitos provedores de nuvem e sem servidor construíram suas pilhas com base em correções proprietárias, limitando a portabilidade e forçando os usuários a escrever funções que funcionassem apenas em uma plataforma. A multicloud sem servidor tornou-se um desafio, minando uma das principais propostas de valor da convenção arquitetônica.

Em teoria, o serverless deveria ser altamente orientado a eventos e, portanto, econômico, invocado apenas quando necessário. Na prática, o escalonamento imprevisível e o planejamento de recursos desafiador muitas vezes se traduziam em contas crescentes sem servidor. Os clientes foram cobrados pelos provedores de nuvem por partidas lentas a frio, embora as partidas a frio tenham se acelerado e custado menos ultimamente. Mais criticamente, as complexidades do gerenciamento da lógica sem servidor forçaram as equipes de DevOps a criar conjuntos inteiramente novos de ferramentas e a gerenciar ativamente algo que deveria ser uma simplicidade de “deslocamento para a esquerda”.

Grande parte da comunidade WebAssembly do lado do servidor considera o WebAssembly um refazer sem servidor (veja “A Reckoning for Serverless” de Fermyon): uma chance de reconstruir sem servidor do zero. Os riscos permanecem, mas a influência das mesmas forças que corromperam o serverless permanece forte. O que é necessário para garantir que o WebAssembly não termine como redux sem servidor? Aqui estão quatro princípios fundamentais para mantê-lo no caminho certo.

Agnóstico Ambiental

Ser ambientalmente agnóstico tem sido a promessa de longa data dos contêineres e de outras camadas de abstração. O WebAssembly pode realmente acertar porque o tempo de execução está operando em um nível baixo. E como foi originalmente projetado para ser executado em um navegador (uma construção que pode literalmente ser executada em qualquer lugar e em qualquer coisa), o WebAssembly foi projetado para ser um ambiente. Isso lhe dá uma vantagem em relação a outras tentativas anteriores de tecnologias 100% portáteis, nenhuma das quais realmente correspondeu à promessa.

A parte crítica de seguir esse princípio é projetar padrões de conformidade fortes para que o mecanismo e os recursos principais do tempo de execução do WebAssembly permaneçam os mesmos e possam ser abordados de forma semelhante em hardware, nuvem, redes de entrega de conteúdo, computação de borda, IoT e nos dispositivos do usuário.

Abstrações que os desenvolvedores podem adorar

O WebAssembly não tem nenhuma opinião sobre rede, armazenamento ou dados, e isso é realmente bom. Não procure além do POSIX por motivos para manter o WebAssembly puramente computacional. Originalmente criado como uma forma de tornar os sistemas operacionais mais interoperáveis, o POSIX evoluiu para uma camada de abstração altamente opinativa que avaliava segurança, escalabilidade, compatibilidade de API e muito mais.

Subjacente ao POSIX está o conceito de sistema de arquivos, que se tornou uma grande barreira para o redesenho das arquiteturas de computação para a era distribuída. Isso nos mantém trancados na estrutura conceitual de arquivos e diretórios.

O modelo de componente WebAssembly proposto promete fornecer um conjunto de abstrações que são mais apropriadas para aplicações modernas e disponíveis estritamente opcionalmente. Os arquivos ainda estarão lá quando necessários, mas soluções de armazenamento nativas em nuvem, como valores-chave e objetos simples, serão fornecidas por meio de interfaces implementadas pelo tempo de execução ou outro módulo Wasm.

Plugins como cidadãos de primeira classe

Este é um claro corolário do primeiro princípio. Em todos os outros paradigmas de computação e tempo de execução, opiniões fortes e suporte integrado para redes, dados e outros elementos significam que os plug-ins (também conhecidos como extensões) são corretamente percebidos como riscos de segurança. Por esta razão, raramente lhes é concedido o estatuto de mais privilegiados. Isso significa que os desenvolvedores que buscam adicionar funcionalidades por meio de plug-ins geralmente enfrentam bloqueios de desempenho e dimensionamento devido a suposições e mecanismos incorporados projetados para proteger o tempo de execução principal e as funcionalidades de computação contra agentes mal-intencionados.

Como o WebAssembly é ingênuo e uma folha em branco, extensões e plug-ins podem ser o mecanismo principal para todos os tipos de funcionalidade. Eles irão, por padrão, operar a partir de um ponto de partida altamente seguro e com menos privilégios. Ao manter esse status de acesso total e recursos totais para plug-ins, é mais provável que o WebAssembly incentive o desenvolvimento de ecossistemas robustos de plug-ins que darão à comunidade a mais ampla seleção de integrações e recursos.

Mantenha os dados brutos

Devido às suas origens no antigo mundo centrado na CPU, a computação continuou a se concentrar na execução de arquivos por meio de sistemas de arquivos. Serverless tentou se libertar dessa limitação. Mas permaneceu vinculado às convenções de tratamento de dados das linguagens de nível superior nas quais uma função foi escrita.

O WebAssembly não carrega os mesmos fardos que o serverless porque trata os dados como um objeto bruto a ser tratado no tempo de execução com regras definidas na linguagem de nível superior, mas traduzidas para a linguagem de nível inferior por meio do compilador WebAssembly. Um dos principais benefícios desta convenção é o design de fluxo de bytes de entrada/saída um por um, que mapeia perfeitamente para designs modernos de computação distribuída, como microsserviços.

O modelo de componente torna ainda mais fácil manter os dados como objetos brutos não modificados por nenhuma lógica interna autônoma no tempo de execução. Assim como o LEGO com uma interface padrão que pode ser encaixada, os componentes do WebAssembly incluem o código WebAssembly compilado e a interface (funções, estruturas de dados, etc.) que permitem interagir com outros componentes.

Os componentes são infinitamente combináveis ​​e altamente personalizáveis. Juntos, componentes e extensões podem fornecer qualquer funcionalidade e manipulação de dados necessária em um mecanismo fácil de gerenciar. É por isso que é importante garantir que o WebAssembly esteja focado no processamento de dados brutos com regras definidas em plug-ins ou extensões e interfaces definidas por meio de estruturas de componentes, em vez de conter opiniões em tempo de execução sobre como interagir com os dados.

Além disso, neste cenário, muitas das antigas construções em torno dos dados que acrescentam falhas e falhas de segurança podem desaparecer, deixando uma abordagem de tratamento de dados mais rápida e segura por padrão.

Conclusão: deixe o WebAssembly fazer o trabalho a ser feito

O WebAssembly nos oferece uma rara oportunidade de repensar a forma como construímos e operamos aplicativos para melhor refletir o imperativo moderno dos sistemas distribuídos. A mudança para contêineres, microsserviços e sem servidor foi o primeiro estágio de uma mudança para a computação de “tarefas a serem realizadas”. Mas esses paradigmas mantiveram um pé no velho mundo e permaneceram amarrados ao sistema de arquivos, ao tratamento estrito de dados e à visão do universo em núcleos grossos.

O serverless foi o que mais se aproximou de se libertar, mas a gravidade da maneira antiga de construir sistemas puxou-o de volta para a sombra escura do aprisionamento, com calços bloqueando a portabilidade e a complexidade bloqueando a agilidade.

WebAssembly é jovem, inovador e ingênuo – felizmente. Também é poderoso na clareza de seu conceito e design. Faça uma coisa simples muito bem. Execute a computação em uma sandbox. Todo o resto é adicionado pela definição do trabalho. Aderir e aplicar esses quatro fatores ajudará a garantir que o WebAssembly possa se libertar das restrições do passado para redefinir a forma como construímos tecnologia no futuro próximo e distante.

A postagem 4 fatores de um mundo nativo do WebAssembly apareceu pela primeira vez em The New Stack.