Painel de Discussão Keynote: Revolucionando Arquiteturas Cloud Native com WebAssembly

[0:00] Então, recentemente comecei a me interessar por boxe. Na verdade, não boxeo. Na maior parte apenas assisto do conforto do meu sofá. E no boxe, há categorias de peso como peso-pesado, peso-médio, peso-leve e assim por diante. E é exatamente como parece. Um boxeador deve atingir um determinado peso para lutar dentro de uma categoria. E essas categorias de peso me lembram as nuvens, as ondas da computação em nuvem.

[0:35] Obrigado. Então, primeiro, temos as máquinas virtuais. Esta é a categoria dos pesos-pesados. Estar na categoria dos pesos-pesados no boxe significa que você é poderoso. Mas se você for nocauteado, vai levar algum tempo para se levantar novamente. Isso é física básica, certo? As máquinas virtuais são o runtime peso-pesado original da nuvem. Muitas vezes, elas levam minutos para iniciar, mas contêm um sistema operacional inteiro, do kernel às aplicações, então você pode fazer muita coisa com elas.

[1:10] Um contêiner é mais leve e menor. E no mundo da Computação em Nuvem, essa seria a sua categoria peso-médio. O peso-médio equilibra velocidade e potência. Os contêineres nos deram o ambiente perfeito para executar um único servidor de longa duração. Eles levam segundos, não minutos, para iniciar, e consomem menos recursos do que máquinas virtuais. Agora, adicione a isso o WebAssembly, a terceira onda da computação em nuvem. Esta é a sua categoria peso-leve. Velocidade e agilidade são a ordem do dia aqui. Compile seu aplicativo uma vez diretamente para o formato binário WebAssembly, e use esse mesmo binário em várias arquiteturas e sistemas operacionais sem alterações.

[2:01] E um aplicativo WebAssembly pode ter inicialização a frio em cerca de meio milissegundo. Meio milissegundo, tornando-o vastamente mais rápido do que até mesmo -- tornando sua velocidade de inicialização vastamente mais rápida do que até mesmo os contêineres. Então, como executamos WebAssembly no Kubernetes e em ambientes nativos de nuvem? Vou falar com vocês hoje sobre o Spin Cube, que é um projeto que ajuda você a fazer exatamente isso.

[2:36] Então este é um recurso personalizado SpinApp no Kubernetes. Online 6 é uma referência a um artefato OCI contendo... Um binário WebAssembly. Sim, isso é algo que você pode fazer. Por trás deste recurso personalizado SpinApp vive um operador spin. Assim que eu aplicar meu spin app ao meu cluster, vamos vê-lo em execução no nosso cluster aqui.

[3:11] O spin app, o operador spin vai de fato capturá-lo e implantar o pod de implantação e o serviço correspondentes. Ele está configurando o pod para usar um runtime Wasm em vez de um runtime de contêiner para executar nosso aplicativo. Então, por fora, você ainda tem seus pods e serviços, como de costume, mas por dentro, eles são na verdade aplicativos WebAssembly, não contêineres. Este é o mesmo aplicativo. Vamos aumentar a contagem de réplicas para 50, e aplicá-lo ao nosso cluster.

[3:43] Estou executando em um cluster AKS de dois nós aqui. E se eu verificar meus pods, eles estão sendo distribuídos, olhe com atenção nos meus dois nós. Um é um nó x86 e o outro é um nó baseado em ARM da Ampere64. Obrigado. E se eu quiser escalar ainda mais, então posso simplesmente colocar esse mesmo binário em qualquer instância burstable, que é barata para mim naquele momento. Obrigado. Esses são o tipo de coisas que têm sido importantes para a equipe do Grupo Zeiss.

[4:18] E eu gostaria de convidar o Kai agora para falar conosco sobre a experiência deles nesse espaço. Obrigado, Kai. Merci, Michel. Então, vindo da Zeiss, eu me identifico com a física. Como o ARC em nosso logotipo sugere, lidamos com esferas, lentes, óptica. De microscópios até esses blocos volumosos parecidos com pedaços de metal, que são sistemas de litografia de alta NA, que você basicamente precisa para produzir seu amado silício da Apple ou as GPUs da NVIDIA. Esses são os únicos dispositivos ópticos em todo o planeta que podem fazer isso.

[4:58] Então meus especialistas em P&D sempre tentam me explicar esse tipo de óptica, mas não há ajuda nisso, então só consigo entender o básico. Mas o que eu entendo é como operar esses modelos de negócio em tecnologia da informação. Muitos dos nossos modelos de negócio exigem que processemos as informações eletronicamente, seja apenas pela pura escala de informação que temos que processar ou pelas especificações do produto que estão anexadas.

[5:34] Oh. Então, no começo, o dinheiro não é o problema quando iniciamos esses projetos. Nós... Os riscos do projeto são altos, os compromissos são assumidos, e basicamente fizemos um recapeamento completo desse caso. Até passamos um pouco de bondade do CNCF nele, como DAP ou KEDA, tanto faz. Assim que a poeira baixa e o negócio se estabiliza, nosso pessoal de finanças nos alcança, o que então exige que basicamente entremos em uma abordagem mais voltada para o design para custo.

[6:06] Em segundo lugar, muitas vezes no começo, temos o luxo de projetar esses serviços dentro de contextos delimitados, aplicando design orientado a domínio, realmente fazendo bons sistemas. Mais adiante, muitas vezes entram em jogo aspectos logísticos, como tamanhos de runtime de contêiner, limitações de número de peças, tanto faz. E logo somos forçados a ceder basicamente que a granularidade técnica do que executamos diverge da granularidade semântica. E este é um dos pontos pelos quais começamos a investigar o WebAssembly na nuvem, basicamente para aproximar essas duas coisas, a granularidade semântica e a técnica.

[6:58] Para isso, generalizamos um dos nossos muitos fluxos, que reflete como normalmente fazemos esse processamento. Isso significa que recebemos uma série de mensagens ou pedidos na nossa porta, e então a expectativa é que essas mensagens sejam processadas em um determinado tempo. Respondendo: ok, quando, como produzimos ou entregamos aquilo. E é exatamente isso que medimos. Desde a chegada dos pedidos até que eles cheguem a alguns buckets.

[7:30] Agora vamos ver isso em ação. Tchau. Então o que vemos aqui são esses três spin apps que lidaram com a carga e suas respectivas implantações. Então você vê primitivas de Kubernetes bem regulares. Vamos gerar alguma carga. Você vê a forma básica das réplicas. A carga aumenta. O primeiro conjunto de réplicas já recebe o primeiro lote de pedidos. E assim que o ambiente está escalando, o número de pedidos que podem ser processados na mesma fatia de tempo aumenta drasticamente. Primeiro, algumas funções de distribuidor pegam os pedidos, tomam algumas decisões básicas, e então os repassam por filas para uma segunda onda de serviços, que basicamente os colocam em buckets para algumas outras decisões.

[8:20] O que podemos ver aqui é quão rápido os serviços estão escalando e absorvendo o tráfego. Obrigado. No final, a taxa de transferência total ficará em torno de 34 segundos, o que, se você acompanhar outros posts que fiz com outros ambientes, é muito bom. Então, no final, é só física. Ao usar um spin app com artefato WebAssembly em vez de uma implantação regular, podemos, para um aplicativo Node.js Express como esse, reduzir o tamanho de 400 megas para quase 2 megas.

[8:57] Então, mesmo se adicionarmos mais lógica, esse tamanho não aumentará drasticamente. E isso permite que a... que a escala suba rápido e desça também rápido, o que, por outro lado, permite que os mesmos recursos, com uma leve sobreposição, sejam reutilizados já pela segunda, terceira ou quarta onda, qualquer que seja a onda de processamento que você tenha. Assim, podemos usar os mesmos recursos várias vezes dentro de um processo como esse.

[9:29] E isso ainda aplicando todas as ferramentas, todos os ambientes que já conhecemos. Sim. Novamente, para concluir: o tamanho de empacotamento menor permite que coloquemos mais serviços nos mesmos recursos ou, por outro lado, usemos recursos mais baratos para processar o mesmo conjunto de serviços. Podemos escalar para cima e para baixo mais rápido, ter um grau maior de reutilização dos mesmos recursos.

[10:02] mantendo as ferramentas que conhecemos. Aqui novamente em números, mesmo ao mudar apenas de x86 para ARM, pudemos reduzir com 60%, então pudemos usar recursos 60% mais baratos para isso. E com isso, quero passar para o meu irmão de cor de cabelo, Ralph. Obrigado. O que vocês acabaram de ver e ouvir do Kai é o resultado de uma coleção de projetos de código aberto tanto em Go quanto em Rust e fundações de código aberto, obviamente a CNCF e também a Bytecode Alliance Foundation em todo o mundo em colaboração. E quero destacar apenas alguns dos projetos importantes que vocês provavelmente conhecem e que de fato tornam possível esse tipo de inovação.

[10:55] Em primeiro lugar está o Kubernetes. É fácil pensar, quando mencionamos WebAssembly, que de alguma forma não estamos falando de Kubernetes. Estamos. É a maturidade e a estabilidade do Kubernetes como plataforma que nos permitem continuar inovando nele e ao seu redor. E, por exemplo, o projeto Container D na CNCF tem muitos shims diferentes que permitem integrar diferentes tipos de cargas de trabalho ao Kubernetes. E a Microsoft tem muito orgulho de ter criado o projeto Container D baseado em Rust, certo, que permite uma execução a frio, desculpe, e que permite aos contribuidores, junto com pessoas como Fermion, Docker, Second State e muitos outros, usar este projeto para trazer ainda mais flexibilidade e agilidade de escala ao Kubernetes sem afetar os contêineres que você já está usando em seus clusters agora. E a ZEISS não é diferente do que muitos, muitos outros já estão fazendo.

[11:56] Agora, como é construído sobre o RunWazi, o SHIM de Container D do WebAssembly para o spin permite que o Kubernetes escale para cima e para baixo muito rapidamente, como vocês acabaram de ver, mas também mova suas cargas de trabalho WebAssembly de um sistema operacional para outro e de uma CPU para outra em tempo real e sem builds multi-arquitetura. E porque eles permitem que cargas de trabalho WebAssembly sejam executadas no mesmo pod. Como contêineres, você pode continuar usando suas cargas de trabalho, suas cargas de trabalho de contêiner que você usa agora. Agora, finalmente, quero destacar, como coloquei aqui, o framework de operador.

[12:30] E o KWASM da Liquid Reply, esse operador é usado para instalar o SpinShim facilmente. Foi o que Kai e a Zeiss usaram sem exigir um novo cluster. Você não precisa inicializar algo novo. E há uma comunidade por trás de todo esse trabalho, cada coisa que fizemos. Então, a maioria das pessoas, porém, realmente preferiria não procurar ferramentas individuais. Eu sei que muitos de vocês estão curiosos para explorar os detalhes, e vocês podem, porque são projetos.

[13:02] Certo? Mas a maioria das pessoas gostaria de usar uma única pilha de ferramentas. Elas não querem encontrá-las todas juntas e depois alinhá-las da maneira certa e configurar cada uma. Então, trabalhando com o feedback da Zeiss e de outros... Fermion, Microsoft, SUSE e Liquid Reply têm o orgulho de anunciar a criação do SpinCube, que vocês viram no slide anterior, que é uma pilha de código aberto que você pode usar para simplificar a experiência de desenvolver, implantar e operar cargas de trabalho WebAssembly no Kubernetes junto com as suas de contêiner. Agora, o SpinCube inclui um gerenciador de classe de runtime, que cuida da instalação, atualização e desinstalação das cargas de trabalho, dos shims de Container D, como os shims baseados em RunWazi que estamos usando aqui.

[13:44] E para executá-los, na verdade temos uma série de shims. No SpinCube, estamos usando os Shims baseados em RunWazi. uh, shim para o spin, o projeto spin. E para otimizar essas cargas de trabalho, para fazer o que a Zeiss estava fazendo, tentando ajustar a densidade e a agilidade de escala, usamos o operador spin. E juntas, essa pilha muito completa de ferramentas Kubernetes permite que todos aqui e ao redor do mundo sigam em frente e obtenham o melhor de suas cargas de trabalho Kubernetes onde quer que estejam. Adoraríamos que vocês experimentassem o Spin Cube.

[14:16] E a melhor maneira de fazer isso é seguir em frente e escanear o código QR. e nos dizer o que você acha. Entre nos repositórios do projeto, nos dê feedback, e junte-se a nós e ajude-nos a torná-lo ainda melhor do que já é. Agora quero pedir à Michelle que volte aqui por um segundo. Obrigado. Obrigado. E hoje gostaríamos de anunciar que enviamos a solicitação para contribuir com o SpinCube para a CNCF. Muitos de nós na comunidade nativa de nuvem estivemos tão empolgados nos últimos anos com o WebAssembly.

[15:00] tem muitas pessoas e você tem muitos projetos trabalhando juntos para tornar essa tecnologia mais acessível em nosso ecossistema. E esperamos que você se junte a nós neste esforço de tentar tornar o poder do WebAssembly ainda mais acessível e aproveitável em nosso espaço. E se você quiser saber mais, estaremos no estande da Microsoft, bem como no estande da Fermion. E temos uma palestra mais tarde hoje às 2.30 no S3, SO6. Muito obrigado.