Zero cold starts: agentes de IA serverless no Akamai Functions — Thorsten Hans

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Zero Cold Starts: Serverless AI Agents on Akamai Functions — Thorsten Hans · Canal: AI Engineer · 22:35 · Assistir no YouTube

Tópicos: Agentes de IA, Infraestrutura e hardware de IA, Open source e ecossistemas de software

Resumo

Thorsten Hans apresenta uma arquitetura para executar MCPs e agentes de IA globalmente distribuídos usando WebAssembly, Spin e Akamai Functions. Ele demonstra como criar e implantar um servidor MCP com ferramentas e armazenamento persistente, e como desenvolver um agente em TypeScript usando o Vercel AI SDK. A plataforma distribui as aplicações para regiões próximas dos usuários e promete inicialização em menos de meio milissegundo. A palestra também destaca a portabilidade, a redução do trabalho operacional e a possibilidade de usar diferentes linguagens compatíveis com WebAssembly.

Pontos-chave

Arquiteturas tradicionais em regiões específicas podem gerar latência para usuários distantes e atrasos de cold start ao escalar.
WebAssembly permite empacotar aplicações de servidor em componentes pequenos, portáteis e rápidos de executar.
Spin reúne CLI, runtime e SDKs para desenvolver e executar aplicações WebAssembly.
Akamai Functions é apresentada como uma plataforma serverless global com cold starts por requisição em menos de meio milissegundo, em média.
WMCP ajuda a compor servidores MCP a partir das ferramentas, recursos e prompts definidos pelo desenvolvedor.
O exemplo de servidor MCP usa um armazenamento de chave-valor que funciona com SQLite no ambiente local e com o armazenamento distribuído da plataforma em produção.
Um agente criado com TypeScript e Vercel AI SDK pode ser implantado com Spin e usar ferramentas como jogar cara ou coroa e lançar dados.
Para aplicações JavaScript, a palestra descreve a criação de um snapshot de memória durante a compilação para acelerar a inicialização.
O fluxo de trabalho demonstrado é desenvolver a aplicação, testá-la localmente com Spin e implantá-la com um comando.
A portabilidade para runtimes compatíveis com WebAssembly e a redução das tarefas de infraestrutura são benefícios destacados.

Capítulos

Início	Capítulo	Resumo
00:01	Desafios de latência e cold starts	O palestrante apresenta os limites de arquiteturas regionais e introduz WebAssembly como base para aplicações de edge.
02:44	Spin e Akamai Functions	A palestra explica os componentes do Spin e as características serverless e globais do Akamai Functions.
06:28	Criação e implantação de um servidor MCP	Uma demonstração mostra como definir ferramentas, compor um servidor MCP e implantá-lo com armazenamento persistente.
10:46	MCP distribuído e integração com um cliente	O palestrante implanta um servidor de decisões e demonstra seu uso por um cliente compatível com MCP.
15:51	Agente de IA em WebAssembly	A demonstração cria e implanta um agente em TypeScript, explica a otimização do runtime e observa a latência de uma chamada ao LLM.
20:11	Fluxo de trabalho e conclusões	A palestra resume o processo de desenvolvimento e destaca portabilidade, padrões abertos, velocidade e menor carga operacional.

Citações

Em média, conseguimos inicializar em menos de meio milissegundo. — 04:52

Posso combinar isso com spin aka deploy. — 12:29

Cada aplicação WebAssembly escrita em JavaScript é mais rápida do que uma aplicação JavaScript nativa em cold starts e desempenho de execução. — 18:01

Você só precisa de spin aka deploy. — 21:17

Conceitos e entidades

Spin (ferramenta): Projeto da CNCF que oferece CLI, runtime e SDKs para criar e executar aplicações WebAssembly.
Akamai Functions (ferramenta): Plataforma serverless global apresentada para executar aplicações WebAssembly com inicialização rápida.
WebAssembly (conceito): Formato de código portátil usado na palestra para empacotar e executar aplicações no servidor.
MCP (conceito): Protocolo usado para conectar clientes a servidores que oferecem ferramentas, recursos e prompts.
WMCP (ferramenta): CLI integrada ao Spin que auxilia na criação e composição de servidores MCP.
Vercel AI SDK (ferramenta): SDK que o palestrante usa como opção para criar agentes de IA em TypeScript.
Thorsten Hans (pessoa): Palestrante e senior developer advocate que apresenta a arquitetura e as demonstrações.
CNCF (empresa): Organização mencionada como responsável pelo projeto Spin.
SQLite (ferramenta): Banco de dados usado por Spin para fornecer armazenamento de chave-valor durante o desenvolvimento local.
StarlingMonkey (ferramenta): Runtime JavaScript otimizado mencionado como parte da estratégia de inicialização rápida.

Tradução completa (pt-BR)

00:01 [música] Sejam todos bem-vindos. Obrigado por participarem da minha palestra. Nos próximos 20 minutos, quero apresentar como vocês podem criar agents ultrarrápidos e MCPs com Spin e executá-los em uma distribuição global. Meu nome é Thorsten. Trabalho como defensor sênior de desenvolvedores na Akamai e acho que todos vocês já criaram

00:33 MCPs ou agents, e eles não são diferentes de qualquer outro tipo de aplicação. Portanto, obviamente, exigem tempos de resposta muito rápidos para que possamos oferecer a melhor experiência possível aos usuários. No entanto, arquiteturas ou infraestruturas tradicionais limitadas a uma região não dão conta quando queremos alcançar um público global, e elas trazem alguns atritos que levaram ao surgimento de arquiteturas nativas de edge. Então, obviamente, a latência é

01:06 uma das maiores preocupações, dependendo de onde você implanta seus MCPs ou agents. Eles podem ser rápidos para uma parte do seu público global, mas outras pessoas podem ter uma latência muito menor e, consequentemente, uma experiência muito pior. Isso depende da sua unidade distribuível, certo? Mesmo que você escolha contêineres ou VMs, pode haver um atraso de cold start que varia de vários segundos a

01:38 vários minutos, especialmente quando é preciso escalar muito rapidamente para atender a uma demanda inesperada dos usuários. No entanto, é claro que podemos superar isso superdimensionando a infraestrutura. Mas manter muitos contêineres ou servidores ativos sem realmente utilizá-los resulta, obviamente, em gastos maiores com a nuvem e não é sustentável do ponto de vista ambiental. Por isso, existem soluções de nível mais alto

02:10 que podemos usar para executar MCPs ou agents, mas elas geralmente vêm com SDKs proprietários, unidades implantáveis próprias ou têm um jeito específico de serem tratadas para funcionar em um ambiente de produção. Depois que você entende essas restrições, sair dessas soluções ou migrar suas cargas de trabalho, seus agents, para outro provedor de nuvem ou outro tipo de infraestrutura costuma ser bastante complexo e extremamente caro. Mas

02:44 há uma solução para isso, que envolve uma nova maneira de nós, engenheiros, criarmos aplicações de backend ou do lado do servidor: adotando WebAssembly no lado do servidor. Pense no WebAssembly como algo que está para as máquinas virtuais assim como os contêineres. São binários minúsculos, fáceis de distribuir, muito rápidos para executar e portáteis. O que chamo de stack de IA nativa de edge

03:15 é uma combinação de um projeto da CNCF chamado Spin e do Akamai Functions. Um runtime no qual você pode executar essas aplicações WebAssembly. Então, vamos falar um pouco sobre Spin. Como eu disse, Spin é um projeto da CNCF independente de fornecedor, que permite criar aplicações WebAssembly destinadas a serem executadas no servidor ou na nuvem. Spin tem três pilares principais. É uma CLI que nós, desenvolvedores, usamos para lidar com todas as nossas

03:47 tarefas do dia a dia, tudo o que vocês conhecem do ciclo interno de desenvolvimento. É um runtime baseado em WAMR que nos permite executar esse tipo de aplicação localmente, em microcontroladores ou em ambientes com recursos limitados. Por último, Spin nos oferece SDKs específicos para cada linguagem, para aumentar a produtividade dos desenvolvedores em tarefas cotidianas, como interagir com serviços HTTP, interagir com bancos de dados ou fazer vários outros tipos de coisas.

04:22 Embora tenhamos SDKs específicos para cada linguagem, Spin é independente de linguagem, e você pode escolher entre todas as linguagens que podem ser compiladas para WebAssembly, incluindo a WebAssembly System Interface, ou WASI. Você pode saber mais sobre Spin em spinframework.dev. Leia este QR code para acessar a documentação do Spin. Spin é a ferramenta de desenvolvimento que usamos para criar esse tipo de aplicação.

04:52 O Akamai Functions é a primeira plataforma de computação verdadeiramente serverless com distribuição global e sem cold start. Cada aplicação que você implanta no Akamai Functions inicia a frio a cada requisição que chega ao seu endpoint e, em média, conseguimos iniciar a frio em menos de meio milissegundo. A plataforma é totalmente gerenciada e, mais uma vez, centrada nos desenvolvedores. Seus desenvolvedores implantam a carga de trabalho. Não há configurações para ajustar nem Terraform para escrever, apenas uma simples

05:23 linha de comando, e sua aplicação é distribuída globalmente sem custo adicional. A segurança é garantida pelo sandbox do WebAssembly. Assim, uma carga de trabalho não pode interagir com recursos externos sem que nós, desenvolvedores, concedamos explicitamente essas permissões. E, para ser uma plataforma completa de computação serverless na edge, precisamos de algum tipo de camada de persistência. Por isso, o Akamai Functions vem com um armazenamento

05:54 de chave-valor integrado que, mais uma vez, é multi-tenant. Você não precisa gerenciar credenciais. Ele é associado automaticamente à sua aplicação, caso você queira usá-lo. Há outro QR code. Leia-o para saber mais sobre o Akamai Functions. Cadastre-se para um período de avaliação ou uma conta gratuita e explore a plataforma. Essas são as bases técnicas que quero usar para criar meus primeiros servidores MCP. Então, em vez de criar um novo servidor MCP do zero,

06:28 quero dizer, podemos implementar o protocolo HTTP ou a API especificada sobre HTTP para criar um MCP. Mas há uma maneira mais inteligente de fazer isso, que é o WMCP. WMCP também é uma CLI que se integra perfeitamente ao Spin. O que isso nos permite fazer é basicamente nos concentrarmos apenas na lógica de negócios. No contexto de um MCP, a lógica de negócios significa implementar nossas tools, nossos recursos ou prompts, e pronto.

07:00 Todo o resto, todos os requisitos não funcionais com os quais precisamos lidar, certo? Por exemplo, autenticar usuários usando OAuth 2 e OIDC. O WMCP cuida disso. Depois, pegamos componentes prontos para usar, disponíveis no mercado, e os combinamos para montar um componente de servidor MCP completo, que executamos no Spin ou no Akamai Functions. E é isso que vamos fazer agora. Então, eu

07:31 instalei o WMCP na minha máquina. O endereço é github.com/wmcp/wasmcp, e ele oferece uma pequena CLI bem prática. Podemos executar wmcp new. Podemos escolher uma linguagem: Rust, TypeScript ou Python. E podemos escolher entre modelos. Por enquanto, o modelo padrão é aquele em que só me preocupo com tools. Vamos chamar este novo servidor MCP de hello. Recebemos instruções: entre no diretório hello. Hello.

08:02 Agora, vamos abrir um novo terminal deste lado. Entre também no diretório hello aqui. E vamos executar npm install, porque isso leva alguns segundos. Vamos abrir este projeto no editor e colocá-lo em tela cheia. O que temos aqui? Um boilerplate pronto para usar, e aquelas linhas onduladas vão desaparecer quando o npm install terminar. Só precisamos declarar o esquema das entradas que

08:36 esperamos. Obviamente, precisamos fornecer a lista das nossas tools. Então, precisamos ser bons cidadãos e fornecer descrições precisas, para que as pessoas e os LLMs saibam como lidar com esse tipo de tool. Nós as listamos em um array simples e, em seguida, há uma função de entrada chamada call tool. Dependendo do payload que recebemos, precisamos decidir qual tool executar. Se abrirmos o exemplo de

09:06 tool aqui, podemos ver que todos os argumentos recebidos são validados e, se estiver tudo certo, concatenamos a entrada recebida com um prefixo e a devolvemos ao usuário. Nada de especial. Vamos fechar o editor e seguir as instruções. O próximo item da lista é make. O make pega o código JavaScript e o compila para WebAssembly. Assim, obtemos um componente WebAssembly de tools, que ainda não é um

09:40 servidor MCP completo. O próximo passo é wmcp compose. Vamos montar um MCP completo usando nossas tools e dizendo: “Por favor, crie um MCP para esta demonstração. Não me importo com autenticação.” Certo, ele baixa todos os outros componentes necessários, monta um servidor MCP e me dá instruções para executá-lo. Posso executar spin up -f server.wasm, e devemos vê-lo em execução em

10:13 localhost 3000. Certo, vamos voltar ao outro terminal e executar o npx MCP Inspector aqui. Isso deve abrir no navegador. Aí está. Ele já está apontando para localhost 3000 aqui. Então, vamos conectar. Vamos listar as ferramentas. Aqui está nossa ferramenta de exemplo. Fornecemos “fu” como parâmetro de entrada. Executamos a ferramenta e devemos receber “foo”. Ótimo. Nada sofisticado, funciona bem. Mas essa é a experiência local. Então, como podemos transformar isso em algo glo

10:46 balmente distribuído? Ou como podemos transformar isso em um servidor MCP distribuído globalmente? Bem, em vez de distribuir globalmente o servidor MCP de Hello World, tenho um servidor MCP de registro de decisões. Vou abrir este primeiro. Ele foi implementado em Rust pelo simples propósito de implementá-lo em Rust. Então, vamos entrar em lib.rs aqui. Há uma classe ou estrutura equivalente em Rust. Como você pode ver, estamos olhando para a função call tool, na qual fazemos uma ramificação

11:19 e usamos uma das APIs CRUD ou ferramentas fornecidas pelo meu servidor MCP. Se entrarmos na implementação de fato, deixa eu… não, isso está errado. Quero isto e depois aquilo: decision.rs. Se formos até o fim do arquivo, vocês verão que a sintaxe é um pouco diferente, mas o significado é o mesmo, certo? Tenho que definir minhas ferramentas. Se formos para a linha 15, mais ou menos… sim, list decisions. Vocês podem ver aqui que uso um armazenamento. Então, na minha

11:55 máquina local, o Spin reconhece que o Thorsten quer usar o armazenamento de chave-valor, então cria automaticamente um armazenamento de chave-valor usando SQLite na minha máquina, para fins de desenvolvimento. Já no Akamai Functions, ele usa o armazenamento de chave-valor distribuído globalmente, sem que eu precise configurar nada. A partir daqui, a história é a mesma, certo? Tenho que usar esse Makefile e compor o servidor. No entanto, acho que é melhor atualizar o manifesto da aplicação

12:29 e concatenar essas tarefas para que eu possa continuar com a experiência de desenvolvimento do Spin e, basicamente, executar spin build para compor e compilar meu servidor MCP. No entanto, também posso combinar isso com spin akamai deploy. Isso compõe o servidor e me pergunta como quero chamar esse servidor MCP no Akamai Functions. Vou chamá-lo de

13:02 ADR MCP. Permito que meu terminal interaja com o registro de serviços. Agora ele pegou meu arquivo Wom e meu manifesto da aplicação, gerou camadas OCI a partir desses arquivos e as enviou para o Akamai Functions, no lado do servidor ou do serviço. Recebemos esses dois arquivos e os distribuímos pelo mundo, em todas as regiões de serviço. Cada região precisa confirmar que recebeu a carga de trabalho e que é capaz de executá-la.

13:37 Em seguida, instanciamos a carga de trabalho uma vez e fazemos uma verificação interna de integridade. Quando recebemos uma resposta HTTP 200 de todas as regiões de serviço, criamos um subdomínio genérico em seu nome, para que seu servidor MCP fique disponível na internet pública. Obviamente, você pode protegê-lo com outros produtos e serviços, como o Property Manager, para colocá-lo atrás do que quiser aplicar antes de encaminhar os usuários ao servidor MCP. Então

14:12 recebemos essa URL. Estamos distribuídos globalmente em cerca de 60 segundos. Vamos passar para um cliente. Estou usando o Z aqui, mas isso funciona com qualquer cliente que ofereça suporte a MCP. Adiciono um servidor. Vou para “Remote” aqui e substituo este pela URL que recebemos. Adiciono o servidor. E podemos ver que já tenho cinco ferramentas. Posso vir aqui e selecionar “View tools”. Essas são as ferramentas CRUD definidas pelo meu MCP. Então, posso

14:47 voltar e conversar com minha IDE no contexto do meu projeto, para que ela possa usar meu servidor MCP. “Registrar uma decisão de usar o 2.0 Hello para…” Certo, agora ele deve identificar minha intenção e pedir permissão para executar a ferramenta insert decision. Podemos ver a entrada bruta. Parece bom. Permitimos. Agora ele chama o Akamai Functions, que já registrou minha

15:18 decisão, e posso dizer: “Mostre todas as decisões, por favor”. Agora, a intenção é usar a ferramenta list decisions e, de novo, sim, talvez ele queira ler os detalhes para me mostrar tudo o que registrou. Com isso, temos um servidor MCP distribuído globalmente, que encaminha todas as solicitações para a região de serviço mais próxima, não importa

15:51 onde estejam seus usuários. E, mais uma vez, você pode escrever essas ferramentas, prompts ou recursos usando os templates de TypeScript, Python ou Rust. Legal. Vamos passar para os agents. Então, opa, não, este aqui. Para agents de IA, a história não é diferente. No entanto, em vez de usar outra CLI, podemos simplesmente escolher qualquer SDK disponível que seja popular. Acho que o AI SDK da Vercel é bem legal de usar. Isso nos permite

16:25 basicamente criar um novo app Spin usando TypeScript. Basta adicionar as dependências de AI da Vercel para criar agents personalizados. Vamos voltar ao terminal para ver como isso funciona. Vamos subir um diretório e entrar em simple game agent aqui. O que está acontecendo aqui? Obviamente, criei um novo app Spin usando um template para começar bem rápido. Estou usando um modelo de linguagem de grande porte implantado em uma instância da Linode com uma GPU dedicada. E meu app Spin só define as ferramentas. Então, este é um agente de jogo simples, para fins de demonstração, que pode jogar cara ou coroa e rolar um dado, cujo número de lados você pode especificar. E aqui, no manipulador HTTP de fato, carregamos a configuração e definimos nosso agent, apontando para a instância do Ollama em execução no nó. Damos

16:56 ao nosso agent uma identidade e uma instrução sobre qual é sua intenção. Registramos nossas ferramentas e definimos algumas restrições sobre quantas etapas ele pode executar. Geramos uma resposta e a devolvemos ao chamador. Certo, vamos executar quit all aqui e fazer outro spin aka deploy, sem confirmação, build. Ele pergunta o nome: game agent. Enquanto ele faz o upload, deixa eu

17:28 explicar o que acontece quando compilamos uma linguagem interpretada. Durante a compilação, carregamos o interpretador, carregamos seu JavaScript personalizado e avaliamos o escopo global. Isso tem uma vantagem: não é só o runtime que fica aquecido; todas as dependências também são carregadas. Depois, tiramos um snapshot da memória, gravamos isso em WASM e armazenamos em disco. Isso significa que toda aplicação WebAssembly escrita em JavaScript é mais rápida do que uma aplicação JavaScript nativa em inicializações a frio e desempenho em runtime.

18:01 A única desvantagem é que precisamos enviar o runtime JavaScript junto com nosso código. Mas usamos um runtime JavaScript otimizado chamado Stalling Monkey, que tem cerca de 10 megabytes. Então, recebemos uma URL. Vou substituir esta URL aqui. E vamos dizer: “Jogue uma moeda”. E vemos uma resposta.

18:32 E, se olharmos esses cabeçalhos, podemos ver que o ponto de presença pelo qual entramos na rede da Akamai é Santa Clara, e a região de serviço mais próxima do nosso agente de IA é LAX. Outro cabeçalho interessante é X-envoy-upstream-service-time. Ele me diz — e diz a vocês também — que foram necessários 33, 34 milissegundos para receber a solicitação, executar a lógica de negócios, consultar o modelo de linguagem de grande porte, gerar uma resposta e voltar

19:05 até o usuário. Ah, ocorreu um erro interno do servidor. Ótimo. Maravilha. Vamos tentar de novo. Ah, sim. Foi um erro do usuário. Desculpe. O erro foi ficar a 30 centímetros da tela. Olhando agora, estamos em 866 milissegundos. Isso é mais realista, porque precisamos passar pelo LLM para descobrir que o resultado do nosso lançamento foi coroa. Vamos fazer de novo. Coroa, coroa, coroa, coroa. Ah, saiu cara. Legal. Cerca de 820

19:37 de volta até o usuário. Ah, ocorreu um erro interno do servidor. Ótimo. Excelente. Vamos tentar de novo. Ah, sim. Foi um erro do usuário. Desculpe. Então, o erro foi ficar a 30 cm da tela. Olhando agora, estamos em 866 milissegundos. Isso é mais realista, porque precisamos passar pelo LLM para basicamente verificar se o nosso lançamento resultou em coroa. Vamos fazer isso de novo. Coroa, coroa, coroa, coroa. Ah, saiu cara. Legal. Então, cerca de 820

20:11 milissegundos foi o que conseguimos alcançar com um ciclo completo pelo LLM, levando nosso agent e fazendo o deploy dele em uma functions. Certo, então o workflow de desenvolvimento é sempre o mesmo. Não importa se você cria qualquer tipo de aplicação de linha de negócios, se cria um MCP ou se cria um agent: você implementa sua aplicação usando qualquer linguagem que possa ser compilada para WebAssembly. Rust, TypeScript, Python e Go são as mais proeminentes atualmente. Você pode testá-la localmente com o Spin CLI. Você

20:46 faz o deploy dela usando um único comando chamado spin deploy. E, por fim, você direciona seus clientes para seu MCP ou para seu agent. Então, as principais conclusões do meu ponto de vista são portabilidade. Você pode pegar esses apps do Spin e executá-los em qualquer runtime compatível com WASI. O Akamai Functions é um runtime e é o runtime distribuído globalmente. Tudo é baseado em padrões abertos. Portanto, Spin, CNCF, WASI e WebAssembly são regidos pela

21:17 Bytecode Alliance. Mas, no fim das contas, você ganha velocidade, certo? Você tem tempos de resposta rápidos. Até o tempo de lançamento no mercado para seus desenvolvedores criarem MCPs e agents diminui, porque você não precisa montar a infraestrutura. Não precisa implementar requisitos não funcionais. Tudo isso já é resolvido. E, em termos de infraestrutura, não há operações para gerenciar. O Spin, também chamado de deploy, é tudo de que você precisa. Há outros comandos disponíveis para que você possa coletar métricas, recuperar logs, fazer upgrade e assim por diante. Mas

21:51 a experiência do desenvolvedor é nossa métrica mais importante desde que começamos o Spin, e continuamos seguindo nessa direção. Temos um novo site, chamado Akamai Developer Hub, onde compartilhamos histórias, experimentos e experiências como estas. Então, acesse developers.akamai.com. E, se tiver mais alguma dúvida, me encontre no estande da Akamai. Com isso, muito obrigado.

22:35 [música]

Transcrição original

[00:01] [music] Welcome everybody. Thanks for joining my talk. In the upcoming 20 minutes, I want to give you an introduction on how you can build ultraast agents and MCPs with spin and run them globally distributed. So my name is Tossen. I work as a senior developer advocate with Ecomi and um I guess all of you have already built

[00:33] either MCPS or agents and they are no different than any other kind of application. So they obviously demand super fast response times so that we can deliver the best possible user experience. However, traditional regionbound architectures or infrastructures fall short when you want to address a global audience and they they come with some frictions which lead to the inception of edge native architectures. So obviously latency is

[01:06] one of the biggest concerns depending on where you deploy your MCPs or your agents. It might be fast for a subset of your global audience, but others might experience a way lower latency and resulting in a way worse user experience. Um, depending on your distributable unit, right? Even so, if you even either choose containers or VMs, you may experience a cold start delay that might range from several seconds up to

[01:38] multiple minutes, especially when you have to scale dramatically fast to meet unexpected user demand. However, we can overcome that obviously uh by overprovisioning the infrastructure. However, keeping around many many containers or servers and actually not utilizing them results in obviously higher cloud spendings and is not sustainable from an environmental footprint. So there are higher level solutions uh

[02:10] that we can use to run MCPS or agents but they usually or often come with proprietary SDKs or uh deployable units or have their own way on how you should treat them in order to make them work in a production grade environment. Once you figured out about those constraints, moving away or migrating your workloads, your agents to another hyperscala to another kind of infrastructure, it’s often rather complex and extremely costly. So, but

[02:44] there’s a solution to that and that solution involves a new way of how we as engineers could build backend or serverside applications and this is done by adopting web assembly on the server side. You can think of web assembly as um as containers relate to virtual machines. So, they are binaries super tiny in size, easy to distribute, super fast to run and portable. What I refer to as the edge native AI

[03:15] stack is a combination of a CNCF project called spin and echcomi functions. One runtime where you can run those web assembly applications. So let’s dive into spin for a minute. Uh spin as I said is a CNCF project that is vendor agnostic and it allows you to build web assembly applications that are meant to be executed on the server or in the cloud. Spin itself consists of three major pillars. So it is a CLI that we as developers use to address all our

[03:47] day-to-day concerns. So everything you know in the realm of the inner loop. It is a runtime. So it’s based on WM time um that allows us to run these kinds of applications either locally or on microcontrollers or constrained environments. Last but not least, Spin gives us language specific SDKs to boost the developer productivity when it comes to day-to-day jobs like for example interacting with HTTP services, integrate interacting with databases or different kind of things.

[04:22] Although we have language specific SDKs, spin itself is language agnostic and you can choose from all the languages that are able to be compiled down to web assembly including the web assembly system interface or shortwi and you can learn more about spin on spin framework.dev. So scan this QR code and you will end up on the spin documentation. So spin is the developer tool that we use for building these kinds of applications.

[04:52] Echi functions is the first truly serverless computing platform that is globally distributed and has zero cold start at all. So every application that you deploy to Ecomi functions is cold started per request that hits your endpoint and on average we can cold start in less than half a millisecond. It’s fully managed and it’s again developer centric. Your developers deploy the workload. No knobs to turn, no terraform to write, just a simple

[05:23] oneliner and your app is globally distributed at no extra cost. Security is um is observed by web assembly’s sandbox. So there’s no way a workload could interact with external resources without us as developers explicitly granting those permissions to our workloads. And to be a full-fledged serverless computing platform at the edge, we need some kind of persistence layer. So Echami functions comes with a built-in

[05:54] key value store that is again multi-tenant. You don’t have to roll credentials. It is automatically associated to your app if your intent is to use it. Again, there is a QR code. Scan that and you can find out more about Echo My Functions. Sign up for a trial or a free a free account there and you know explore it. So these are the technical underpinnings that I want to use in order to build first MCP servers. So instead of handrolling a new MCP

[06:28] server, I mean we can implement the HTTP protocol or the uh the specified API on top of HTTP to build an MCP. There is a smarter way of doing that and a smarter way is WMCP. WMCP again is a CLI that integrates seamlessly with spin. So what it what this allows us to do is basically to focus just on the business logic and in in the in the realm of an MCP business logic basically means we implement our tools we implement our resources or prompts and we are good to

[07:00] go everything else all those non-functional requirements that we have to tackle right like for example authenticating users using of 2 and OIDC that’s done by WMCP and we then take readyto-use components off the shelf and compose a final MCP server component together and run that on spin or on a myi functions and that’s what we are going to do right now. So I have

[07:31] installed wmcp on my machine it’s github.com wmcpwasmcp and it gives you a nice little CLI. So we can do womcp new. We can choose a language, Rust, TypeScript, uh, Python. And we can choose from templates. The default template is me only caring about tools for now. And let’s call this new MCP server hello. We get instructions. Hey, move into hello. Uh, hello.

[08:02] Then let’s open up a new terminal on this side. CD into hello over here as well. And let’s run npm install because that takes a few seconds. And let’s open this one in the editor and let’s do this full screen. So what do we get over here? Uh we get a boiler plate that’s uh ready to use and those squirrel lines will go away once mp npm install is done. So all we have to do is we have to express the scheme on which inputs we

[08:36] expect. We have obviously to provide the list of our tools. So again we have to be good citizen over here and have to provide precise descriptions so that humans and LLMs know how to handle these kind of tools. So we list them in a simple array and then there’s one ingestion function that’s called call tool and depending on uh the the payload that we receive we have to decide which tool we have to execute. If we jump into handle example

[09:06] tool over here, we can see uh all incoming arguments are validated and if everything’s fine, then we basically uh concaten concatenate the received input with a prefix and return that back to the user. Nothing fancy. So let’s close the editor over here and follow the instructions. Next on list is make. make goes on and takes the JavaScript code, compiles that down to web assembly. So we end up with a tools web assembly component which is not yet a

[09:40] full-fledged uh MCP server. Next in line would be where MCP compose. Let’s compose a full-fledged MCP by taking our tools and saying hey please give me an MCP for the sake of this demo. I don’t care about authentication. Okay, it pulls all the necessary uh other components and composes together an MCP server and gives me instructions on how to run that. I can do a spin up -f server.wazm and we should see that running on

[10:13] localhost 3000. Okay, let’s bring back the other terminal and let’s run np npx the uh mcp inspector over here. That should fire up in the browser. There we go. Uh it’s already pointing to localhost 3000 right here. So let’s connect. Let’s list tools. There’s our example tool. We provide fu as an input parameter. We run the tool and we should get back foo. Great. Nothing fancy cool works. But that’s the local experience. So how can we take that to become a glo

[10:46] or how can we turn that into a globally distributed MCP server? Well, instead of globally distributing uh the hello world MCP server, I have a decision lock MCP server and let me open up this one first. So there is this one is implemented in Rust for the sake of implementing it in Rust. Um so let’s go into lip RS over here. There is an equivalent class or structure in Rust. As you can see, we’re looking at the call tool function where we branch out

[11:19] and either use one of the CRUD APIs or tools that is provided by my MCP server. If we dive into the actual implementation um let me no this is wrong. I want this and then I want to do that uh decision. RS if we go to the bottom of the file you can see this is slightly different syntax but the same meaning right I have to define my tools and if we go to line 15 or so yes list decisions you can see over here that I use a store so on my

[11:55] local machine spin recognizes hey toen wants to use the key value store so it automatically creates a key value store using SQLite on my machine for development time purposes and on ecom myi functions it’s leveraging the globally distributed um key value store without me having to configure anything from here it’s actually the same story right I have to use that make file and compose the server however I think it’s smarter to update the application

[12:29] manifest and concatenate those tasks so that I can remain in the spin developer experience and basically do a spin build to compile compose and compile my MCP server. However, I can also combine this one with spin ecomi deploy. So this right now composes the server asks me hey how do you want to call that MCP server on a my functions? I call it

[13:02] ADR MCP. I allow um my terminal to interact with the service registry. Now it’s taken my Wom file and my application uh manifest generating OCI layers from those files uploading them to Echcomi functions on the server side or on the service side. We receive those two files and we distribute them across the globe through all the service regions. Every region has to confirm a that it received the workload that is capable of running the

[13:37] workload. Then we instantiate the workload once and do a internal health check. And once that came back for all the service regions with an HTTP 200 then we roll a generic subdomain on your behalf so that you that your MCP server will be on the public internet. Obviously you can shield that with other products and services uh like the property manager to shield it behind whatever you want to enforce before uh forwarding users to the MCP server. So

[14:12] we get that URL. So we are globally distributed in roughly 60 seconds. Let’s move over to an uh to a client. I use Z over here but that works with any client that basically supports MCP. I add a server. I go to remote over here and let me replace this one with the URL that we received. Add the server. And we can see I have five tools already. I can go here and say view tools. And these are the CRUD tools that my MCP defined. So I can

[14:47] go back and chat with my IDE in the context of my project so that it could leverage uh my MCP server. track a decision to use or of 2.0 Hello for awful. Okay, so it should now identify my intent and ask permission to run the insert decision tool. We can see the raw input. Looks good. We allow it. It now calls out to echo my functions has already has already tracked my

[15:18] decision and I can say give me all the decisions please. Now the intent is to use the list decisions tool and again we are uh yes it might want to read uh details to give me everything that it tracked or and uh with that we have a globally distributed um MCP server that’s routing all the requests to the closest service region no matter

[15:51] where your users are and again you can write those tools or prompts or resources using TypeScript, Python or Rust templates. Cool. Uh let’s move on with agents. Um so, oops, nope, this one. So, for AI agents, the story is no different. However, instead of using another CLI, uh we can simply pick any kind of SDK that’s out there and that’s popular. Um I I think the Verscel AI SDK is pretty nice to use. So this allows us

[16:25] basically to create a new spin app using TypeScript. Just bring in the Versal AI dependencies and to build custom agents. Again, let’s move back to the terminal to see how that looks like. Uh so let’s move one up and let’s CD into a simple game agent over here. And what’s going on over here? Obviously, I have created a new spin app using a template so that I can get started pretty quickly. I’m leveraging a large

[16:56] language model deployed to a Lenode instance with a dedicated GPU. And all my spin app does it defines the tools. So, this is a simple game agent for the sake of demonstration purposes that can flip co flip coins that can roll a dice where you can specify how many sides that dice should have. And over here in the actual HTTP handler, we load the config and we define our agent, you know, pointing it to the old lama instance running on the node. We give

[17:28] our agent an identity and an instruction on what its intent actually is. We register our tools and we give it some constraints of of how many steps it might take. We generate a response and return it back to the collie. Okay, let’s uh go let’s do a quit all over here and let’s do another spin aka deploy no confirm build and it asks for the name that’s the game agent. So while it is uploading let me

[18:01] explain what happens when we compile a lang an interpreted language. So during compilation time we load the interpreter, we load your custom JavaScript and then we evaluate the global scope. This has one advantage that not just the runtime is hot also all the dependencies are loaded and then we take a memory snapshot write that to WM store that on disk meaning that every web assembly application written in JavaScript is faster than a native

[18:32] JavaScript application when it comes to cold starts and runtime performance. The only trade-off though is that we have to ship the JavaScript runtime along with our um with our user code. But we use an optimized JavaScript runtime called stalling monkey which is roughly 10 megabytes in size. So we get back an URL. Let me replace this URL over here. And let’s say toss a coin. And we see um we see a response back.

[19:05] And if we look at these headers, we can see uh the point of presence where we enter the Ecomi network is Santa Clara and the closest service region for our AI agent is LAX. Another interesting header is X envoy upstream service time. And this tells me and you right now as well that it took 33 34 milliseconds to receive the request to run through the business logic to reach out to the large language model to generate a response and to go

[19:37] all the way back to the user. Oh, there’s an internal server error. Great. Awesome. Let’s try this again. Oh, yeah. That was an user error. Sorry. So, the error was staying 30 cmters in front of the screen. Um looking at it now we are 866 milliseconds. Um that is more realistic because we have to go through the LLM to basically see that uh our to our toss resulted in tails. Let’s do that again. Tails tails tails tails. Oh, there’s a hat. Nice. So roughly 820

[20:11] milliseconds is what we could achieve with a full loop through the LLM by taking our agent and deploying it to a functions. Okay, so the developer workflow is always the same. No matter if you build any kind of line of business application, if you build an MCP or if you build an agent, you implement your application using any language that you could compile down to web assembly. Rust, TypeScript, Python, Go are the most prominent ones these days. You can test it locally with the spin CLI. You

[20:46] deploy it using a single command called spin a deploy. And finally, your you point your clients to your MCP or to your agent. So final or key takeaways from my from my point are portability. You can take those spin apps and run them on any Wii compliant runtime. Echi functions is one runtime and it’s the globally distributed runtime. Everything is based on open standards. So spinners, CNCF, Wesi, Web Assembly are governed by the

[21:17] bite code alliance. But ultimately you gain speed, right? You have fast response times. Even the time to market for your developers to build MCPs and to build agent goes down because you don’t have to roll the infrastructure. You don’t have to implement non-functional requirements. That’s all taken care of. And in terms of infrastructure, there’s no ops. It’s spin aka deploy is all you need. There are other commands in the box so that you can g gather metrics that you can retrieve logs that you can upgrade and so on and so forth. But

[21:51] developer experience is our our highest metric when we started spin and while we continue in that direction. Um we have a new website that’s called the Ecomi developer hub where we share stories and experiments and and experiences like these. So go check out developers.accomi.com. ecomi.com and if you have any further question find me at the Akcomi booth and with that thank you very much.

[22:35] >> [music]