WebAssembly e Kubernetes ficam melhores juntos: Matt Butcher

Matt Açougueiro

Nesta entrevista, nos aprofundamos em detalhes sobre o formato WebAssembly (WASM) e Kubernetes com Matt Butcher, cofundador e CEO da Fermyon. Butcher é apaixonado por WebAssembly, sistemas distribuídos e inteligência artificial.

Butcher é um dos criadores originais ou participou da criação de Helm, Brigade, Cloud Native Application Bundles, Open Application Model, Glide e Krustlet. Ele escreveu/co-escreveu muitos livros, incluindo “Learning Helm” e “Go in Practice”.

Nesta entrevista, Butcher fala sobre a motivação e evolução das funções serverless e como o Wasm as complementa. Ele aborda os casos de uso do Wasm em computação de ponta, IA e também no servidor.

Ele também falou sobre como o SpinKube, recentemente introduzido como uma plataforma sem servidor na plataforma Kubernetes desenvolvida pela Wasm, foi um esforço motivado pela adoção do Kubernetes baseado em um orquestrador semelhante que foi usado no Fermyon Cloud. Finalmente, Butcher pinta um quadro realista dos desafios para a comunidade Wasm, especialmente com as comunidades existentes, como Java.

Você pode se apresentar e fornecer um breve histórico de como o Wasm surgiu? Algum problema específico no desenvolvimento de aplicativos de sistemas distribuídos que você pretendia resolver com o Wasm?

Passei minha carreira em software na intersecção entre computação distribuída, ferramentas para desenvolvedores e segurança da cadeia de suprimentos; não foi realmente um benefício que me atraiu para Wasm, mas como as características da tecnologia foram mapeadas para os problemas que eu estava tentando resolver (e, de forma mais geral, os problemas que estávamos tentando resolver como indústria): portabilidade; velocidade de inicialização e execução; forte sandbox baseado em capacidade; e tamanho do artefato.

Na Microsoft, estávamos analisando o Azure Functions e outras tecnologias semelhantes e víamos muito desperdício. Os sistemas estavam ociosos 80% (ou mais) apenas aguardando solicitações de entrada. As máquinas virtuais estavam pré-aquecidas em uma fila, consumindo memória e CPU, aguardando para que uma função sem servidor fosse instalada e executada. E todo esse desperdício foi feito em nome do desempenho. Nós nos perguntamos: e se pudéssemos encontrar uma forma de computação muito mais eficiente, que pudesse iniciar a frio com muito mais rapidez? Então não precisaríamos pré-aquecer as máquinas virtuais. Poderíamos também melhorar drasticamente a densidade, porque os recursos seriam libertados com mais frequência.

Portanto, tratava-se realmente de encontrar um tempo de execução melhor para o padrão de desenvolvedor que chamamos de “funções sem servidor”. Existem muitas definições de serverless circulando por aí. Quando dizemos isso na Fermyon, nos referimos ao padrão de design de software no qual um desenvolvedor não escreve um servidor, mas apenas um manipulador de eventos. O código é executado quando uma solicitação chega e é encerrado assim que a solicitação é processada.

Sim. A primeira geração de serverless nos deu um bom padrão de design (FaaS, ou funções serverless) baseado no tratamento de eventos. Mas do Lambda ao KNative, as implementações foram construídas com base em tempos de execução que não foram otimizados para esse estilo de carga de trabalho. As máquinas virtuais podem levar alguns minutos para iniciar, e os contêineres tendem a demorar algumas dezenas de segundos. Isso significa que você precisa pré-aquecer as cargas de trabalho ou sofrer grandes penalidades por inicialização a frio. O pré-aquecimento é caro, pois envolve o pagamento de CPU e memória enquanto algo fica ocioso. As partidas a frio, porém, têm um impacto direto no usuário: tempo de resposta lento.

Fomos atraídos pelo WebAssembly especificamente porque estávamos procurando uma forma de computação mais rápida que reduzisse o tempo de inicialização a frio. E com menos de um milissegundo, o tempo de inicialização a frio do WebAssembly é literalmente mais rápido que um piscar de olhos. Mas o que nos surpreendeu foi que, ao reduzir a inicialização a frio, utilizar os pequenos tamanhos binários do WebAssembly e escrever um executor de funções sem servidor eficaz, também conseguimos aumentar a densidade. Isso, por sua vez, reduz custos e melhora a sustentabilidade, uma vez que esta geração sem servidor está fazendo mais com menos recursos.

Aprofundando-se na interseção entre Wasm e computação de ponta, o Wasm é feito sob medida principalmente para aplicações de ponta onde a eficiência e a capacidade de resposta são fundamentais?

As funções sem servidor são a principal forma de as pessoas programarem de ponta. Devido ao seu perfil de tempo de execução, o Wasm é uma opção fenomenal para a computação de ponta – e vimos redes de distribuição de conteúdo como Fastly e, mais recentemente, Cloudflare, demonstrarem isso. E estamos começando a ver mais casos de uso do Wasm em dispositivos restritos e desconectados – desde torres 5G até a indústria automotiva (com carros rodando aplicativos Spin devido a essa eficiência e portabilidade).

Uma maneira de pensar sobre esse problema é em termos de quantas aplicações você pode executar em um nó de borda. Os contêineres requerem muitos recursos do sistema. Em um hardware (ou máquina virtual) que pode executar cerca de 30 a 50 contêineres, podemos executar mais de 5.000 aplicativos Wasm sem servidor. (Fermyon Cloud executa 3.000 aplicativos de usuário por nó em nosso cluster.)

A outra coisa realmente interessante sobre o WebAssembly é que ele é neutro em termos de sistema operacional e arquitetura. Ele pode ser executado em Windows, Linux, Mac e até mesmo em muitos sistemas operacionais exóticos. Da mesma forma, pode rodar em arquitetura Intel ou ARM. Isso significa que o desenvolvedor pode escrever e compilar o código sem precisar saber qual é o destino. E isso é importante para a computação de ponta, onde muitas vezes a localização é decidida no momento da execução.

Navegando no mundo do software empresarial: Muitas empresas ainda usam Java. Tendo em mente os desenvolvedores e arquitetos Java, você pode comparar e contrastar Java e Wasm? Você pode falar sobre o papel do WASI neste contexto?

Luke Wagner, o criador do Wasm, uma vez me disse que o Java inovou (junto com o .NET) no final dos anos 90 e ao longo das décadas ele foi refinado, otimizado e aprimorado. WebAssembly foi uma oportunidade para começar do zero com base em 20 anos de pesquisa e desenvolvimento.

Wasm está em dívida com linguagens de bytecode anteriores, com certeza. Mas há mais do que isso. O WebAssembly foi construído com necessidades de sandbox de segurança muito rígidas. Interfaces de sistema negadas por padrão e baseadas em recursos são essenciais para uma tecnologia que pressupõe que está executando código não confiável. Java e .NET assumem a disposição padrão de que o contexto de execução pode “confiar” no código que está executando. Wasm é o oposto.

Em segundo lugar, o Wasm foi construído com o objetivo declarado de que muitas linguagens diferentes (idealmente qualquer linguagem) pode ser compilado para Wasm. JVM e .NET começaram com uma perspectiva diferente de que linguagens específicas seriam construídas para acomodar o tempo de execução. Em contraste, a primeira linguagem a obter suporte ao Wasm foi C. Rust, Go, Python e JavaScript, todos seguidos logo depois. Em outras palavras, o WebAssembly demonstrou que poderia ser um alvo para as linguagens de programação existentes, enquanto depois de décadas nem o Java nem o .NET foram capazes de fazer isso de forma ampla.

Além disso, o WebAssembly foi projetado para oferecer velocidade tanto em termos de inicialização a frio quanto de desempenho em tempo de execução. Embora o Java sempre tenha tido tempos de inicialização notoriamente lentos, os binários do WebAssembly levam menos de um milissegundo para iniciar a frio.

Mas a melhor coisa sobre o WebAssembly é que, se ele for realmente bem-sucedido, não demorará muito até que Java e .NET possam compilar no WebAssembly. A equipe .NET disse que oferecerá suporte total ao WebAssembly no final de 2024. Esperançosamente, o Java não ficará muito atrás.

Explorando a sinergia entre Wasm e Kubernetes, SpinKube foi lançado na Cloud Native Computing Foundation’s Kubecon UE 2024 em Paris. O Kubernetes foi uma reflexão tardia? Como isso afeta o desenvolvimento de aplicativos nativos da nuvem, incluindo o tratamento de deficiências e a redefinição de aplicativos em contêineres?

A maioria de nós de Fermyon trabalhou no Kubernetes por muito tempo. Construímos Helm, Brigade, OAM, OSM e muitos outros projetos Kubernetes. Quando mudamos para o WebAssembly, sabíamos que teríamos que começar com ferramentas de desenvolvedor e avançar em direção aos orquestradores. Então começamos com o Spin para fazer com que os desenvolvedores construíssem coisas úteis. Construímos o Fermyon Cloud para que os desenvolvedores pudessem implantar seus aplicativos em nossa infraestrutura. Nos bastidores, Fermyon Cloud dirige o Nomad da HashiCorp. Tem sido um orquestrador espetacular para as nossas necessidades. Como eu disse anteriormente, conseguimos hospedar 3.000 aplicativos fornecidos pelo usuário por nó de trabalho em nosso cluster, ordens de magnitude maiores do que poderíamos ter alcançado com contêineres.

Mas inevitavelmente sentimos a força da gravidade do Kubernetes. Muitas organizações estão operando clusters Kubernetes maduros. Seria difícil convencê-los a mudar para o Nomad. Por isso, trabalhamos juntos com Microsoft, SUSE, Liquid Reply e outros para construir uma excelente solução Kubernetes. A Microsoft fez o trabalho mais pesado quando escreveu o suporte de contêiner para Spin.

A popularidade imediata do SpinKube surpreendeu até nós. As pessoas estão ansiosas para experimentar um tempo de execução sem servidor que supere o Knative e outras tentativas anteriores de sem servidor no Kubernetes.

Vamos conversar sobre Wasm e Inteligência Artificial. Há um burburinho sobre Wasm e IA. Você pode expandir isso? Isso significa que Grandes Modelos de Linguagem (LLMs), etc. pode ser movido para o limite com Wasm?

Existem duas partes para trabalhar com LLMs. Existe o treinamento de um modelo, que exige enormes quantidades de recursos e tempo. E existe o uso (ou “inferência contra”) de um modelo. Esta parte posterior pode se beneficiar muito com a otimização do tempo de execução. Portanto, nos concentramos exclusivamente na inferência sem servidor com LLMs.

Em sua essência, WebAssembly é uma tecnologia de computação. Geralmente pensamos nisso em termos de uso da CPU. Mas é igualmente aplicável às GPUs que a IA usa para inferência. Portanto, conseguimos construir SDKs dentro do host WebAssembly que permitem aos desenvolvedores fazer inferências LLM sem ter que se preocupar com a arquitetura ou os recursos da GPU subjacentes.

Mais importante ainda, o Fermyon torna possível dividir o uso da GPU em um nível muito fino de granularidade. Embora a maioria dos mecanismos de inferência de IA bloqueiem a GPU durante um processo de servidor (por exemplo, horas, dias ou meses seguidos), bloqueamos a GPU apenas durante uma operação de inferência, que dura segundos ou talvez alguns minutos por vez. Isso significa que você pode obter uma densidade muito maior, executando mais aplicativos de IA na mesma GPU.

Isso é o que torna o Wasm viável no limite, onde as funções são executadas em apenas alguns piscar de olhos. Esses nós de borda precisarão apenas de um número modesto de GPUs para atender milhares de aplicações.

Roteiro WASM: Quais são as lacunas que impedem a adoção do Wasm e o roteiro orientado pela comunidade para resolvê-las? Mais alguma coisa que você deseja adicionar?

WebAssembly ainda está ganhando novos recursos. O principal em andamento no momento são as chamadas de função assíncronas entre componentes. Isso permitiria que os módulos WebAssembly se comunicassem entre si de forma assíncrona e melhoraria enormemente o potencial de computação paralela do Wasm.

Mas sempre o grande risco do WebAssembly vem de seu objetivo de design mais audacioso. O Wasm só terá sucesso se puder executar todas as principais linguagens de programação e executá-las de maneira mais ou menos uniforme (por exemplo, com suporte para WASI, a WebAssembly System Interface). Vimos muitas linguagens adicionarem suporte WebAssembly de primeira camada. Alguns têm boas implementações que não estão incluídas na linguagem principal e requerem conjuntos de ferramentas separados. Isso é um pequeno obstáculo. Outros, como Java, não fizeram nenhum progresso notável. Embora eu ache que as coisas estão progredindo bem para todas as principais linguagens, exceto Java, até que essas linguagens tenham suporte completo, elas não atingirão todo o seu potencial.

A postagem WebAssembly e Kubernetes ficam melhores juntos: Matt Butcher apareceu pela primeira vez em The New Stack.