Workload profiles
Workload profiles allow us to have a dedicated compute (memory and CPU) for the applications deployed in a Container Apps environment. Microsoft supports general-purposes and memory-optimized workload profiles with up to 32vCPU and 256 GiB (E32 profile).
By assigning multiple workload profiles to an ACA environment, we can accommodate different types of workloads. For example, we can ensure that resource-intensive applications run on suitable hardware and general-purpose applications run in a different resource pool.
The best thing about this offering is that we can combine multiple dedicated profiles with a serverless profile in the same ACA environment.
Basically, we can achieve something like the following image, where I might have an API in the Consumption profile, workers and job in a dedicated profile, and resource-intensive applications in a dedicated memory-optimized profile.
Workload Consumption is an excellent choice for applications with intermittent traffic, as you only pay for the resource you use. Consumption supports idle instances, helping you to save costs while avoiding the plague of the serverless world: the cold starts.
Benefits
Workload profiles bring a lot of benefits compared to the initial Consumption plan:
➕You have better cost control when you choose the plan size that fits your workload.
➕You can define User-Defined Routes (UDRs) to manage outbound traffic routing from your container app environment’s subnet. This enables the use of network appliances like Azure Firewall.
➕With the new plan structure, the minimum required subnet size is a /27 CIDR, compared to the minimum subnet size of /23 for container apps created on the existing Consumption plan.
➕In the same ACA environment, you can combine a Consumption profile with a dedicated plan. This gives you the flexibility to enjoy the best of both worlds.
➕The Consumption plan can now run up to 4 vCPUs and 8 GiB of memory for a single application, which is twice the capacity compared to the Consumption-only environment. The Consumption-Workload profile allows applications to consume resources to a max of 100 cores (for example, you can run fifty 2-core apps).
➕ / ➖ Fixed price for a given capacity. It’s up to you to add as many applications as it can accommodate in that environment. If you put in 30 containers or just a few containers, you will pay the same bill. If you add too few, money is wasted, and if you add too many, you need to ensure your profile can scale.
Basically, the workload profile (consumption+dedicated) wipes away the need for the consumption-only ACA environment.
Q: How can we map ACA terminology to the Kubernetes world?
I used to view Azure Container App as a namespace as a service, but with the introduction of the new workload profile offering, the ACA Environment is clearly mapped to a Kubernetes cluster with a single namespace and multiple node pools.
- Container App: I see this as more of a label that identifies a Microservice.
- Revision: Represents a version of a deployment linked to a specific microservice (app).
- Replica: Can be likened to a Pod in Kubernetes, an instance of the microservice.
Q: How many nodes can I put in a 27?
A /27 subnet has 32 available IPs. Azure takes 11 IPs for the network integration (network and broadcast included), meaning we have 21 available IPs for our dedicated nodes.
Run the scenario1 to:
- deploy an ACA environment with 3 workload profiles with 7 D4 instances each (for a total of 21 nodes). This way all the 21 available IPs will be assigned.
- deploy 3 applications (one per dedicated profile) that allocate all the available resources. The 28 cores will be reserved for 28 instances of the app-01, app-02 and app-03. Basically 4 application instances per node.
Note:
- The workload-consumption node does not take the IP from the 21 available. I suppose it gets one from the 11 reserved by Azure.
- If you ask for more node instances than the available IPs, the deployment will complete successfully but the number of nodes will match the max available IPs (see image below).
Q: How many app replicas can I put in a D4?
As much as it can fit. This mainly depends on the MEM and CPU requested by your application. In the Dedicated plan, only the nodes receive an IP from the associated subnet. The single replicas receive an IP from an internal logical IP.
Q: What happens if I try to ask for more resources than are available?
A new revision will be created to attempt to fulfil the request. The current revision will only be dismissed if the new revision is considered ready.
Let’s consider a scenario where we have 5 app instances in an environment that can schedule a maximum of 8 instances (scenario 2 on GitHub). If we trigger a new deployment to increase the instances from 5 to 7 (known as a revision-scope change), Azure Container Apps will attempt to create a new revision with 7 instances before terminating the current revision with 5 instances.
In a single revision mode, the new revision will be considered ready when one of its replicas becomes ready. In our scenario, the new revision won’t be fully activated because there is only space for 3 replicas. However, ACA considers it ready, resulting in 100% of the traffic being routed to the new revision.
Therefore, we will end up in a situation where instead of having 7 replicas (as intended), the traffic is 100% routed to 3 replicas and the new revision is marked with the ‘Degraded’.
Bottom line: Make sure you have enough resources available to perform a revision-scope change.
🔨To fix the ‘degraded’ revision and get the 7 running instances, run the “az containerapp revision deactivate” command targeting the old revision, and then give the new revision a little push by running the “az containerapp revision activate” command.
Q: Does it make sense to have one workload profile per ACA environment to serve a single solution?
From one side, this approach allows you to have stricter network isolation and better network sizing. On the other hand, it might be unnecessarily complex and therefore less maintainable. In the end, as with everything in IT, it depends on your specific use case and requirements.
Conclusion
In conclusion, Azure Container Apps Workload Profiles open up a world of possibilities for optimizing and managing your containerized workloads without dealing with the Kubernetes complexity. Whether you require the flexibility of Consumption profiles, the power of dedicated plans, or a seamless blend of both, ACA Workload Profiles offer the control and scalability needed to meet your application’s unique demands.
Subscribe to our RSS feed