Modelos de cobrança no Azure Functions

Modelos de cobrança no Azure Functions

O mercado esta ficando cada vez mais dinâmico e, com essa dinâmica, vem junto a necessidade de escalar, cada vez mais, as suas aplicações. E porque não pedaços/trechos do seu código?

No post anterior, fiz uma introdução e expliquei alguns cenários de aplicação que podemos ter, usando o Azure Functions. Hoje vamos falar quais são os tipos de modelo de cobraça são aplicados para o Azure Functions.

Infraestrutura Dinâmica (Dynamic Host)

Usando o modelo Dynamic Host, você não precisa se preocupar com nenhum tipo de recurso de hardware ou configuração, para que sua Function possa ser executada.

Neste modelo, você será cobrado apenas e somente apenas pelo tempo que seu código executar, e o que ele vier a usar de CPU ou memória RAM. Ou seja, isso é um grande avanço na redução de custos e otimização de infraestrutura, contrário do modelo, ainda utilizando pelos WebJobs, onde você precisa pré-configurar a WebApp, ou seja, a VM que será configurada para hospedar o seu serviço e, pior, pagar por esta máquina, mesmo que sua aplicação/código, fique ocioso. Isso é Ruim, hein !!!

Na figura abaixo, você vai encontrar a configuração de criação para um Azure Functions, usando o plano por consumo (Consumption Plan). O que eu considero muito mais vantajoso. Lembrando que só será pago pelo que usar, mesmo que sua Function fique ociosa por muito tempo.

Dynamic Host usando Plano de Consumo (Consumption Plan)

Modelo Clássico por Plano de Serviço (Service Plan)

Neste método de cobrança, como o próprio nome já diz, a cobrança é feita por um modelo de App Service ou Serviço de Aplicativo.

Quando optamos por criar um Azure Functions, usando este método de cobrança Service Plan, o serviço passa a rodar (executar), dentro de uma VM, ou seja, o conceito de consumo do modelo PaaS com reserva de recurso, continua existindo. Com isso, todos os recursos de hardware ainda precisam ser pré-definidos no momento da criação do plano, ou seja, CPU/RAM + Disco, tal como você faria para criar um Web Apps / API Apps.

Apesar desse modelo clássico de hospedagem não ter o melhor custo x benefício, existe um motivo para que ele exista. O modelo clássico existe para que seja possível hospedar Azure Functions junto com um Web App ou API App.

Do ponto de vista de custo controlado, o Modelo Clássico leva uma vantagem sobre o Modelo de Hospedagem Dinâmico, visto que no Clássico escopo de escalabilidade já foi pré-definido, por outro lado, caso seu serviço precise de mais recurso de hardware, a sua Functions será prejudicada.

Caso tenha mais questionamentos sobre a questão de Cobrança do Azure Functions, você pode encontrar maiores detalhes aqui.

Gostou do assunto?
Quer receber mais novidades sobre Tecnologia? Assine minha página no Facebook.

Quer debater mais sobre assunto? Deixe seu comentário. Terei o maior prazer em debater sobre o assunto.

Comments