Opções de hospedagem do Azure Functions
Ao criar um aplicativo de funções no Azure, você precisa escolher um plano de hospedagem para o aplicativo. Há três planos de hospedagem básicos do Azure Functions disponibilizados pelo Azure Functions: o plano de Consumo, o plano Premium e o plano Dedicado (Serviço de Aplicativo). Esses planos de hospedagem são facilitadas pela infraestrutura do Serviço de Aplicativo do Azure e estão em GA (disponibilidade geral) nas máquinas virtuais Linux e Windows.
O plano de hospedagem do Azure Functions que você escolher ditará os seguintes comportamentos:
- Como o aplicativo de funções é dimensionado.
- Os recursos disponíveis para cada instância do aplicativo de funções.
- Suporte para funcionalidades avançadas, como conectividade à Rede Virtual do Azure.
Além da hospedagem do Azure Functions, você também pode hospedar aplicativos de função em contêineres em contêineres que podem ser implantados em clusters do Kubernetes ou em Aplicativos de Contêiner do Azure. Se você optar por hospedar suas funções em um cluster Kubernetes, considere o uso de um cluster Kubernetes habilitado para o Azure Arc. Para saber mais sobre como implantar aplicativos de contêiner personalizados, confira Hospedagem de Aplicativos de Contêiner do Azure Functions.
Este artigo fornece uma comparação detalhada entre os vários planos de hospedagem, incluindo as opções de hospedagem baseada em contêineres.
Observação
A hospedagem dos contêineres do Azure Functions em clusters do Kubernetes habilitados para Azure Arc e Aplicativos de Contêiner do Azure está atualmente em versão prévia.
Visão geral dos planos
Veja o seguinte resumo dos benefícios dos três principais planos de hospedagem para o Azure Functions:
| Plano | Vantagens |
|---|---|
| Plano de Consumo | Dimensione automaticamente e pague apenas pelos recursos de computação quando suas funções estiverem em execução. No plano de Consumo, as instâncias do host do Functions são adicionadas e removidas dinamicamente com base no número de eventos de entrada. ✔ Plano de hospedagem padrão. ✔ Pague apenas quando suas funções forem executadas. ✔ Escala horizontalmente de maneira automática, mesmo durante períodos de carga alta. |
| Plano Premium | Escala automaticamente com base na demanda usando trabalhos pré-configurados que executam aplicativos sem atraso após estarem ociosos, é executado em instâncias mais poderosas e se conecta a redes virtuais. Considere o plano do Azure Functions Premium nas seguintes situações: ✔ Os aplicativos de funções executam continuamente ou quase continuamente. ✔ Você tem um número alto de execuções pequenas e uma fatura de execução alta, mas com poucos GB por segundo no plano de Consumo. ✔ Você precisa de mais opções de CPU ou memória do que é fornecido pelo plano de Consumo. ✔ O código precisa executar por mais tempo do que o tempo de execução máximo permitido no plano de Consumo. ✔ Você precisa de recursos que não estão disponíveis no plano de Consumo, como conectividade de rede virtual. ✔ Você deseja fornecer uma imagem Linux personalizada na qual executar suas funções. |
| Plano dedicado | Execute suas funções em um plano do Serviço de Aplicativo com taxas regulares do Plano do Serviço de Aplicativo. Melhor para cenários de execução longa em que o Durable Functions não pode ser usado. Considere um Plano do Serviço de Aplicativo nas seguintes situações: ✔ Você tem VMs subutilizadas que já estão executando outras instâncias do Serviço de Aplicativo. ✔ Dimensionamento e custos preditivos são necessários. |
As tabelas de comparação neste artigo também incluem as opções de hospedagem a seguir, que fornecem a maior quantidade de controle e isolamento na qual executar seus aplicativos de funções.
| Opção de hospedagem | Detalhes |
|---|---|
| ASE | O ASE (Ambiente do Serviço de Aplicativo) é um recurso do Serviço de Aplicativo que fornece um ambiente totalmente isolado e dedicado a executar com segurança os aplicativos do Serviço de Aplicativo em grande escala. Os ASEs são apropriados para cargas de trabalho de aplicativos que exigem: ✔ Uma escala muito alta. ✔ Isolamento de computação completo e acesso seguro à rede. ✔ Alto uso de memória. |
| Aplicativos de Contêiner do Azure | O serviço Aplicativos de Contêiner do Azure é um ambiente totalmente gerenciado que permite executar microsserviços e aplicativos conteinerizados em uma plataforma sem servidor. Os Aplicativos de Contêiner do Azure permitem que você execute suas funções com o poder do AKS (Serviço de Kubernetes do Azure) subjacente, enquanto remove a complexidade de ter que trabalhar com APIs do Kubernetes. |
| Kubernetes (Direto ou Azure Arc) |
O Kubernetes fornece um ambiente totalmente isolado e dedicado em execução na plataforma Kubernetes. O Kubernetes é apropriado para cargas de trabalho de aplicativos que exigem: ✔ Requisitos de hardware personalizados. ✔ Isolamento e acesso seguro à rede. ✔ Capacidade de executar em um ambiente híbrido ou de várias nuvens. ✔ Execução junto com os aplicativos e serviços existentes do Kubernetes. |
As tabelas restantes neste artigo comparam os planos em vários recursos e comportamentos. Para uma comparação de custo entre planos de hospedagem dinâmicos (Consumo e Premium), confira a página de preços do Azure Functions. Para ver os preços das várias opções de plano Dedicado, confira a página de preços do Serviço de Aplicativo.
Sistema operacional/runtime
A tabela a seguir mostra o suporte ao sistema operacional e ao idioma dos planos de hospedagem.
| Linux1,2 Somente código |
Somente código do Windows | Linux1,2,3 Contêiner do Docker |
|
|---|---|---|---|
| Plano de Consumo | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
Sem suporte |
| Plano Premium | C# JavaScript Java Python PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Plano dedicado | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| ASE | C# JavaScript Java Python TypeScript |
C# JavaScript Java PowerShell Core TypeScript |
C# JavaScript Java PowerShell Core Python TypeScript |
| Kubernetes (direto) | n/d | N/D | C# JavaScript Java PowerShell Core Python TypeScript |
| Azure Arc (versão prévia) | C# JavaScript Java Python TypeScript |
N/D | C# JavaScript Java PowerShell Core Python TypeScript |
1 O Linux é o único sistema operacional compatível com a pilha de runtime do Python.
2 O suporte do PowerShell no Linux está atualmente em versão prévia.
3 o Linux é o único sistema operacional compatível com contêineres do Docker.
Duração do tempo limite do aplicativo de funções
A duração do tempo limite para funções em um aplicativo de funções é definida pela propriedade functionTimeout no arquivo de projeto host.json. Essa propriedade se aplica especificamente a execuções de função. Depois que o gatilho inicia a execução da função, a função precisa retornar/responder dentro da duração do tempo limite. Para saber mais, confira Melhorar o desempenho e a confiabilidade do Azure Functions.
A seguinte tabela mostra os valores padrão e máximo (em minutos) para planos específicos:
| Plano | Padrão | Máximo1 |
|---|---|---|
| Plano de Consumo | 5 | 10 |
| Plano Premium | 302 | Ilimitado3 |
| Plano dedicado | 302 | Ilimitado3 |
1 Independentemente da configuração de tempo limite do aplicativo de funções, 230 segundos é a quantidade de tempo máxima que uma função disparada por HTTP pode levar para responder a uma solicitação. Isso ocorre devido ao tempo limite de ociosidade padrão do Azure Load Balancer. Para tempos de processamento mais longos, considere usar o padrão assíncrono das Durable Functions ou adiar o trabalho real e retornar uma resposta imediata.
2 O tempo limite padrão para a versão 1.x do tempo de execução do Functions é ilimitado.
3 Garantido por até 60 minutos. A correção do sistema operacional e do runtime, a correção de vulnerabilidades e a escala de comportamentos ainda podem cancelar as execuções de funções, portanto, certifique-se de gravar funções robustas .
Escala
A tabela a seguir compara os comportamentos de dimensionamento dos vários planos de hospedagem.
As instâncias máximas são fornecidas por aplicativo por função (Consumo) ou por plano (Premium/Dedicado), a menos que indicado de outra forma.
| Plano | Escalar horizontalmente | Número máximo de instâncias |
|---|---|---|
| Plano de Consumo | Controlado por evento. Escale horizontalmente de forma automática, mesmo durante períodos de carga alta. A infraestrutura do Azure Functions escala automaticamente os recursos de CPU e memória adicionando outras instâncias do host do Functions de acordo com o número de eventos de gatilho de entrada. | Windows: 200 Linux: 1001 |
| Plano Premium | Controlado por evento. Escale horizontalmente de forma automática, mesmo durante períodos de carga alta. A infraestrutura do Azure Functions escala automaticamente os recursos de CPU e memória adicionando outras instâncias do host do Functions de acordo com o número de eventos nos quais suas funções são disparadas. | Windows: 100 Linux: 20-1002 |
| Plano dedicado3 | Dimensionamento manual/automático | 10 a 30 |
| ASE3 | Dimensionamento manual/automático | 100 |
| Kubernetes | Dimensionamento automático controlado por eventos para clusters Kubernetes usando KEDA. | Varia de acordo com o cluster |
1 Durante a expansão, atualmente há um limite de 500 instâncias por assinatura por hora para aplicativos Linux em um plano de consumo.
2 Em algumas regiões, os aplicativos Linux em um plano Premium podem ser dimensionadas para 100 instâncias. Para mais informações, confira o artigo do plano Premium.
3 Para limites específicos para as várias opções do plano do Serviço de Aplicativo, confira os limites do plano do Serviço de Aplicativo.
Comportamento de inicialização a frio
| Plano | Detalhes |
|---|---|
| Plano de Consumo | Os aplicativos podem ser dimensionados para zero quando estiverem ociosos, o que significa que algumas solicitações podem ter latência adicional na inicialização. O plano de consumo tem algumas otimizações para ajudar a reduzir o tempo de inicialização a frio, incluindo a extração de funções de espaço reservado pré-configuradas que já têm o host de funções e os processos de linguagem em execução. |
| Plano Premium | Instâncias perpetuamente quentes para evitar inicializações a frio. |
| Plano dedicado | Ao executar em um plano Dedicado, o host do Functions pode ser executado continuamente, o que significa que a inicialização a frio não é um problema. |
| ASE | Ao executar em um plano Dedicado, o host do Functions pode ser executado continuamente, o que significa que a inicialização a frio não é um problema. |
| Kubernetes | Dependendo da configuração do KEDA, os aplicativos podem ser configurados para evitar uma inicialização a frio. Se for configurado para escalar para zero, uma inicialização a frio será experimentada para novos eventos. |
Limites de serviço
| Recurso | Plano de Consumo | Plano Premium | Plano dedicado | ASE | Kubernetes |
|---|---|---|---|---|---|
| Duração padrão do tempo limite (min) | 5 | 30 | 301 | 30 | 30 |
| Duração máxima do tempo limite (min) | 10 | não associado7 | não associado2 | não associado | não associado |
| Máximo de conexões de saída (por instância) | 600 ativos (1.200 no total) | não associado | não associado | não associado | não associado |
| Tamanho máximo da solicitação (MB)3 | 100 | 100 | 100 | 100 | Depende do cluster |
| Comprimento máximo da cadeia de caracteres de consulta3 | 4096 | 4096 | 4096 | 4096 | Depende do cluster |
| Comprimento máximo da URL de solicitação3 | 8192 | 8192 | 8192 | 8192 | Depende do cluster |
| ACU por instância | 100 | 210-840 | 100-840 | 210-2508 | Preços do AKS |
| Memória máxima (GB por instância) | 1.5 | 3,5-14 | 1,75-14 | 3,5-14 | Todos os nós são compatíveis |
| Contagem de instâncias máxima (Windows/Linux) | 200/100 | 100/20 | varia de acordo com a SKU9 | 1009 | Depende do cluster |
| Aplicativos de Funções por plano11 | 100 | 100 | não associado4 | não associado | não associado |
| Planos do Serviço de Aplicativo | 100 por região | 100 por grupo de recursos | 100 por grupo de recursos | - | - |
| Slots de implantação por aplicativo10 | 2 | 3 | 1-209 | 20 | n/d |
| Armazenamento5 | 5 GB | 250 GB | 50-1.000 GB | 1 TB | n/a |
| Domínios personalizados por aplicativo | 5006 | 500 | 500 | 500 | n/a |
| domínio personalizado Suporte a SSL | conexão SSL SNI não associada incluída | conexões SSL SNI e 1 IP SSL não associadas incluídas | conexões SSL SNI e 1 IP SSL não associadas incluídas | conexões SSL SNI e 1 IP SSL não associadas incluídas | n/a |
1 Por padrão, o tempo limite do runtime do Functions 1.x em um plano do Serviço de Aplicativo não é associado.
2 Requer que o plano do Serviço de Aplicativo seja definido como Always On. Pagamento com taxas padrão.
3 Esses limites são definidos no host.
4 O número real de aplicativos de funções que você pode hospedar dependerá da atividade dos aplicativos, do tamanho das instâncias do computador e da utilização de recursos correspondente.
5 O limite de armazenamento é o tamanho total do conteúdo no armazenamento temporário em todos os aplicativos no mesmo plano do Serviço de Aplicativo. O plano de consumo usa os Arquivos do Azure para obter um armazenamento temporário.
6 Quando seu aplicativo de funções estiver hospedado em um Plano de consumo, somente a opção CNAME será compatível. Para obter aplicativos de funções em um plano Premium ou plano do Serviço de Aplicativo, você poderá mapear um domínio personalizado usando um CNAME ou registro A.
7 Garantido por até 60 minutos.
8 As funções de trabalho são funções que hospedam aplicativos de clientes. As funções de trabalho estão disponíveis em três tamanhos fixos: Um vCPU/3,5 GB de RAM, dois vCPUs/7 GB de RAM e quatro vCPUs/14 GB de RAM.
9 Confira Limites do Serviço de Aplicativo para saber detalhes.
10 Incluindo o slot de produção.
11 Atualmente, há um limite de 5.000 aplicativos de função em uma determinada assinatura.
Limitações para criar aplicativos de funções em um grupo de recursos existente
Em alguns casos, ao tentar criar um plano de hospedagem para o aplicativo de funções em um grupo de recursos existente, você pode receber um dos seguintes erros:
- O tipo de preço não é permitido neste grupo de recursos
- Os trabalhos do <SKU_name> não estão disponíveis no grupo de recursos <resource_group_name>
Isso pode acontecer quando as seguintes condições são atendidas:
- Você cria um aplicativo de funções em um grupo de recursos existente que já contém outro aplicativo de funções ou aplicativo Web. Por exemplo, os aplicativos de Consumo do Linux não são suportados no mesmo grupo de recursos que os planos Linux Dedicado ou Linux Premium.
- O novo aplicativo de funções é criado na mesma região que o aplicativo anterior.
- O aplicativo anterior é incompatível com o novo aplicativo em algum aspecto. Isso pode acontecer entre SKUs, sistemas operacionais ou devido a outros recursos no nível da plataforma, como suporte à zona de disponibilidade.
O motivo disso é a forma como os planos de aplicativos Web e de aplicativos de funções são mapeados para diferentes pools de recursos ao serem criados. SKUs diferentes exigem um conjunto diferente de funcionalidades de infraestrutura. Quando você cria um aplicativo em um grupo de recursos, esse grupo de recursos é mapeado e atribuído a um pool de recursos específico. Se você criar outro plano nesse grupo de recursos e o pool mapeado não tiver os recursos necessários, esse erro ocorrerá.
Quando esse erro ocorrer, crie o aplicativo de funções e o plano de hospedagem em um novo grupo de recursos.
Recursos de rede
| Recurso | Plano de Consumo | Plano Premium | Plano dedicado | ASE |
|---|---|---|---|---|
| Restrições de IP de entrada | ✅Sim | ✅Sim | ✅Sim | ✅Sim |
| Pontos de extremidade privados de entrada | ❌Não | ✅Sim | ✅Sim | ✅Sim |
| Integração de rede virtual | ❌Não | ✅Sim (Regional) | ✅Sim (regional e gateway) | ✅Sim |
| Gatilhos de rede virtual (não HTTP) | ❌Não | ✅Sim | ✅Sim | ✅Sim |
| Conexões híbridas (somente Windows) | ❌Não | ✅Sim | ✅Sim | ✅Sim |
| Restrições de IP de saída | ❌Não | ✅Sim | ✅Sim | ✅Sim |
Cobrança
| Plano | Detalhes |
|---|---|
| Plano de Consumo | Você paga apenas pelo tempo durante o qual suas funções são executadas. A cobrança baseia-se no número de execuções, no tempo de execução e na memória usada. |
| Plano Premium | O plano Premium é baseado no número de segundos de núcleo e na memória usada nas instâncias necessárias e pré-aquecidas. Pelo menos uma instância por plano deve ser mantida aquecida em todos os momentos. Esse plano fornece o preço mais previsível. |
| Plano dedicado | Você paga o mesmo por aplicativos de funções em um plano do Serviço de Aplicativo que pagaria por outros recursos do Serviço de Aplicativo, como aplicativos Web. |
| ASE (Ambiente do Serviço de Aplicativo) | Existe uma taxa mensal fixa para um ASE que paga pela infraestrutura e não se altera com o tamanho do ASE. Também há um custo por vCPU do plano do Serviço de Aplicativo. Todos os aplicativos hospedados no ASE estão em um SKU de preços Isolado. |
| Kubernetes | Você paga apenas os custos do cluster Kubernetes; nenhuma cobrança adicional para o Functions. Seu aplicativo de funções é executado como uma carga de trabalho de aplicativo sobre o cluster, assim como um aplicativo normal. |