Service Instances vs Dynamic CI Groups

[Robert Campbell]

In the past we have created FKA business services (cmdb_ci_service) and added dynamic CI groups to them to take advantage of the auto-removal of stale infrastructure. There isn't necessarily any specific pattern we can use to have a completely automated service but we want to have as close to an automated service as possible. 

We thought of doing away with the service and only using a dynamic CI group. The problem with doing this is the structure according to the CSDM 5 White Paper.

This says that the Dynamic CI Group is tied to the TSO but it doesn't show a relationship to the service instance anymore (not sure if it ever showed it but that is the current relationship). From previous documentation, the service classification would determine the behavior but it doesn't seem to be that flexible anymore. I wanted to get some clarification on that before proceeding.  

[Barry Kant]

Hi Robert,

Dynamic CI Groups have a dual use:
1 - To group CIs and link to TSOs (service_classification='Technical Service')
2 - A special type of Service Instance (service_classification='Application Service')

So you can still do both if you read the CSDM paper Service Instance (can be a Dynamic CI Group, like all of the extends of the base Service Instance table).

BR,
Barry

[Mathew Hillyard]

Hi @Robert Campbell 

The main reason to build things into Dynamic CI Groups is to relate common types of CI together - e.g. servers, databases, etc.

Application Services (now under the Service Instance umbrella) are a hierarchy of related CIs with directional and specific relationships designed to show impact analysis and dependencies.

When you say you model services linked to dynamic CI groups, does this include what would normally be known as app services as per the description above? If so, is the reason that you are not using application services that you don't have discovery able to populate CI relationships and/or service mapping to do the top down mapping? If not then I suppose Dynamic CI Groups are OK for now but they're all at one level so far from ideal for any kind of dependency or impact mapping.

I guess whether it depends on whether you want to follow CSDM or not. You either do all of it or none of it - a halfway house doesn't work.

Another limitation is that in the dependency views due to a platform limitation you cannot see which service offerings a member of a dynamic CI group belongs to as these views exclusively rely on CI relationships, and the members of a DCG are not build on CI Relationships but on Service Configuration Associations. You can view downwards from Service Offering to DCG in dependency views then click the Details button to see the related CIs but not upward from the CIs.

I hope this helps!

Mat