Containers
Series Recap
This is Part 3 of a six-part series on how ITOM architecture decisions become licensing costs. Part 1 covered Servers and VMs – the largest SU driver in most enterprise environments, and the category where Discovery scope and ITOM scope are most often treated as the same thing. Part 2 covered PaaS Resources – the category where a favorable 1:3 ratio creates a false sense of security that cloud provisioning velocity quickly erases.
Part 3 covers Containers. The 1:10 ratio is the third most favorable in the model. The risk profile is unlike any other resource type – not because of what the ratio is, but because of how container environments scale and how teams measure them.
One framework note that applies across all six parts: a resource can exist in the CMDB without consuming a Subscription Unit. Three conditions must all be true before a CI counts – it is in a table mapped to a licensable category, it is in scope for an ITOM product, and any category-specific requirements are satisfied. Unresolved Monitored Objects are the exception: a UMO is counted when ITOM Health receives an event or metric that cannot be resolved to any CI in CMDB, independent of CMDB table mappings or scope configuration.
Note that certain connector types – specifically endpoint-oriented Service Graph Connectors – may affect SU consumption even for resources not yet in full ITOM management scope. Confirm connector-specific behavior with your ServiceNow account team before relying on scope exclusions as a licensing control.
What Makes Containers Different
Under default platform configuration, a container CI classified into a CMDB class mapped to the Container licensable category counts at 1:10. The same conditions that apply to servers and PaaS resources apply here: CI type mapping and ITOM application scope determine what counts.
The difference is that container environments can invalidate a scoping decision within hours of it being made – and the most common measurement approach produces a number that systematically understates actual SU consumption.
Four things separate containers from every other resource type in this series:
- The standard container ratio is 1:10, but container counts in active clusters routinely dwarf server counts and PaaS resource counts in the same environment.
- Ephemeral containers spin up and down faster than licensing review cycles occur. A cluster that runs 1,200 pods at peak and 300 at off-hours is not a 300-container environment for SU purposes.
- Point-in-time snapshots understate exposure. SU consumption is calculated on 90-day daily averages, not current running counts. See the modeling note below.
- Scoping decisions made at implementation can drift rapidly as development teams scale workloads independently of any licensing review process.
Modeling Risk: The single most common container SU error is modeling exposure against a point-in-time count. If your estimate is based on how many containers are running right now, it is almost certainly understating your actual consumption. Use 90-day daily averages from your Kubernetes or CMDB data before treating any container SU estimate as reliable.
The Scale Problem
Container environments do not scale like server estates. An organization with 200 servers and a cluster running 4,500 containers on a 90-day daily average carries more Container SU exposure than Server SU exposure – despite the more favorable ratio.
|
Resource Type
|
Count
|
SU Ratio
|
Total SUs
|
|---|---|---|---|
|
Servers
|
200
|
1:1
|
200 Server SUs
|
|
Containers (90-day avg)
|
4,500
|
1:10
|
450 Container SUs
|
|
Per-unit ratio and total exposure are different numbers. In container environments, both the ratio advantage and the point-in-time measurement habit work together to produce underestimates. The combination is where most unplanned container SU cost originates.
|
|||
Ingestion Paths
Container CIs enter the CMDB through Kubernetes and container runtime integrations. Unlike servers, there is no agent-versus-agentless tradeoff – the integration surfaces pod and container-level CIs directly from the runtime. The scoping and classification decisions that determine SU exposure must be made before the integration is enabled broadly.
Ratios in this series reflect the ServiceNow ITOM Subscription Unit Overview effective February 1, 2024. Customers contracted prior to that date may be subject to different ratios. Confirm which version governs your executed agreement before using these figures for planning or renewal modeling.
|
Ingestion Path
|
How It Works
|
Example Tools
|
SU Ratio
|
Counts?
|
|---|---|---|---|---|
|
Kubernetes / Container integrations / Runtime API discovery
|
K8s and container runtime integrations surface pod and container-level CIs into CMDB tables
|
K8s integrations, container runtime APIs
|
1:10
|
YES - by default, any container CI classified into a CMDB class mapped to the Container licensable category will consume SUs at 1:10
|
|
Scale Risk
|
Define which namespaces, clusters, or workload types belong in ITOM scope before enabling container integrations broadly, and revisit that scope on a cadence that reflects how fast the environment changes.
|
|||
Real-World Scenario: Container Volume Risk
An organization runs 200 servers and enables Kubernetes integration broadly across two active clusters without a prior classification policy. Their container environment includes production workloads, dev/test namespaces, and ephemeral CI/CD pipeline containers provisioned across multiple teams. At the next review cycle they find 6,000 container CIs mapped to the Container licensable category, measured at peak. The 90-day daily average across the billing period was 4,500.
|
Approach
|
Containers Ingested
|
ITOM-Managed
|
Container SUs
|
Unintended SUs
|
|---|---|---|---|---|
|
Broad integration enabled, no classification policy
|
6,000 peak / 4,500 avg
|
4,500 avg - all classified into Container licensable CMDB classes, no exclusions defined
|
450
|
250 unintended - dev/test and pipeline containers consuming SUs with no operational return
|
|
Integration enabled with pre-classification policy
|
6,000 peak / 4,500 avg
|
2,000 avg - production workloads only; dev/test and pipeline containers excluded before integration enabled
|
200
|
None - excluded containers exist in CMDB but are not mapped to the Container licensable category
|
|
Key Takeaway
|
Both approaches produce identical CMDB coverage. The difference is 250 Container SUs, eliminated not by changing the integration tool or method, but by defining which namespaces and workload types map to the Container licensable category before the integration runs - and modeling exposure on averages rather than snapshots.
|
|||
Common Misconceptions
“Containers are cheap at 1:10, so broad container discovery is low-risk.”
The 1:10 ratio is more favorable per unit, but container environments scale in ways that eliminate the advantage quickly. As the table above shows, 4,500 average containers produce more than double the SU exposure of 200 servers. Per-unit ratio and total exposure are different numbers.
“Our container count is under control – we checked last week.”
SU consumption is calculated on 90-day daily averages, not point-in-time counts. Ephemeral workloads, autoscaling, and CI/CD pipelines can move container counts by hundreds within a single day. A snapshot from last week reflects one moment in a three-month billing period.
“Scoping out dev/test namespaces at implementation means we are covered going forward.”
Container environments change faster than most licensing governance processes. Development teams can spin up new namespaces, expand existing clusters, or onboard new workloads without triggering a licensing review. Scoping decisions made at implementation require active monitoring to remain accurate. A namespace exclusion configured at go-live is not a standing control – it is a starting point.
Closing: What to Review Before Your Next Kubernetes Integration Expansion
If any of the following questions produce uncertainty, that uncertainty has a dollar value attached to it.
- Are container SU estimates based on 90-day daily averages, or on point-in-time counts? If the answer is point-in-time, the estimate is likely understated.
- Were dev/test namespaces, CI/CD pipeline containers, and other non-production workloads explicitly excluded from the Container licensable category before integration was enabled – or did those exclusions happen after those CIs were already in CMDB?
- Is there a defined review cadence for container scope that matches the pace at which development teams provision new namespaces and workloads? A governance process that runs quarterly in an environment that changes daily is not a control.
- When did someone last pull a 90-day daily average from the CMDB or Kubernetes data and compare it against the licensed Container SU count?
Container SU exposure is a measurement and governance problem as much as it is a scoping one. The ratio is favorable. The environment velocity is not. Getting the measurement right is the first step – and it requires looking at the right time window.
Up Next: Part 4 – End User Computing Devices
Part 4 covers EUC Devices – the only resource type in the ITOM model where the ingestion path chosen at implementation creates a binary licensing outcome: cost or no cost, independent of data quality. It is also the category where a well-intentioned CMDB or SAM improvement initiative most reliably becomes an unplanned licensing event.
