Autoscaling Controller  ·  View 01 of 37  ·  1 · Context and scope

System Context

What sits inside the controller's boundary, what feeds it, and what it is allowed to change.

Editable source SVG draw.io All views
Signal sources Managed Prometheus utilization, custom Azure Monitor platform metrics Service Bus backlog, msg age Forecast Feed calendar, prediction People Service Owner SRE On-Call FinOps Analyst Platform Admin Capacity providers VM Scale Sets stateless fleets AKS Node Pools node groups Workload Replicas Deployments Warm Pool Fleet pre-warmed Autoscaling Controller declare, then converge Governance and evidence Microsoft Entra ID workload identity Azure Data Explorer decision journal Grafana + Alertmanager alerts, dashboards declares target + bounds pins, pauses, unfreezes reads cost of stability sets fleet ceilings remote read metric query queue depth capacity floor set capacity set node count set replicas attach, recycle authenticates journals every decision exports metrics Autoscaling Controller — System Context External / third party Queue / topic Person or role Security / platform Data store synchronous batch Out of scope: running the workloads, scheduling them, and any customer payload. The controller decides how much capacity a target should have and drives the fleet to that number. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions

  • The controller decides capacity and drives towards it. It does not run workloads and does not schedule them.
  • It ingests no customer payload data at any point, which keeps the whole control plane out of data-classification scope.
  • Signal sources are inbound and read-only; capacity providers are outbound and write-only. No interface is both.

Stack

  • The requirement names Google Cloud; this architecture is built on Azure and open source at the sponsor's direction.
  • Substitutions: managed instance groups → VM Scale Sets, GKE node pools → AKS node pools, Pub/Sub → Event Hubs, Cloud Monitoring → Azure Monitor plus Managed Prometheus.
  • Nothing outside the technology names changes: the requirement was written to survive a change of cloud, and it did.

Assumptions

  • Forecast feeds are external and signed; the controller never generates its own forecast in v1.
  • Every scaling target has an owning team, because cost attribution and the RBAC model both depend on it.
  • Warm pools are in scope as a controller-managed fleet, not as a provider feature.
All views High-Level Architecture  ▶
Solution Architecture v1.0 · Data & AI Global Practice · 2026-09 · 37 views · Azure and open source01-system-context