Every operations team I’ve worked with has a naming convention for servers. Some encode the site, rack, role, and environment into a cryptic hostname. Others use a list of planets or cartoon characters that made sense to whoever built the first cluster. On-premises, even a bad naming convention mostly works because the physical world supplies the structure. A server lives in a data center, in a rack, plugged into a switch that somebody owns. When it breaks, its location tells you who to call. Public cloud took that structure away, and most hybrid environments haven’t replaced it. Selector’s presentation at Cloud Field Day 26 addressed this gap, and it got me thinking about how much hybrid cloud troubleshooting depends on agreeing on what to call things.
Cloud Resource IDs Don’t Say Where Resources Live
A cloud resource ID is designed for the cloud provider, not for your operations team. An AWS instance ID or an Azure resource path uniquely identifies an object, yet it tells you little about which account, region, or application it belongs to. The three big providers don’t even agree on how to organize or name things. AWS groups resources into accounts, Azure into subscriptions and resource groups, and Google Cloud into projects. Kubernetes adds another layer, with EKS, AKS, GKE, and OpenShift each using slightly different terms for similar ideas. An engineer chasing an outage has to speak all of these dialects at once, usually at 2 a.m.
Sirish Kondi, who leads Selector’s data infrastructure team, suggested a second difference. On-premises networks have natural boundaries like sites and data centers, and ownership follows those boundaries. Cloud architectures appear flat. Multiple virtual private clouds (VPCs), subnets, virtual machines, and virtual routers all exist at the same levels. Without an obvious hierarchy, it’s hard to know which team should look first when an alert fires.
One Failure Often Shows Up as Two Unrelated Alarms
Kondi described a scenario anyone running a hybrid network will recognize. A Border Gateway Protocol (BGP) session between the data center and the cloud drops. The on-premises network team gets a Simple Network Management Protocol (SNMP) trap. The cloud team gets a notification that an application is unreachable. Both alerts are accurate, and nothing ties them together. Each team starts its own investigation. Eventually somebody opens a bridge call and gets everyone in the same virtual room… and an hour later they realize they’ve been looking at the same problem from opposite ends.
Selector’s fix starts with semantic hygiene: naming things consistently. Every cloud resource gets a normalized name made up of the cloud, account, region, and resource type, followed by the provider’s native ID. The format is identical across AWS, Azure, and Google Cloud. Once everything is named the same way, a question like “what happened in this region?” becomes a simple prefix match on a name. Alarms from Google Cloud Monitoring, Google Cloud audit logs, and AWS CloudWatch get the same naming treatment, so each alarm links back to the resources it affects. The SNMP trap and the cloud alarm caused by the same BGP failure are recognized as one event.
Constructs Put Ownership Back into the Data
A consistent name tells you what a resource is. It doesn’t tell you who should fix it. Selector handles that by grouping resources into constructs such as VPC, WAN edge, compute, Kubernetes, and security perimeters. Customers can add their own, such as a construct for GPUs. Each construct is defined by dimensions, things you can measure. Compute has CPU, memory, disk, and uptime. A VPC has address space, routes, and quotas. When an alarm arrives, it’s already attached to a construct, and the construct is attached to a team. The cloud removed the physical boundaries that used to define ownership, and constructs rebuild those boundaries as metadata.
I like that the constructs come from measurement. It’s tempting to build groupings around the org chart, and org charts change with every reorganization. The things you can measure on a VPC stay the same when the network team gets a new manager.
You Can Adopt the Naming Discipline Without a New Platform
Many organizations won’t buy an observability platform to fix this, and the lesson still applies. Most hybrid environments already have naming and tagging policies in each cloud. Few of those policies are consistent across clouds, and even fewer align with the names used on-premises. A naming standard that encodes cloud, account, region, and type is cheap to define and expensive to retrofit. Mapping resources to owners works the same way. If an alarm can’t tell you who owns the affected resource, finding the right person will dominate your mean time to resolution (MTTR).
Coverage matters too. A delegate asked what happens when the root cause is in a source Selector isn’t collecting. Kondi said Selector inventories everything it has permission to read, every project in a Google Cloud account, for example, and customers exclude what they don’t want monitored. I think that default of monitoring everything belongs in any monitoring design. When resources are monitored by default, new resources are visible from the day they’re deployed unless someone opts them out. When resources have to be opted in, someone has to remember to do it, and eventually someone forgets.
Hybrid cloud gives every team its own tools, data model, and vocabulary. Correlating alarms across those domains only works when the data agrees on what each resource is called and who owns it. Selector does that work as data arrives, not during an incident, when hours are usually lost. Whether you buy a platform or write your own conventions, decide what to call things before the next outage decides for you.
You can watch Selector’s full set of presentations on the Selector AI appearance page from Cloud Field Day 26, and find more from the event at TechFieldDay.com.
