TL;DR — O Azure Durable Task Scheduler agora oferece sandboxes sob demanda (private preview) para executar atividades isoladas em containers gerenciados, com suporte a .NET e Python. Isso elimina a necessidade de infraestrutura dedicada para workloads com toolchains nativos, código de LLM ou bursting. Para empresas brasileiras que lidam com orquestrações complexas, a feature reduz custos de idle e complexidade operacional, mantendo o orchestrator inalterado.
Todo workflow durável tem aquela atividade que você gostaria de executar em outro lugar. Talvez precise de uma toolchain nativa, execute código não confiável de cliente ou gerado por LLM, ou demande Python a partir de um orchestrator .NET, ou ainda compute bursty que deve escalar a zero quando o trabalho termina.
A Microsoft anunciou hoje as On-demand Sandboxes para Azure Durable Task Scheduler, agora em private preview. Com elas, você move passos individuais do workflow para compute gerenciado e isolado, enquanto o orchestrator permanece exatamente onde está. Basta informar ao DTS quais atividades devem ser executadas em isolamento, fornecer uma imagem de container com o código da atividade, e o DTS cuida do provisionamento, scaling e teardown. Sem infraestrutura para gerenciar, sem custos ociosos, sem mudanças no orchestrator.
Sign up for On-demand Sandboxes Private Preview Today →
Disponibilidade: As sandboxes sob demanda são direcionadas aos SDKs standalone do Durable Task usados fora do host do Azure Functions — para aplicações rodando em Azure Container Apps, Azure Kubernetes Service, App Service ou qualquer outro ambiente self-hosted. O private preview suporta os SDKs .NET e Python, com suporte para mais linguagens e Azure Functions em breve.
O que é o Azure Durable Task Scheduler?
O Durable Task Scheduler é um backend totalmente gerenciado para execução durável no Azure. Pode servir como backend para um aplicativo Durable Functions usando a extensão Durable Functions, ou como backend para aplicações que utilizam os SDKs Durable Task em outros ambientes de computação, como Azure Container Apps, Azure Kubernetes Service ou Azure App Service. Para uma introdução mais profunda, veja a visão geral do Durable Task Scheduler ou a documentação completa do Durable Task.
Por que usar sandboxes sob demanda?
A maioria das atividades fica bem dentro do processo do orchestrator: são rápidas, simples e co-localizadas. Mas eventualmente você encontra um passo que não se encaixa: precisa de um binário nativo, runtime de linguagem diferente, isolamento por invocação ou compute bursty que você não quer manter aquecido. As sandboxes sob demanda oferecem uma maneira de lidar com essas exceções sem criar infraestrutura dedicada ou gerenciar políticas de scaling no AKS ou ACA.
- Granularidade no nível de atividade. Mova passos individuais para compute gerenciado, não a aplicação inteira.
- Isolamento por atividade ou por invocação. Cada execução roda em uma sandbox microVM limpa. Ideal para código não confiável, plugins de cliente ou lógica gerada por LLM.
- Flexibilidade cross-runtime. Execute um passo de inferência Python a partir de um orchestrator .NET. Sem compromisso de nenhum dos lados.
- Scale-to-zero. Pague por CPU e memória por segundo de execução, não por infraestrutura que espera.
- Sem alterações no orchestrator. Seu código de orquestração e modelo de hospedagem não mudam.
Aqui estão alguns cenários onde as sandboxes sob demanda brilham:
- Toolchains nativas. Empacote ffmpeg, LibreOffice ou Pandoc em um container sem arrastá-los para o seu aplicativo principal.
- Pré-processamento pesado de CPU. OCR, extração de layout ou processamento de imagem podem escalar independentemente do resto do workflow.
- Workflows cross-runtime. Um orchestrator .NET despacha um passo de inferência Python. Sem compromissos.
- Execução de código em sandbox. Execute plugins de cliente ou código gerado por LLM com uma fronteira limpa a cada invocação.
- Isolamento multi-tenant. Passos específicos de tenant ganham limites dedicados enquanto o resto permanece in-process.
- Workloads event-driven bursty. Passos que disparam forte mas raramente podem não justificar infraestrutura sempre ligada. Cold starts abaixo de 1 segundo significam capacidade quando necessária sem pagar para manter aquecido.
Como funciona?
As sandboxes sob demanda usam um modelo de duas partes: um perfil de worker no aplicativo do orchestrator que informa ao DTS quais atividades devem ser offload, e uma imagem de worker que contém as implementações dessas atividades. Seu orchestrator continua chamando atividades da mesma forma; a decisão de rodar uma atividade em sandbox está na configuração do perfil.
1. Declare um perfil de worker sandbox
No aplicativo que hospeda seu orchestrator, defina um perfil de worker sandbox. O perfil fornece ao DTS a imagem do container, o shape de recursos, a configuração de concorrência e os nomes das atividades que devem rodar em sandbox:
using Microsoft.DurableTask.Worker.AzureManaged.Sandbox;
[SandboxWorkerProfile("code-executor")]
internal sealed class CodeSandboxWorkerProfile : ISandboxWorkerProfile
{
public void Configure(SandboxOptions options)
{
options.ContainerImage = Environment.GetEnvironmentVariable("DTS_SANDBOX_IMAGE")
?? throw new InvalidOperationException("DTS_SANDBOX_IMAGE is required.");
options.Cpu = "1000m";
options.Memory = "2048Mi";
options.MaxConcurrentActivities = 1;
options.AddActivity(TaskNames.ExecuteCode);
}
}
Em seguida, habilite a descoberta de sandboxes sob demanda ao configurar o worker Durable Task no aplicativo principal:
workerBuilder.AddTasks(tasks => tasks.AddAllGeneratedTasks());
workerBuilder.UseDurableTaskScheduler(options =>
{
options.EndpointAddress = Environment.GetEnvironmentVariable("DTS_ENDPOINT");
options.TaskHubName = Environment.GetEnvironmentVariable("DTS_TASK_HUB");
options.Credential = credential;
});
workerBuilder.EnableSandboxes();
A configuração do perfil faz o seguinte:
- SandboxWorkerProfile: um ID amigável para esta configuração de sandbox. Agrupa atividade, imagem e recursos para monitoramento e reuso entre deployments.
- ContainerImage: a imagem do container (do seu registry) que contém as implementações das atividades.
- Cpu / Memory: o shape de recursos para cada instância do worker. Dimensionado conforme a necessidade da atividade.
- MaxConcurrentActivities: quantas atividades uma única instância do worker pode processar concorrentemente.
- AddActivity: a atividade específica a ser offload. Apenas atividades adicionadas a um perfil de worker sandbox executam em compute gerenciado isolado pelo DTS; todo o resto permanece in-process.
O ponto de chamada do orchestrator não muda:
ExecuteCodeOutput execution = await context.CallActivityAsync<ExecuteCodeOutput>(
TaskNames.ExecuteCode,
new ExecuteCodeInput(pythonCode, input.CsvData));
ExecuteCode não está registrado na lista de atividades in-process do aplicativo principal. Quando o orchestrator o chama, o DTS usa o perfil codegen para rotear o trabalho para a imagem sandbox.
2. Construa a imagem do worker
A imagem do worker é um container que você controla. Na maioria dos aplicativos, esse worker reside em um projeto separado do host do orchestrator para ter seu próprio entry point, dependências e imagem de container. Ele registra as implementações de atividade que pode executar e opta pela execução gerenciada com UseSandboxWorker():
builder.Services.AddDurableTaskWorker(workerBuilder =>
{
workerBuilder.AddTasks(tasks =>
{
tasks.AddActivity<ExecuteCodeActivity>();
});
workerBuilder.UseSandboxWorker();
});
UseSandboxWorker() é a linha chave. Sinaliza que este worker roda em compute gerenciado pelo DTS. O worker sandbox não precisa configurar o endpoint DTS, task hub, profile ID ou credenciais; o DTS injeta as configurações de runtime ao iniciar o container.
As implementações das atividades são atividades Durable Task padrão. Não há nada de especial no código da atividade: ele pode chamar um runtime com dependências diferentes, como Python e pandas, enquanto roda em um container isolado em vez do processo do seu aplicativo principal.
Empacote a imagem como qualquer serviço containerizado, incluindo os runtimes e ferramentas nativas que a atividade precisa. Envie para seu container registry (ex.: Azure Container Registry) e referencie a imagem na opção ContainerImage do perfil do worker.
Visualize logs no dashboard do DTS
Depois que suas atividades sandbox estiverem em execução, você pode visualizar os logs de execução diretamente no dashboard do Durable Task Scheduler. O dashboard mostra saída em tempo real dos workers gerenciados, incluindo stdout, stderr e eventos de ciclo de vida das atividades. Isso oferece visibilidade completa do que está acontecendo dentro da sandbox sem precisar configurar sinks de log externos ou montar sua própria pipeline de observability.
Demo
Primeiros passos
As sandboxes sob demanda estão em private preview. Para obter acesso, inscreva-se aqui. A Microsoft habilitará a feature no seu scheduler e ajudará você a rodar sua primeira atividade sandbox.
Depois de aprovado, o workflow é direto: declare um perfil de worker sandbox no seu aplicativo orchestrator, construa e envie uma imagem de worker, e o DTS cuida do resto.
Sign up for On-demand Sandboxes Private Preview Today →
Documentação: Visão geral do Durable Task Scheduler
Samples: Azure-Samples/Durable-Task-Scheduler
Precificação: Preços do Azure Durable Task Scheduler
Dúvidas, feedback ou ideias? Abra uma issue no repositório GitHub do Durable-Task-Scheduler.
Perguntas Frequentes
-
Quais SDKs são suportados no private preview?
Atualmente, os SDKs standalone .NET e Python do Durable Task são suportados. Suporte para outras linguagens e integração com Azure Functions está previsto para o futuro. -
Preciso modificar meu orchestrator para usar as sandboxes?
Não. A configuração é feita via um perfil de worker no código do orchestrator, que declara quais atividades devem ser executadas em sandbox. O código de orquestração permanece inalterado. -
Como funciona o isolamento e a segurança?
Cada execução de atividade em sandbox é isolada em um ambiente microVM limpo, ideal para código não confiável, plugins de clientes ou lógica gerada por LLM. O isolamento pode ser por atividade ou por invocação. -
O que acontece com custos de infraestrutura ociosa?
As sandboxes sob demanda seguem o modelo scale-to-zero: você paga apenas por CPU e memória por segundo de execução, sem custos de infraestrutura parada. Isso é vantajoso para workloads bursty que não justificam recursos sempre ligados.
Artigo originalmente publicado por greenie-msft em Azure Updates - Latest from Azure Charts.
