WebAssembly transformou aplicativos de navegador e está previsto para expandir a infraestrutura do servidor. Qual será o impacto nos recipientes e no Kubernetes? Opiniões de seis especialistas.
Visto como o quarto padrão da internet, o WebAssembly, também conhecido como Wasm, tem gerado debates intensos desde sua criação. Trata-se de uma linguagem de programação semelhante a um conjunto, um formato binário compacto e um alvo de compilação para várias linguagens, como C, C++, C#, Go, JavaScript, Python, Rust, entre outras, que pode ser executado em alta velocidade em um navegador web. O WebAssembly já está bem estabelecido no desenvolvimento web e está cada vez mais próximo de ser amplamente utilizado fora do navegador.
A eficiência, rapidez, mobilidade e segurança do Wasm têm entusiasmado os desenvolvedores com suas oportunidades em servidores, clientes e até mesmo com a possibilidade de superar os contêineres Linux. No entanto, será que essa tecnologia se tornará uma plataforma popular que desafiará o atual ecossistema de contêineres?
Indivíduos que estão familiarizados com o debate entre recipientes Wasm e provavelmente já estão cansados de ver este mesmo tweet de 2019 de Solomon Hykes, co-fundador de Docker e Dagger, sendo repetido em todos os artigos sensacionalistas sobre Wasm e em cada slide de apresentação.
Se o WASM+WASI estivesse disponível em 2008, não teríamos precisado desenvolver o Docker. Isso destaca a importância dessa tecnologia. O uso do WebAssembly em servidores representa o futuro da computação.
O detalhe é crucial, de acordo com Hykes. Ele sugere que se a tecnologia Wasm já estivesse disponível, não haveria tanta demanda por contêineres como o Docker. No entanto, essa realidade não se concretizou, e atualmente os contêineres Docker são amplamente utilizados. A substituição dos contêineres Linux não é uma tarefa simples, como Hykes ressalta.
Minha postagem no Twitter foi amplamente interpretada de forma equivocada. Há uma interpretação de que o WebAssembly irá substituir os contêineres Docker, o que eu não acreditei na época da postagem e continuo não acreditando. Na minha visão, isso nunca irá ocorrer, já que o Docker é estabelecido como padrão e o WebAssembly e o WASI, apesar de suas qualidades, são tecnologias muito distintas e não podem ser consideradas substitutos diretos. Eles possuem abordagens e aplicações bastante diferentes.
A maioria concorda que o WebAssembly supera os recipientes no navegador, em casos de uso de computação de borda, plugins sandboxed e algumas funções serverless. Enquanto alguns têm grande confiança no potencial transformador do Wasm, as opiniões estão divididas quanto ao seu papel como substituto a longo prazo para recipientes ou processos stateful do servidor. A seguir, vamos explorar mais a fundo para comparar em que aspectos o Wasm supera os recipientes e onde não.
O lugar onde Wasm atinge objetos de armazenamento.
Alguns programadores acreditam que o uso do Wasm está se tornando cada vez mais comum em diferentes aplicações, especialmente em ambientes desafiadores. Matt Butcher, co-fundador e CEO da Fermyon, afirma que o Wasm é adequado tanto para dispositivos de IoT quanto para grandes infraestruturas em nuvem. Ele destaca que essa tecnologia é ideal para funções sem servidor, IoT, computação de borda e plugins de extensão.
No limite
Um campo em que o Wasm se destaca é a computação de borda, onde sua natureza leve e segura o torna particularmente interessante. De acordo com Michael J. Yuan, fundador do Segundo Estado e do projeto WasmEdge da Cloud Native Computing Foundation, o isolamento de software na borda é essencial, porém os contêineres consomem muitos recursos. Nesse contexto, o Wasm pode ser empregado para isolar e gerenciar softwares de forma mais eficiente do que os contêineres.
Enquanto os contêineres requerem megabytes ou gigabytes, os módulos Wasm necessitam apenas de kilobytes ou megabytes. De acordo com Bailey Hayes, CTO da Cosmonic, um arquivo .wasm é menor e independente do tempo de execução em comparação com os contêineres. A portabilidade do Wasm permite a execução de cargas de trabalho em ambientes diversos, como nuvem, borda ou dispositivos com recursos limitados.
Isso faz com que o Wasm seja apropriado para situações específicas, como em pequenos aparelhos incorporados. Um exemplo disso é a utilização de wasmCloud na indústria de Internet das Coisas (IoT), onde a MachineMetrics está implementando essa tecnologia na linha de produção para melhorar o processamento de dados das máquinas de maneira segura e eficaz.
Atividades fundamentais para o rendimento.
O WebAssembly desempenha um papel importante em necessidades críticas de desempenho, como funções sem servidor e certas aplicações de inteligência artificial. De acordo com Luke Wagner, um engenheiro sênior da Fastly, há casos específicos em que o WebAssembly será a opção preferencial ou escolhida em vez de contêineres. Ele destaca que o WebAssembly oferece benefícios de economia de custos e melhorias no tempo de inicialização para cargas de trabalho baseadas em servidor, o que pode ser atraente para empresas que desejam evitar depender exclusivamente de soluções proprietárias sem servidor.
No contexto de inteligência artificial, o Wasm é considerado apropriado para realizar inferências em dispositivos heterogêneos de forma interplataforma. Segundo Yuan, os contêineres são inadequados para GPUs devido ao seu peso e falta de portabilidade, o que os torna inadequados para usos como o LlamaEdge, um serviço de tempo de execução local baseado em Wasm e API para grandes modelos de linguagem (LLMs).
Desenhos arquitetônicos fundamentados em elementos modulares.
Alguns consideram o WebAssembly System Interface (WASI), uma especificação proposta pela ByteCode Alliance, como o fundamento para um ecossistema de componentes modulares. A Hayes da Cosmonic observa que novos tipos de arquiteturas estão surgindo para aproveitar o tamanho e a velocidade dos componentes do Wasm. Ela destaca a eficiência do Wasm em termos de tamanho, independência de tempo de execução e inicialização rápida, o que diminui a latência em comparação com contêineres.
Inclua nos padrões de segurança do Wasm e melhore significativamente a funcionalidade em contêineres. De acordo com Hayes, os contêineres geralmente não são vistos como a melhor opção para proteger e isolar código de usuário de forma segura.
“Fastly’s Wagner expressa otimismo quanto à migração de muitas cargas de trabalho de contêineres para Wasm. Especialmente em relação às cargas de trabalho de greenfield, um movimento que já está sendo observado atualmente. Com a padronização em torno do WebAssembly Component Model em andamento, as empresas podem optar por Wasm como uma forma de modularizar seus serviços, evitando a complexidade de uma arquitetura tradicional de microsserviços.”
Se a arquitetura baseada em componentes se tornar o principal paradigma de desenvolvimento, os contêineres podem ter um papel menos relevante, de acordo com alguns defensores. A promessa do Wasm é permitir a construção de aplicações por meio de componentes isolados em suas próprias áreas restritas. Embora o Wasm possa não substituir completamente os contêineres, existe a possibilidade de que o Wasm possa superá-los em aplicações baseadas em componentes, já que os contêineres podem não agregar valor a essas aplicações.
Extensões para softwares de servidor
Plugins para sistemas já estabelecidos são uma área promissora, conforme destacado por Yuan. Hykes também enxerga o Wasm como uma excelente opção para a criação de plugins altamente isolados para aplicativos de servidor. De fato, desenvolvedores de frameworks de plugins, como os do Istio WasmPlugins, Shopify Functions e extensões do Envoy, já estão adotando o Wasm. Além disso, alguns frameworks disponíveis no mercado facilitam a geração e execução desses plugins.
Aplicativos e plataformas online.
Naturalmente, as aplicações web que utilizam WebAssembly são muito comuns e populares. Esta tecnologia é amplamente adotada para aplicações de alto desempenho na web, especialmente aquelas baseadas em navegadores, onde o WebAssembly é altamente eficaz. É importante ressaltar que os recipientes ainda não têm grande presença nesse campo, pois a execução no navegador já está bem estabelecida e suportada, o que torna mais fácil a adesão a essa tecnologia.
Por exemplo, a Adobe incorpora de forma ativa o Wasm em versões online do Photoshop, Express, Lightroom, Acrobat e outras aplicações. Colin Murphy, engenheiro sênior de software da Adobe, destaca que o Wasm foi criado para executar programas rapidamente, de forma eficiente e segura. À medida que se desenvolve, o Wasm ampliará seu uso em diferentes áreas da computação, como os serviços web.
“Segundo Hykes, o uso de vapor no navegador está seguindo a direção correta, e ele acredita que em breve se tornará algo comum. Ele destaca a prática da equipe de engenheiros de back-end da Dagger de escrever código de front-end em Go e compilá-lo para Wasm. Hykes destaca que os engenheiros mais experientes muitas vezes se sentem limitados, pois não podem trabalhar no desenvolvimento de front-end, e essa abordagem visa capacitá-los.”
Onde os vasos colidem com Wasm.
De acordo com Hayes da Cosmonic, em certos locais específicos, os dispositivos duráveis como computadores e eletrodomésticos ainda serão predominantes e não devem ser substituídos por Wasm.
Assim como as máquinas virtuais não foram totalmente substituídas por recipientes, a transição para o WebAssembly não será total. De acordo com Butcher, afirmar que o WebAssembly irá eliminar os contêineres é uma visão simplista. É provável que aplicativos Wasm sejam executados juntamente com os milhares de aplicativos já em funcionamento em contêineres no Kubernetes.
Servidores em larga escala.
Butcher menciona que a medida não é ideal para processos de servidor de longo prazo. Ele destaca que o ponto forte dos contêineres está na empacotagem e na execução de servidores existentes de longa duração, como o Postgres, WordPress ou aplicativos Java empresariais. Butcher não acredita que a tecnologia desafiará esse espaço nos próximos dez anos, devido à falta de suporte de threads, fraco suporte de soquete e ao fato de que muitas das linguagens suportadas não são otimizadas para Wasm.
Wagner rapidamente observa que o Wasm não consegue substituir de forma simples cargas de trabalho em contêineres que requerem recursos de um sistema operacional específico ou processadores que ainda não são compatíveis com o Wasm. Da mesma forma, se a carga de trabalho utilizar uma linguagem que não seja totalmente suportada pelo Wasm, haverá dificuldades. No entanto, Wagner acredita que essas questões serão resolvidas à medida que o ambiente Wasm se desenvolve.
Alguns indivíduos não estão tão convencidos. De acordo com Butcher, o modelo de segurança do Wasm não permite o acesso a diversos recursos de baixo nível do sistema operacional aos quais os aplicativos de servidor normalmente têm acesso, e não há indicações de que isso irá mudar. Ele afirma que a maioria dos grandes códigos não podem ser facilmente convertidos para WebAssembly e que é necessário reescrever o código. Embora haja opiniões de que essa situação é temporária, Butcher discorda e acredita que essa restrição permanecerá.
Mesmo Cloudflare, uma empresa líder na próxima geração de plataformas de nuvem que parecia substituir contêineres, utiliza contêineres como base de sua plataforma de Trabalhadores. De acordo com o blog da Cloudflare, se você utilizou inferência de IA em GPUs com IA de Trabalhadores, lançou navegadores sem cabeça com Renderização de Navegador ou trabalhos de construção em fila com os novos Construções de Trabalhadores, você utilizou contêineres em sua rede, possivelmente sem perceber.
A ideia principal é que os recipientes se integram e convivem harmoniosamente com outras estratégias de desenvolvimento, e é provável que continuem seguindo essa tendência.
Plataformas de computação em nuvem desenvolvidas para Linux.
Linux se espalhou amplamente, e os recipientes são essenciais para esse sistema operacional, o que os torna difíceis, senão impossíveis, de serem substituídos. Hykes afirma que, ao discutir a substituição de recipientes, é necessário considerar a substituição do Linux.
“Os contêineres se tornaram um elemento essencial do Linux, abrangendo não apenas o kernel, mas também a camada do sistema operacional, a pilha de tecnologias em torno dele e a forma convencional de executar o Linux em data centers na nuvem”, destaca Hykes. “Esses elementos são agora indispensáveis e a questão principal é se você adiciona mais camadas sobre eles.”
Embora os contêineres possam suportar Componentes de Wasm, é desafiador visualizar Wasm emergindo como uma plataforma de servidor e de domínio geral comparável ao Linux atualmente. De acordo com Hykes, atualmente não há motivos evidentes para uma mudança em larga escala para essa nova plataforma.
Outros concordam que não é vantajoso substituir a pilha atual do recipiente por completo. De acordo com Yuan do Segundo Estado, em muitas aplicações nativas da nuvem hoje em dia, os containers Linux são as ferramentas mais adequadas e não devem ser trocados. A mudança seria mais apropriada para novos cenários em que o isolamento é fundamental, mas os containers não são suficientes.
Outras circunstâncias em que é necessário reduzir o tempo de execução tornam o Wasm não ideal. Segundo Wagner, da Fastly, geralmente, o desempenho em tempo de execução do Wasm é moderado em comparação com o código nativo, e em certos cenários, qualquer sobrecarga pode ser inaceitável. Nessas circunstâncias, o Wasm não pode substituir os contêineres.
Limpeza de recipientes e utensílios.
Paráfrase: Muitos acreditam que Kubernetes está intimamente ligado ao futuro da infraestrutura de nuvem, apesar de previsões de que Wasm poderia substituir os tempos de execução baseados em contêineres até 2030. Em vez de substituir o paradigma atual dos contêineres, há quem enxergue Wasm como integrado nesse contexto.
Yuan não acredita que Wasm substituirá os recipientes, mas sim os considera tecnologias que se complementam. Ele destaca que a Bytecode Alliance e a CNCF estão avançando para garantir que o Wasm seja uma complementação ao Kubernetes, desenvolvendo projetos que permitem a execução conjunta de módulos de recipientes e Wasm no mesmo cluster.
Alguns visualizam um cenário em que o Docker suporta a execução de contêineres Linux, contêineres Windows e recipientes Wasm simultaneamente. Hykes considera essa possibilidade viável, embora reconheça que a demanda atual é limitada. Isso se deve, em parte, à falta de adoção generalizada do WebAssembly nos servidores, conforme observado por Hykes, que ainda o considera um caso de uso de nicho.
“Segundo Hykes, para que o sistema possa se popularizar, é necessário um caso de uso principal que convença a todos a utilizá-lo no servidor, além de uma forma fácil de utilizá-lo. Ele ressalta a importância de ter um caso de uso para promover a adoção de uma nova plataforma.”
Perspectivas para WebAssembly
No futuro, é provável que novos mercados e formas de computação surjam graças ao WebAssembly (Wasm). Segundo Murphy, da Adobe, a capacidade de portabilidade e composição do WebAssembly System Interface (WASI) poderá eliminar as barreiras entre diferentes tipos de computação, como data centers, edge computing, dispositivos móveis e IoT.
Além das aplicações mencionadas anteriormente, os setores Wasm também englobam uma variedade de casos de uso em áreas como bancos, manufatura, telecomunicações, serviços digitais, jogos, entre outros. Por exemplo, a equipe WebAssembly Canvas Catalyst do TM Forum apresentou uma prova de conceito que substituiu o Kubernetes utilizando wasmCloud para gerenciar suas APIs abertas.
O processo de refatoração demandaria esforço, porém resultaria em ganhos de eficiência que não eram necessários na era anterior ao uso de contêineres. De acordo com Murphy, “Docker e Kubernetes trouxeram inovações significativas, e se você adaptar suas aplicações para se beneficiarem deles, os resultados são excelentes”. No entanto, na maioria dos casos, as aplicações eram simplesmente contêineres com pouca ou nenhuma refatoração. Isso frequentemente resultava em tempos de inicialização lentos e altos requisitos de memória.
Paráfrase do texto: O que podemos esperar do futuro? É provável que vejamos o Wasm se tornar mais compacto e rápido, sendo cada vez mais utilizado em diversas novas aplicações. No entanto, substituir completamente o atual ecossistema de contêineres parece problemático. Tanto a tecnologia de lavagem quanto os contêineres continuarão desempenhando papéis importantes na computação em nuvem e no ambiente empresarial por um longo período.