Em uma das tecnologias que impulsiona o suporte ao WebAssembly no Azure Kubernetes Service, existe a promessa de criar aplicações que sejam portáteis entre diversas nuvens e hosts.
A junção de WebAssembly e Kubernetes representa um avanço empolgante. Enquanto os contêineres tradicionais podem ser volumosos e demorados para implantar, mesmo com o uso de distribuições Linux otimizadas, os aplicativos WebAssembly requerem apenas um tempo de execução padrão e, por serem arquivos binários dedicados, consomem significativamente menos recursos do sistema. Isso os torna uma opção atraente em comparação com contêineres para aplicações que necessitam de escalabilidade rápida ou precisam operar em ambientes com recursos limitados.
A Microsoft demonstra confiança no WebAssembly ao oferecer suporte no Azure Kubernetes Service, facilitando a implantação por meio do shim contêiner de runwasi. Os desenvolvedores podem utilizar novos frameworks de aplicativos WebAssembly, trabalhando com o tempo de execução do Wasmtime para o WebAssembly System Interface (WASI).
Introduzindo o SpiderLightning.
Uma das estruturas mencionadas é o SpiderLightning, uma subsidiária da Microsoft Deis Labs, desenvolvida para a criação de aplicações distribuídas. O nome SpiderLightning foi inspirado em um tipo de parafuso relâmpago que pode percorrer grandes distâncias através das nuvens. Esse framework consiste em um conjunto de interfaces de aplicação padrão para aplicações WASI, utilizando a linguagem de definição de interface WIT.
Existe uma forte relação entre a arquitetura do WebAssembly (especificamente, WASI) e as exigências dos programadores que desenvolvem aplicações distribuídas nativas para a nuvem. Essa relação está relacionada às disparidades entre diferentes provedores de serviços de nuvem, não como uma forma de evitar bloqueios e garantir a portabilidade, mas sim focando em como proporcionar uma plataforma verdadeiramente multicloud, independente de serviço, capaz de abranger desde dispositivos de borda simples até servidores de alto desempenho, utilizando uma variedade de hardware, desde Raspberry Pi até os mais recentes servidores com múltiplos núcleos da Intel, AMD ou ARM.
O WASI fornece muitos elementos essenciais para concretizar essa visão, embora de maneira básica. Não é inesperado, já que estamos nos estágios iniciais de uma nova plataforma e não podemos esperar a mesma maturidade de sistemas com mais de duas décadas, como a JVM ou a .NET CLR. No entanto, os criadores da plataforma estão cientes disso e estão disponibilizando as ferramentas necessárias para facilitar o desenvolvimento de extensões de plataforma.
WASI prestes a ocorrer com WIT.
Um dos principais aspectos dessa capacidade de expansão é o Modelo de Componente WebAssembly. Desenvolvido pelo grupo de trabalho do WebAssembly como a versão Wasm de um modelo de processo de sistema operacional, esse modelo serve de base para a implementação das interfaces do WASI. Um componente essencial de qualquer abordagem de baixo nível como essa é uma linguagem de definição de interface, que estabelece como as interfaces interagem com o código. No caso do WebAssembly, e em particular do Modelo de Componente, o padrão IDL é wit, que oferece uma maneira concisa e compreensível para os humanos definirem interfaces que são traduzidas para código WebAssembly.
Para criar aplicações distribuídas com o WASI, é necessário um conjunto de extensões que possibilitem a abstração de serviços fornecidos por provedores específicos, transformando-os em interfaces. Em vez de utilizar APIs separadas para diferentes serviços de armazenamento como S3 na AWS e Blob no Azure, e ter que lidar com o código para gerenciá-los individualmente, seria viável ter um único componente de armazenamento que oferecesse um conjunto unificado de interfaces em todas as plataformas. Nesse cenário, o WASI atuaria como a camada subjacente responsável por gerenciar as implementações específicas dos serviços.
Aqui é onde o SpiderLightning entra em cena, oferecendo um conjunto de interfaces que incorporam diversas funcionalidades comuns de aplicação distribuída. Ao programar com base nessas interfaces, você pode garantir a portabilidade do código, sem se preocupar com a infraestrutura. Assim, você pode concentrar-se apenas na implementação da lógica de negócio. Os Deis Labs descrevem o SpiderLightning como um conjunto de peças Lego, com componentes que disponibilizam recursos como armazenamento de chaves, APIs gRPC, filas de mensagens e muito mais.
Contar com um conjunto de definições WIT é apenas o começo; para tornar um ambiente realmente portátil, é necessário uma implementação baseada em APIs e serviços comuns de nuvem. Deis desenvolveu um framework de prova de conceito chamado leve, que é construído em cima do ambiente de tempo de execução WASI conhecido.
Iniciar de forma suave.
Assim como várias funcionalidades da plataforma de desenvolvimento nativa na nuvem, o leve é uma ferramenta CLI que pode ser instalada em sistemas baseados em UNIX, por meio da execução de um script de instalação disponível no GitHub. Desenvolvedores que utilizam Windows podem recorrer ao Subsystem do Windows para Linux. O script realiza o download de um arquivo tar que inclui o binário do leve, o descompacta e instala o CLI.
A ferramenta irá gerar e completar um aplicativo WASI. Sua tarefa é apenas especificar a versão das interfaces SpiderLightning que ele utilizará. Pode-se optar por Rust ou C, desde que os alvos de compilador adequados estejam instalados. Após a compilação do aplicativo, é possível executar o código utilizando o comando leve, direcionando o arquivo Wasm compilado para o aplicativo e configurando o SpiderLightning para associar as interfaces às implementações.
Este documento de configuração é fundamental para trabalhar com leve. Ele permite especificar os recursos necessários para o seu código, identificando o tipo de recurso e seu nome. Sua importância reside no fato de facilitar a alternância entre diferentes recursos de infraestrutura suportados sem a necessidade de modificar o código. Assim, é possível migrar de um provedor de armazenamento para outro mais adequado ao ambiente de destino. O código em execução na borda pode utilizar recursos locais, enquanto um destinado a uma nuvem privada pode acessar um elemento específico de sua infraestrutura, e um voltado para uma nuvem pública pode utilizar os serviços de plataforma do provedor.
A saída gera um código portátil que pode ser executado no AKS, utilizando os recursos do Azure, e escalando de forma flexível para diferentes ambientes, como hardware de borda ou data center local. Além disso, auxilia na proteção das informações da conta, evitando que sejam armazenadas no repositório de código, ao utilizar uma configuração leve para gerenciar esses dados e conexões.
Para que isso seja bem-sucedido, sua aplicação deve incluir a definição WIT do SpiderLightning para o recurso que está sendo utilizado. Isso explica como seu código deve interagir com a interface, incluindo como ele acessa o serviço, os comandos disponíveis, os dados transmitidos e as respostas esperadas. O serviço real é gerenciado pela plataforma de execução, o que permite que você se dedique aos problemas que seu código resolve, em vez de se preocupar com os detalhes de lidar com o Azure ou qualquer outra plataforma de nuvem suportada.
Desenvolvendo habilidades adicionais SpiderLightning.
Atualmente, o Spider O relâmpago está em fase inicial de desenvolvimento, com suporte para apenas algumas das capacidades previstas e um número limitado de serviços disponíveis. A loja de valor-chave é a mais avançada até o momento, especialmente em relação ao suporte de mensagens. Trata-se de um projeto de código aberto que foi projetado para permitir a adição de novas funcionalidades por meio da criação de novas dependências para novos serviços. Com o suporte ao AKS, existe um incentivo para a Microsoft adicionar suas próprias capacidades à plataforma, e um esboço de um plano futuro sugere que essas adições, juntamente com uma seleção de serviços da AWS, estão planejadas.
Estamos nos estágios iniciais da utilização do WebAssembly para desenvolver aplicações distribuídas e o SpiderLightning apresenta grande potencial. Ao oferecer uma forma de abstração dos serviços de plataforma, ele se mostra como uma maneira interessante de criar aplicações portáteis que podem escalar facilmente em diferentes ambientes de nuvem. A progressão das ferramentas e estruturas como o SpiderLightning, dentro do contexto do WASI, será algo a ser acompanhado de perto, à medida que ideias e conceitos são compartilhados. A comunidade do WebAssembly está claramente focada em estabelecer um conjunto padrão de ferramentas para suportar códigos portáteis que possam interagir com diversos serviços de hospedagem. O SpiderLightning pode representar o primeiro passo em uma jornada longa, porém confiante.