O entusiasmo por Wasm vem sendo construído nos últimos anos. E enquanto alguma energia Wasm permanece no mundo dos navegadores, mais entusiasmo está concentrado em Wasm no lado do servidor da equação. Microsoft, Cloudflare, SUSE, Docker, Red Hat e outros stalwarts introduziram produtos ou integrações Wasm. Vários projetos de código aberto estão abrindo caminho pelo caminho de projetos da CNCF, e o interesse dos desenvolvedores aumentou.
Por exemplo, o kit de ferramentas Spin de código aberto para construção de aplicativos sem servidor já foram baixados mais de 230.000 vezes. O que isso significa para a engenharia de plataforma? Onde veremos os apps Wasm implantados? Por que no lado do servidor?
As Máquinas Virtuais e os Contêineres
As máquinas virtuais definiram a nuvem inicial. A proposta de valor era clara: empacotar um sistema operacional e aplicativos dentro de uma máquina virtual e executá-los com segurança no hardware de outra pessoa. Há pouco mais de uma década, plataformas de código aberto como o OpenStack se juntaram a uma lista crescente de provedores de nuvem para tornar possível que organizações grandes e pequenas executem sua infraestrutura sem precisar possuir seu próprio hardware ou alugar espaço em rack de data center.
Por mais poderosas que fossem as máquinas virtuais, elas tinham algumas desvantagens que atraíam a ira dos desenvolvedores e do pessoal do DevOps. As imagens de máquina eram lentas para construir, implementar e iniciar, e elas empurravam um enorme fardo de segurança e manutenção para a equipe ou indivíduo responsável por construir a imagem da VM.
A rápida ascensão dos contêineres Docker não foi nenhuma surpresa para aqueles que prezavam experiência e facilidade de uso. Os Dockerfiles tornaram a construção de imagens fácil e atraente para os desenvolvedores. Níveis mais altos de abstração e conjuntos menores de dependências reduziram e distribuíram a carga de manutenção entre as partes responsáveis. Os contêineres inicializaram em apenas uma dúzia de segundos em vez de minutos.
O zelo era descomunal, no entanto. Os primeiros proponentes das tecnologias de contêineres alegaram que era a sentença de morte para as máquinas virtuais. Quando o Kubernetes chegou à cena, ele mostrou que o oposto era verdade: VMs e contêineres vivem uma coexistência feliz. A grande maioria dos clusters Kubernetes de hoje distribui máquinas virtuais como nós e, em seguida, empacota essas máquinas virtuais com contêineres.
Funções Serverless e Suas Limitações
Por mais úteis que sejam, os contêineres não resolvem todos os problemas das nuvens modernas. Eles são ótimos para processos de longa duração cuja expectativa de vida útil é de horas, dias ou meses. No entanto, à medida que um novo padrão de desenvolvimento chamado "funções sem servidor" ganhou popularidade, as fraquezas dos contêineres ficaram evidentes.
Uma função serverless funciona como um aplicativo orientado a eventos. Em vez de iniciar um processo daemon de longa duração que manipula centenas de milhares de solicitações (ou mais) durante sua longa vida útil, uma função serverless manipula apenas um evento — uma solicitação.
Ela inicia quando um evento é recebido, faz qualquer processamento necessário, retorna uma resposta e desliga. Operacionalmente falando, a virtude desse modelo é que quando uma solicitação não está sendo manipulada, poucos ou nenhum recurso do sistema é utilizado. Idealmente, funções serverless são mais eficientes, mais baratas e mais fáceis de gerenciar. Mas isso requer ter o tempo de execução correto. A primeira geração de serverless não acertou em cheio nisso.
Contêineres e máquinas virtuais são otimizados para processos de longa duração. Consequentemente, se eles levarem um minuto ou algumas dezenas de segundos para iniciar, a lógica de orquestração geralmente absorve esse custo. No entanto, levar minutos ou até segundos para iniciar em funções sem servidor é inaceitável, especialmente para serviços de linha de frente. Os usuários simplesmente não vão esperar por uma resposta.
Muitas tentativas foram feitas para contornar essas limitações, sendo mais comumente máquinas virtuais ou contêineres de "pré-aquecimento", para que fiquem ociosos em uma fila aguardando uma solicitação. Mas isso é ineficiente, aumentando o custo de operação de funções sem servidor.
Wasm para o Resgate
O que é necessário é um runtime isolado e seguro que possa iniciar em milissegundos. Wasm é exatamente um runtime assim.
Com seus contêineres Com tempo de inicialização abaixo de milissegundos e um modelo de segurança mais forte do que contêineres, o Wasm é um ambiente fantástico para sandboxing de processos de curta duração, como funções sem servidor. Sem surpresa, muitas ferramentas de código aberto, incluindo Spin e Wasmtime, evoluíram para executar funções Wasm em ambientes de nuvem. O Wasm sem servidor é muito mais eficiente e econômico do que soluções específicas de nuvem, como AWS Lambda ou Azure Functions. Mas não há razão para colocar o Wasm contra contêineres — eles podem trabalhar cooperativamente.
Funções sem servidor são ótimas para muitos aplicativos, mas não para todos. Elas podem fornecer microsserviços mais baratos e simples, backends da web, servidores de API e processadores em lote. Mas muitos serviços precisam ser executados o tempo todo, mantendo um conjunto de threads trabalhando continuamente. Bancos de dados, filas de mensagens e aplicativos legados são exemplos disso.
Os contêineres fornecem uma excelente tecnologia base para servidores always-on. Para respeitar os casos de uso serverless e always-on, um sistema deve ser capaz de executar contêineres e cargas de trabalho Wasm.
Integrando Wasm com Contêineres
Já temos uma série de ambientes de contêiner, do Rancher Desktop e Docker Desktop localmente ao Kubernetes e Nomad na nuvem. Começar com outro orquestrador, dessa vez para o Wasm sem servidor, introduziria ainda mais complexidade operacional em um ambiente já complicado. Tem sido muito mais fácil integrar os executores do Wasm nesses ambientes existentes.
No desktop, tanto o Rancher Desktop quanto o Docker Desktop suportam a execução do Wasm. O SpinKube traz suporte ao Wasm para o Kubernetes, fornecendo facilidades para executar contêineres e o Wasm lado a lado no mesmo pod. Até mesmo o Nomad de classe empresarial pode agendar tarefas para um tempo de execução do Wasm. Independentemente dos seus investimentos em infraestrutura, se você estiver executando contêineres, não é difícil também executar o Wasm nos mesmos serviços.
O SpinKube, submetido no início deste ano para adição aos projetos sandbox do CNCF, integra um shim Containerd, alguns operadores e novos CRDs para adicionar suporte Wasm diretamente ao Kubernetes. Longe de introduzir sobrecarga de desempenho, os clusters SpinKube podem hospedar milhares de aplicativos Wasm e gerenciar várias centenas de milhares de invocações de funções sem servidor por segundo em um cluster Kubernetes de 8 nós.
Uma Evolução do Serverless
A AWS introduziu a primeira onda de funções serverless com Lambda. Uma década depois, é hora de uma atualização de toda a tecnologia. Com funções serverless baseadas em Wasm e projetos como SpinKube, é possível executar aplicativos web de linha de frente usando o padrão de design de funções serverless.
Graças à portabilidade do Wasm e à natureza de código aberto das plataformas Wasm, não há mais bloqueio de nuvem. Execute-os em qualquer lugar onde o Kubernetes seja executado, em qualquer lugar onde contêineres sejam executados ou mesmo em bare metal tão pequeno quanto um Raspberry Pi. E o tempo de inicialização a frio ultrarrápido de submilissegundos do Wasm significa que não apenas suas cargas de trabalho de frontend com maior desempenho podem ser executadas como Wasm, mas até mesmo seus aplicativos raramente acessados podem ser instalados em um cluster Kubernetes sem consumir recursos o tempo todo.
O Wasm chamou a atenção de muitos desenvolvedores do lado do servidor porque a ferramenta é fácil de usar e direta de executar. No entanto, as características de tempo de execução do Wasm o tornam uma tecnologia tão poderosa quando pareada com contêineres na nuvem moderna de hoje.
