Azure container app pricing is based on requests. How does that work for an always-running process?

Question

Please note: I have chosen "azure container instances" as the tag since there is no "azure container apps" tag, but my question is about azure container apps.

A typical windows service is "always running" by design.

Suppose I currently have a windows service. The job of this always-running worker is to asynchronously wait on streamed network data, exposed as an IAsyncEnumerable, and process the items that appear. Data arrives via a persistent TCP connection and is processed through various libraries (vendor nuget package which connects to vendor network resource, internal business logic, etc) before appearing in the IAsyncEnumerable.

This process never terminates. It asynchronously waits if there is no data to process. It is "always running" in exactly the same sense that a completely normal windows service is always running.

We want to move this to an azure "cloud native" model. In a recent group call with team members from Microsoft (which was organised through our enterprise agreement), we discussed what the "azure cloud native" equivalent would be to something currently coded as a windows service. We were told that azure container apps might be the best fit.

The pricing page for azure container apps at https://azure.microsoft.com/en-au/pricing/details/container-apps/ says:

The first 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests each month are free. [...] Active usage occurs while your container is starting or while there is at least one request being processed by the application

What is the definition of "request" in this paragraph? It seems like this phrasing assumes a request-response or event trigger model, like a web application or azure function app.

In particular, what does "at least one request being processed" mean in the context of a console application with an infinite loop that asynchronously waits for data coming via a persistent TCP connection?

Answer 1

Hi @allmhuran ,

Sincerest apologies for the delayed response. Hopefully, I can shed some light but do comment down below for clarifying questions.

What is the definition of "request" in this paragraph? It seems like this phrasing assumes a request-response or event trigger model, like a web application or azure function app.

You are correct in that request in this statement refers to any networking i.e., HTTP requests received by your container application. With regards to

In particular, what does "at least one request being processed" mean in the context of a console application with an infinite loop that asynchronously waits for data coming via a persistent TCP connection?

I would say this would fall under compute, because there is some processing going on e.g., while(true) but should still fall under Idle charges which are reduced. Instead of a persistent TPC connection, I would either expose an endpoint to kick off processing or use an event driven method. One more thing, currently Container Apps only supports Linux (still in preview), so you should be able to use a Windows Server Core base image and simply run your application as a console app. Another option is to use Azure Container Instances.

Answer 2

Our current hosting is via a windows service, but my expectation that is easily changed with UseSystemd() instead of UseWindowsService().

I have received some information from within microsoft about this.

Apparently there will eventually be a pricing model where a process is deemed idle unless it exceeds either a vcore usage or network rate threshold, and where billing is therefore not tied to the concept of requests. However this model is not yet available in preview.

I am glad to see that Azure is finally acknowledging the existence of processes that are not http-request based.