Rendering Platform: Choosing a Hosting Model Under Burst, Idle, and Timeout Constraints
Fabrikam Media runs an image-rendering platform made of three tiers: a REST API, a render worker, and a nightly ingest batch. All three currently run on 12 always-on D-series VMs averaging 18 percent CPU. The nightly batch spikes to 400 concurrent renders between 01:00 and 04:00, then the platform is idle for roughly 20 hours. Every component is already containerized, and the team has no Kubernetes experience. Constraints: the API must accept traffic only from the corporate network and never from the public internet; a single render job runs 5 to 45 minutes; workers write output to an Azure Files share over SMB and read from Azure SQL through a private endpoint. Finance wants the monthly compute bill cut by at least 40 percent without a code rewrite, and everything must stay in one region.
1. Select a hosting model for each of the three tiers and justify each choice against the stated constraints.
Read the worked answer
API tier: App Service (or Container Apps) with a private endpoint. Inbound private endpoint satisfies the no-public-inbound rule, VNet integration gives outbound reach to the SQL private endpoint and the SMB share, and the platform gives you deployment slots and autoscale without node management.
Worker tier: Container Apps with a KEDA queue-length scaler. Scale rules on the render queue, scale to zero when the queue is empty, and per-replica billing. Replicas can run far longer than a Functions Consumption plan allows.
Nightly batch: Container Apps Jobs on a schedule trigger. The job spins up only for the 01:00-04:00 window and scales back to zero.
Why not Functions Consumption for the workers: default timeout is 5 minutes and the maximum configurable value is 10 minutes, so a 45-minute render would be killed mid-flight. Functions would only work on Premium or with Durable orchestration, which adds complexity for no benefit here.
Why not AKS: no in-house Kubernetes skills and a minimum node pool that would sit idle and billed for 20 hours a day.
2. The lead engineer argues for moving all three tiers to AKS so the team has one platform. Give the strongest counter-arguments and state what new requirement would make AKS the right answer.
Read the worked answer
Counter-arguments
- Cost against the 40 percent target. AKS bills for the nodes, not the pods. A system node pool sized for the API baseline runs 24x7 regardless of the 20 idle hours, and the cheap scale-to-zero behavior the batch tier depends on becomes your problem to engineer with cluster autoscaler plus a burst profile.
- Operational surface. Someone must own cluster upgrades, node image patching, CSI drivers, ingress, and workload identity federation. That skill does not exist on this team today, and the vendor does not pay for the learning curve.
- Capability delta is small. Container Apps already runs on AKS-managed infrastructure and covers the private endpoint, VNet integration, KEDA scaling, and scheduled jobs. AKS adds control the workload does not need.
What would flip the decision: a requirement for custom resource definitions or operators, a service mesh with mTLS between every hop, GPU node pools with specific device plugins, hard multi-tenant namespace isolation with its own admission control, or a genuine portability mandate to run the same manifests on another cloud. Absent one of those, the managed container service wins on total cost of ownership.
3. How would you structure the compute commitments to hit the cost target without locking the company into the wrong SKUs?
Read the worked answer
Separate the bill into a baseline and a burst, and treat them with different instruments.
- Baseline: the API and its supporting instances that must run every hour of the month. Buy a 1-year reservation for that known quantity. If the team expects to change VM families or move between App Service and Container Apps within the year, prefer a savings plan instead, which discounts compute more broadly and is not tied to one SKU in one region.
- Burst: the 400 concurrent renders and the nightly job. Leave these on consumption or pay-as-you-go pricing and let scale-to-zero do the work. Pre-purchasing capacity for a 3-hour nightly window means paying for 21 hours you do not use.
- Sequencing: right-sizing and scale-to-zero usually deliver the largest share of a 40 percent reduction before any commitment is signed. Model the commitment only against the load you can evidence from 30 days of telemetry.
- Guardrails: scope reservations narrowly, review utilization monthly, and remember reservations can be exchanged or refunded within limits rather than simply wasted.