Vou ser sincero com você.
Quando começamos a criar nosso produto de IA, achávamos que o tempo de execução compartilhado era bom. Um grande contêiner, todos os clientes acessam o mesmo endpoint. Fácil, fácil. Envie-o na sexta-feira, depois das cervejas.
Estávamos muito enganados.
Os primeiros 10 clientes? Tudo é lindo
Você implementa. Os clientes se registram. A API responde rapidamente. Os registros estão limpos. Você se sente um gênio.
Você diz ao seu cofundador: "Veja, eu lhe disse que não precisamos do Kubernetes". Dê cinco pontos. A vida é boa.
Então o cliente 11 entra. Ele tem um caso de uso que você não esperava. Eles enviam 400 solicitações por minuto. Seus outros 10 clientes? Todos eles estão recebendo timeouts agora. Sua folga está explodindo.
Mas está tudo bem, certo? Basta adicionar a limitação de taxa. Correção rápida.
Errado. Isso foi apenas o começo.
O que realmente quebra com 50 clientes
Deixe-me explicar o que aconteceu conosco, porque eu gostaria que alguém tivesse me contado isso antes.
**Tivemos um tempo de execução compartilhado com todas as chaves de API do cliente no env. Um manipulador de erros ruim estava registrando o ambiente completo em nossa ferramenta de monitoramento. Não percebemos isso por três semanas. Três semanas de segredos do cliente armazenados no Datadog. Ainda perco o sono com isso.
**O cliente 34 descobriu que podia enviar um prompt que fazia com que o modelo produzisse tokens infinitos. Tempo de execução OOM'd. Todos os 50 clientes caíram. Às 2h47 de uma terça-feira. Pergunte-me como eu sei.
**O desempenho tornou-se imprevisível. O cliente A obtém resposta em 200 ms. A mesma solicitação do cliente B leva 4 segundos. Por quê? Porque o cliente C está executando um trabalho em lote que consome toda a CPU. Não é possível nem mesmo depurar isso em um tempo de execução compartilhado porque o tráfego de todos está misturado.
As solicitações de personalização se acumularam. O cliente corporativo quer o GPT-4. Outro quer o Claude. O terceiro precisa de um prompt de sistema personalizado. Em um tempo de execução compartilhado? Boa sorte. Basicamente, você precisa de sinalizadores de recursos para a infraestrutura. Isso não existe.
A matemática que ninguém faz
Aqui está o que eu gostaria de ter calculado antes de começarmos:
Custo de criação de tempo de execução compartilhado: 2 semanas
Custo de migração de 50 clientes para tempos de execução isolados após a quebra de material: 3 meses
Custo de perder 2 clientes corporativos devido a um vazamento de dados entre locatários: inestimável (e não no bom sentido)
A migração foi brutal. Tivemos que criar um sistema de provisionamento, orquestração de contêineres, gerenciamento de volume, roteamento de DNS, certificados SSL, isolamento de ambiente. Tudo isso enquanto mantínhamos 50 clientes funcionando. Foi como trocar o motor de um avião em pleno voo.
enquanto isso, as pessoas que começaram com o isolamento estão criando produtos reais
enquanto estávamos nos afogando em trabalho de migração, outras equipes estavam enviando produtos reais em tempos de execução isolados desde o primeiro dia:
A ClawField criou um scanner de bot de negociação ao vivo em tempos de execução isolados. Cada entrada dentro de 30 segundos, execução precisa até o segundo. Ele não estava depurando problemas entre locatários. Ele estava criando recursos que geravam dinheiro.
A Max Blade enviou um aplicativo iOS completo que inicia agentes OpenClaw isolados. Sem Telegram, sem chaves de API, sem configuração. Basta fazer login e seu agente estará ativo. Ele criou isso porque não estava preso à manutenção da infraestrutura compartilhada.
Esses são produtos reais de construtores reais. Eles começaram com o isolamento para que pudessem dedicar seu tempo ao produto e não ao encanamento.
Por que ninguém faz a troca até que seja tarde demais
Converso com muitos fundadores que estão criando produtos de IA. Todos eles dizem a mesma coisa:
"Vamos isolar mais tarde, quando tivermos mais clientes"
Essa é a armadilha. No momento em que você tiver clientes suficientes para justificar o isolamento, também terá clientes demais para migrar com segurança. A janela em que é fácil mudar? É agora mesmo. Antes de você ter o problema.
É como os backups. Ninguém se preocupa com backups até perder dados. Então, de repente, é a coisa mais importante do mundo.
Como é, de fato, o isolamento por locatário
Após três meses de migração, eis o resultado final:
- Cada cliente recebe seu próprio contêiner do Docker
- Cada contêiner tem seu próprio volume persistente em
/data - As variáveis de ambiente são completamente separadas por locatário
- Cada cliente recebe um URL exclusivo, como
customer.agents.shipclaw.io - A falha de um cliente não afeta mais ninguém
- Você pode personalizar os limites de modelo, configuração e taxa por cliente
A diferença foi da noite para o dia. Os tíquetes de suporte caíram 80%. Não há mais páginas às 3h da manhã. Os clientes corporativos pararam de ameaçar sair.
"Mas os tempos de execução isolados são caros"
Essa é a objeção que mais ouço. Mais contêineres = mais dinheiro, certo?
Mais ou menos. Mas vamos fazer a matemática real:
Custos de tempo de execução compartilhados:
- Infraestrutura: US$ 200/mês
- resposta a incidentes às 3h da manhã: sua sanidade
- Rotatividade de clientes devido a problemas de confiabilidade: mais de US$ 5 mil por mês em perda de receita
- Negócios empresariais perdidos porque "não podemos garantir o isolamento": ???
- Tempo de engenharia para depuração de problemas entre locatários: 20 horas/semana
Tempos de execução isolados:
- Infraestrutura: US$ 400/mês (sim, é mais)
- incidentes às 3h da manhã: basicamente zero
- Rotatividade de clientes: muito baixa
- Negócios corporativos: agora você pode realmente fechá-los
- Tempo de engenharia em questões de infraestrutura: 2 horas/semana
A infraestrutura custa mais. Todo o resto custa muito menos. Líquido? Você sai muito à frente.
Como fazemos isso agora com o ShipClaw
Depois de passar por todo esse sofrimento, criamos o ShipClaw para que ninguém mais precise fazer isso.
Você abre o construtor visual. Arraste um nó de tempo de execução para a tela. Conecte um Gateway para roteamento. Adicione um Volume para armazenamento persistente. Adicione o Env Config para segredos. Clique em implementar.
É isso mesmo. Cada cliente obtém um tempo de execução do OpenClaw totalmente isolado. Seu próprio contêiner, seu próprio volume, suas próprias variáveis de ambiente, seu próprio URL. Você não escreveu um único Dockerfile ou manifesto do Kubernetes.
Tudo o que levou 3 meses para ser criado manualmente? Agora, a implantação é por arrastar e soltar.
A parte em que eu lhe dou conselhos gratuitos
Se estiver criando um produto de IA para vários clientes, comece com o isolamento desde o primeiro dia. Não me importa se você usa o ShipClaw, se o constrói você mesmo ou se usa outra coisa completamente diferente. Só não faça a coisa do tempo de execução compartilhado.
O débito técnico aumenta rapidamente. O risco de segurança é real. As páginas das 3 da manhã virão. E migrar mais tarde é dez vezes mais difícil do que começar do jeito certo.
Confie em mim. Aprendi isso da maneira mais cara para que você não precise.