An Operational Model for Cloud Agentic Applications with Selector

In this Cloud Field Day 26 session, Sirish Kondi, who leads the data infrastructure team at Selector, walked through the engineering behind the platform’s hybrid cloud capabilities using a scenario in which an on-call engineer is alerted that a Dallas application is no longer reachable. On-premises environments offer natural boundaries such as sites and data centers where ownership can be assigned, but cloud architectures are flat, with VPCs, subnets, VMs, and routers all at the same level, making it harder to know who should look first. If a BGP session between the two environments fails, the on-premises team receives an SNMP trap and the cloud team receives an unreachability notification, yet nothing ties the two together. To close that gap, Selector built five additions modeled on its existing on-premises tooling: a cloud collection engine, a uniform naming convention, grouping into constructs, a cloud alarm engine, and query access through its agents.

Kondi explained that cloud collection works in two ways. Selector polls provider APIs to build performance trends, but rate limits restrict polling frequency, so short-lived events can slip between intervals. It therefore also subscribes to provider-generated events and alerts, which caught a link-down event in his example that polling missed, although a brief spike to 92 percent interface utilization went undetected. Because provider resource IDs reveal little about which cloud, account, or region they belong to, Selector assigns each resource a normalized name composed of cloud, account, region, and type, followed by the native ID, in a format that works the same way across AWS, Google Cloud, and Azure. That structure turns a question like “what happened in this region” into a simple prefix match. Resources are then organized into constructs such as VPC, WAN edge, compute, Kubernetes, and security perimeters, which customers can extend with their own groupings such as GPUs. Each construct is defined by what can be measured on it, such as CPU, memory, disk, and uptime for compute or address space, routes, and quotas for a VPC, so an incoming alarm arrives already tied to a construct and a team to engage.

The alarm engine normalizes the different event models of Google Cloud Monitoring, Google Cloud audit logs, and AWS CloudWatch using the same naming format, then links each alarm back to the affected resources, so an on-premises SNMP trap and a cloud alarm triggered by the same BGP failure are recognized as one event. Selector’s Rosetta agent now has about 18 cloud-specific tools and works with external LLMs to build queries against this curated data, answering questions like why an application is unreachable when its VM appears healthy or which interconnects currently have BGP sessions down. In response to a delegate asking what happens when the root cause lies in an uncollected source, Kondi said Selector inventories all resources it has permission to read, such as every project in a Google Cloud account, and lets customers exclude items rather than having to list everything that should be monitored, which helps expose coverage gaps. Selector also builds a deterministic path between on-premises and cloud resources by combining VPC route tables, hub route tables, and router BGP tables. Returning to the Dallas scenario, Kondi showed how the platform traces the problem through interconnect data, normalized names, constructs, and alarms to pinpoint the WAN edge as the source, so that the team can take over.