Cloud OOTB fields

Kumar62
Tera Contributor

3 weeks ago - last edited 3 weeks ago

Hi All,

I’m looking for some guidance and would really appreciate any insights or recommendations from the community.

We currently have four custom attributes on the cmdb_ci_server table:

  • Cloud Hosted
  • Cloud Deployment Model
  • Cloud Premises
  • Cloud Service Type

These attributes are populated by an external integration and are subsequently used to determine the hosting type on Application Services 

As part of our CMDB alignment and rationalisation effort, we are looking to retire these custom attributes and replace them with an OOTB CMDB/CSDM-aligned approach where possible.

Has anyone implemented a similar solution using OOTB capabilities? Specifically, we're interested in understanding:

  • Whether there are OOTB fields, relationships, or CSDM patterns that can replace these attributes.
  • How other organisations determine whether a CI is Cloud-hosted, On-Premise, Public Cloud, Private Cloud, or Hybrid without custom fields.
  • Recommended approaches for classifying cloud service types (IaaS, PaaS, SaaS, CaaS).
  • Whether Application Service hosting models can be derived through OOTB CMDB relationships and Service Mapping rather than custom attributes.

Any guidance, best practices, or examples from your own implementations would be greatly appreciated.

Thanks in advance for your help.

0 Helpfuls
  • 224 Views
1 REPLY 1

Vikram Reddy
Tera Guru

3 weeks ago

Hello @Kumar62,

 

The closest OOTB equivalent to your first two attributes lives one level up, on Business Application (cmdb_ci_business_app), not on the server. It has an Install Type choice field with values like On Premise, Cloud, Hybrid, SaaS and Third Party Hosted. CSDM's intent is that hosting classification sits at the application/service level and gets inherited down through relationships, rather than being tagged on every individual server.

For the on-prem versus cloud question on the CI itself, CSDM leans on class and lineage instead of a flag: a server discovered through the AWS/Azure/GCP Cloud Discovery patterns lands in cmdb_ci_vm_instance, not plain cmdb_ci_server, and discovery_source shows where it came from. That class membership plus the "Runs on::Hosts" relationship back to the underlying cloud CI is what CMDB Workspace uses to render the Cloud vs Non-cloud resources view, so Application Service hosting can genuinely be derived rather than stored redundantly.

Where CSDM honestly falls short is IaaS/PaaS/SaaS/CaaS granularity and public/private/hybrid deployment model, there's no OOTB field for that split, and the community threads on this all land on the same answer: model it through Technical Service/Service Offering type, or accept one governed choice field if you truly need it, rather than four bespoke attributes.

  • Cloud Hosted / Premises — replace with Install Type on Business Application, rolled up to Application Service
  • Cloud Deployment Model — no OOTB equivalent, keep a single governed field if required
  • Cloud Service Type — model via Service Offering type or a Technical Service classification, not a flat attribute
  • Cloud detection on servers — rely on cmdb_ci_vm_instance class plus relationship to the cloud CI, not a boolean

Happy to go deeper if you share which cloud discovery patterns you've got active, that changes what's already populated for you.

References

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls