CSDM Service offering for IAAS, PAAS, SAAS

[Nilanjan1]

Is there any way to identify a Cloud Service as IAAS, PAAS, SAAS and what all attributes can be used to identify this?

Regards

Nilanjan

[CMDB Whisperer]

@stig Not sure it would be advisable to eliminate the Application Service just because it is in the Cloud.  While it is true that there may not be specific infrastructure CIs associated with the Application Service, it still plays an important role.  It represents the actual application (including SaaS, PaaS, etc.) that has entry points for user access, and it also provides the ability to identify application related incidents, changes, etc.  Business Application alone won't suffice they are purely logical CIs and don't represent operational, serviceable entities.  And while it is technically true that technically you could use the Service Offering itself as a CI for ITSM tasks, this would not be appropriate because it would not provide links back to the Business Application that is responsible for the incident.  Finally, just because it is a Cloud Service does not mean you can't have different end points for Dev, Test, and Prod (as we do in ServiceNow which is PaaS).

So in summary I would still recommend using the Application Service for the Cloud Service, and associate it with the Service Offering and the Business Application.  The main thing that is different about Cloud Services in reality is how the infrastructure is deployed.  As far as the CSDM is concerned, it still plays the same role as an on-prem deployed Application Service.

[Stuart Tucker]

The approach we are looking to adopt is exactly as you have said, with the Application Service linked to a Business Application, but when the item is third party or cloud then relate the Application Service to a Service Model, rather than a Technical Service Offering. As it is not something we are internally supporting, represent that via a Product Model (Service Model) that describes what you are getting from the Cloud/3rd Party host.

[CMDB Whisperer]

I put together this alternate view of CSDM to highlight the actual function of each element within the model.  As shown here, Application Service is critical for any application that is accessed by users, regardless of how it is deployed, on-premises or in the cloud.

[Mark Bodman]

From a CSDM guidance perspective, it's a critical component in the model to link any resource, including cloud resources, with the consumers of a service. 
I recommend reviewing this end to end cloud application video, where we discuss integrating with the cloud at the IaaS level of detail.  The role of the Application Service is particularly critical in this situation to manage the cloud resources over time using TAGs.  PaaS and SaaS solutions have a similar need, we cover that to a large degree in our Platform Examples  where ServiceNow is discussed which could be considered both. 

[Community Alums]

[Updated}

If there is only one active implementation of the "Cloud Service" Business Application deployed to a specific environment(e.g., dev, QA, Prod), I would use the version field of the Application Service as CMDB Whisperer recommends.

However, if the "Cloud Service" Business Application has multiple concurrent deployments, each using a different target platform (IAAS,PAAS, or SAAS), I would include IAAS,PAAS or SAAS in the Application Service name to make them unique and easier to select from a list. For example:

Cloud Service - IAAS(Prod)

Cloud Service - PAAS(Prod)

Cloud Service - SAAS(Prod)

Business Applications may also be concurrently deployed to more than one application stack. For example:

• during datacenter migration , deployments of a Business Application may exists in both datacenters until the old one is decommissioned.
• during migration from on-prem infrastructure to a cloud platform, multiple deployments of a Business Application may need to co-exist until migration is completed.
• manufacturing sites and retail locations will each have instances of the same Business Application.

In these cases, your naming convention for Application Services should include the location as part of the name. I recommend adding @<location> to the name of the service, similar to the way that Applications are named when deployed to multiple servers.