Running Containers Without Kubernetes

Rung 3 pays off

Lesson 2.2 produced a production-grade container image for AssetTrack’s API. The ladder placed it on rung 3: a managed container service — concretely, Azure Container Apps. Today you deploy it and take inventory of everything you did not have to build.

Prompt first

Generate the az CLI commands to deploy a container to Azure Container Apps:

- Image: assettrack-api from our Azure Container Registry
- Ingress: external HTTPS on port 8080, platform-managed TLS
- Secrets: the database connection string pulled from Azure Key Vault
  via managed identity - never inline
- Scaling: 1 to 5 replicas on HTTP concurrency of 50, scale to 1 (not 0 -
  this API backs field operations during storms)
- Probes: readiness and liveness against /healthz

Explain what the platform now handles that a Kubernetes deployment
would have made me configure myself.

The shape of the answer:

az containerapp env create \
  --name meridian-prod --resource-group rg-meridian \
  --location eastus2

az containerapp create \
  --name assettrack-api \
  --resource-group rg-meridian \
  --environment meridian-prod \
  --image acrmeridian.azurecr.io/assettrack-api:1.4.2 \
  --registry-identity system \
  --ingress external --target-port 8080 \
  --min-replicas 1 --max-replicas 5 \
  --scale-rule-name http-concurrency \
  --scale-rule-type http \
  --scale-rule-http-concurrency 50 \
  --secrets "db-conn=keyvaultref:https://kv-meridian.vault.azure.net/secrets/assettrack-db,identityref:system" \
  --env-vars "ConnectionStrings__Oracle=secretref:db-conn"

Three details in those flags carry most of this lesson’s weight:

--registry-identity system and keyvaultref:...,identityref:system — the app pulls its image and reads its secret using a managed identity. There is no registry password and no connection string in any config file, pipeline variable, or shell history. Credential-less by construction.
--min-replicas 1 — scale-to-zero is a great default for internal tools, and the wrong one here: a cold start in the middle of a storm-day dispatch surge is a field tech staring at a spinner. Scaling policy is a business decision expressed in one flag.
Version-pinned image tag — :1.4.2, not :latest. Deploys should change because you chose to change them. (Lesson 2.5 has more to say about :latest.)

The inventory: what you never built

This table is the argument for rung 3. For this one API, the platform absorbed:

Concern	On Container Apps	On a cluster you own
TLS certificates	Issued and rotated by the platform	Your cert-manager config, your renewals
OS and node patching	Invisible to you	Your maintenance windows
Ingress routing	One flag	Ingress controller to choose, deploy, patch
Autoscaling	One scale rule	Metrics pipeline + HPA tuning
Zero-downtime deploys	Revisions built in	Rollout strategy + PodDisruptionBudgets
Registry auth & secret storage	Managed identity references	Pull secrets, CSI drivers, rotation story

Every row is work that exists somewhere — the question the ladder keeps asking is whether it exists on your payroll.

💡Revisions are your rollback button

In multiple-revision mode, Container Apps keeps prior revisions addressable. Ship 1.4.3, watch it misbehave, and rollback is one command: route traffic back to the 1.4.2 revision. You get blue-green semantics without building blue-green infrastructure — remember this in Lesson 4.3 when the promotion runbook needs its backout step.

When rung 3 is not enough

Honesty requires the failure modes. Managed container platforms will fight you when the workload needs: privileged containers or kernel modules, custom node types or GPUs with exotic drivers, long-lived non-HTTP protocols the ingress cannot route, or network topologies the platform cannot express. Those are real forcing tests — name one, and Lesson 2.4’s descent to Kubernetes is justified. AssetTrack’s API needs none of them.

KNOWLEDGE CHECK

The deploy references the database credential as a Key Vault reference resolved through a managed identity, rather than passing the connection string directly. What is the operational win?

Key takeaway

A managed container platform gives you the container’s benefits — dependency control, immutable versioned artifacts, instant rollback via revisions — while absorbing TLS, patching, ingress, scaling, and secret plumbing. That inventory table is your template: run it for any workload, and if every row lands in the platform column, you have no business on a cluster. The one Meridian workload that fails that test is next.