osFoundry / Platform
Computação em contêiner
Precisa de processos persistentes? Mude o runtime para um contêiner. Mesmo app, modo diferente.
O que é
A computação em contêiner é um modo de execução para os apps que você cria no osFoundry. A maioria dos apps funciona bem como processos efêmeros, guiados por requisições: sobem, respondem e desligam. Mas algumas cargas de trabalho precisam de algo que continue vivo: um servidor WebSocket mantendo conexões abertas, um worker em segundo plano esvaziando uma fila, um agendador batendo o próprio relógio ou um backend que mantém estado quente em memória entre as requisições. Para esses casos você muda o modo de execução para contêiner e o mesmo app passa a rodar como um processo de longa duração, em vez de começar do zero a cada vez.
O ponto é que se trata do mesmo app. Você não o reescreve, não faz um fork nem o move para outro serviço. O código, as rotas e as ligações ficam onde estão; você muda apenas como ele é executado. Isso faz do modo contêiner uma decisão que você toma quando um recurso pede por ela, e não uma arquitetura com a qual você se compromete de saída. Comece um app no modo leve e efêmero e mude para contêiner no momento em que adicionar a peça que precisa persistir.
Isso combina com a proposta do osFoundry de manter chat, agentes, apps, código e dados em um só espaço de trabalho, em vez de espalhados por contas de hospedagem separadas. Como o osFoundry é bring-your-own-key e local-first, você roda o seu próprio app nos seus próprios termos, sem uma camada SaaS por assento em volta dele. A computação em contêiner estende isso ao backend: quando seu app deixa de ser um auxiliar sem estado e passa a precisar continuar rodando, o espaço de trabalho já tem um lugar para ele morar.
Principais recursos
- Alterne qualquer app do osFoundry entre execução efêmera e em contêiner sem mexer no código
- Rode processos de longa duração: servidores WebSocket, workers em segundo plano, agendadores e daemons
- Mantenha estado quente em memória entre requisições em vez de fazer cold start a cada chamada
- Escolha o modo de execução por app, então você só paga por um processo persistente onde um recurso precisa
- O backend vive no mesmo espaço de trabalho que seu chat, seus agentes, seu código e seus dados
Casos de uso
- Desenvolvedor: um app ganhou um recurso WebSocket para atualizações ao vivo, então sua execução muda para contêiner para manter as conexões abertas
- Criador de automações: um worker em segundo plano que esvazia uma fila de tarefas e roda em um agendamento precisa de um processo que nunca durma
- Líder de equipe: um protótipo começou sem estado e, quando passou a precisar de um cache quente e um backend persistente, migrou para o modo contêiner sem reconstruir nada
Perguntas frequentes
Quando devo mudar um app para computação em contêiner em vez do modo padrão?
Mude quando seu app precisar de algo que continue vivo entre requisições: conexões abertas (como WebSockets), workers em segundo plano ou agendados, um processo daemon ou estado em memória que você não quer perder a cada chamada. Se o app apenas responde requisições e desliga, o modo efêmero, mais leve, encaixa melhor.
Preciso reescrever meu app para rodá-lo como contêiner?
Não. É o mesmo app em outro modo. Você muda a configuração de execução e o código existente roda como um processo persistente. Essa é toda a ideia: você pode começar com um app simples e migrar para um contêiner só quando um recurso realmente exigir.
Como isso se relaciona com o osFoundry ser bring-your-own-key e local-first?
A computação em contêiner é sobre onde o backend do seu app roda, então ela fica alinhada com o resto do osFoundry: suas chaves, seus modelos e seus dados continuam sob seu controle, e o backend do app vive no mesmo espaço de trabalho que seu chat, seus agentes, seu código e seus dados, em vez de uma conta de hospedagem separada.