A Container Apps traffic split is the release-control surface I expect teams to use instead of replacing production all at once. It assigns percentages across active revisions, which makes canaries, phased rollouts, A/B tests, and quick rollbacks possible without rebuilding the app. Architecturally, the split must be tied to health checks, telemetry, deployment gates, and a rollback threshold, not treated as a manual slider. I review whether sticky sessions, identity, downstream schema changes, and cache behavior make split traffic safe. Operators should capture old and new weights, revision names, error rates, latency, and business metrics. A good split gives the team evidence before promotion and a clean route back when a release misbehaves.
SecuritySecurity for Container Apps traffic split focuses on ensuring every traffic target has approved authentication, authorization, identity, secrets, image provenance, and logging before receiving users. Review managed identity, RBAC, registry permissions, secrets, ingress, network rules, image provenance, audit logs, and who can change the resource. Prefer private endpoints or internal ingress where appropriate, Key Vault backed secrets, least privilege, and explicit approval for public exposure. Watch for broad contributor access, plaintext environment variables, untrusted images, stale revisions, and logs that reveal tokens or customer data. Production use should include owner, rotation path, emergency rollback, and evidence that security controls apply to every active revision.
CostCost for Container Apps traffic split comes from running multiple active revisions, extra telemetry, duplicated dependencies, test traffic, minimum replicas, and cleanup after promotion. Direct charges may be visible in billing, but indirect costs appear as incident response, excessive telemetry, duplicate capacity, failed retries, slow deployments, or support time. Review budgets, tags, workload profile placement, replica limits, retention policies, build frequency, and log ingestion before scaling or automating it. Tie every cost increase to an owner, business reason, expected duration, and measurement window. This helps finance distinguish intentional capacity from waste and helps engineers avoid small configuration choices becoming monthly variance.
ReliabilityReliability for Container Apps traffic split depends on health gates, rollback routing, active revision readiness, label correctness, metrics comparison, and stable behavior while two versions run together. Operators should know expected scale behavior, startup path, dependencies, probes, retry rules, image pull path, and the rollback target. Monitor replica state, revision health, ingress errors, dependency failures, queue depth, latency, and quota. Test the failure path before production change, including image pull failure, secret rotation, downstream outage, and traffic rollback. Keep a known-good revision or image available when possible. This prevents a small configuration mistake from becoming a user-visible outage during a busy release window. Review the evidence after every release.
PerformancePerformance for Container Apps traffic split is about latency comparison between revisions, sample size, cache behavior, cold starts, dependency timing, and saturation during gradual promotion. Measure signals that reflect workload experience, such as latency, throughput, queue depth, replica readiness, image pull duration, CPU, memory, connection counts, or dependency response time. Avoid tuning one setting in isolation when identity, network path, registry location, cache state, partitioning, image size, or downstream services also influence results. Keep baseline measurements before and after changes so regressions are visible. That evidence helps teams optimize the actual bottleneck instead of the most obvious Container Apps setting. Use the same measurement window across stable and candidate versions.
OperationsOperationally, Container Apps traffic split needs clear ownership, naming, tagging, change records, and repeatable verification. Teams should know which portal blade, CLI command, metric, log query, deployment file, and runbook prove current state. Capture before-and-after evidence for production changes, including resource IDs, revision names, image digests, traffic weights, replica counts, secrets, region, and monitoring window. Keep rollback steps near the change record, not in personal notes. For support, define who can approve changes, who monitors impact, and when old revisions, images, or sessions should be cleaned up. Also document alert recipients, emergency approvers, evidence owners, and the post-rollout review date for audits.