Modeling micro services / APIs in CSDM

[jonathanwaldo]

I work for a large global logistics organization that is seeking to utilize the CSDM to model its complex technology environment which heavily leverages the use of micro services / APIs in its application architecture. Currently we use the "web service" class to document about 3,700 unique components, created and updated as they are spit out of our DevOps pipeline. They are not discovered and thus, these are not instances of the services, but a representation of the code itself. Some of these components are mission critical; externally exposed to our global customer and supplier base or internal facing choke points for processing high volumes of transactions. An example could be an API that is used by a number of applications to call data from the MDM database. We often use these CIs in the Incident, Problem and Change processes.

My question for the community is, what is the right place to put these components in the CSDM? A business application with child Application Services representing environments? It kind of makes my head spin to think of 3,700 business applications just to represent our micro service and API components, along with 3-4x more for representing lower environment instances of those services.

Thank you!

[jonathanwaldo]

Hi Ed,

Where do you think an API specific class (other than the out of the box "web service" class which is designed for discovered web services) fit in the CSDM? my thought is that tickets would be assigned to the child application service of a Business Application that represents the code / business logic that is performed by the API.

[Ed Laar1]

Hi Jonathan,

I should consider the creation of a CI class = Integrations where the API's can be registered. Create an attribute=type where you can put API as a choice. In this way all API integrations can be easily recognized.

Register all your API's in this class with their specific name and so on. Before doing this also create a Product name and so on for every API in a way that API's can be treated as 'normal' products to enable versioning etc. etc.

In this way every API is a CI and thus Incidents and Changes can be created, tracked etc. Also these CI's (in fact API's) can be included into the Service tree.

Writing this, perhaps it's better to create a CI-class for Integrations and due to to the fact that different types of integrations exist create child classes for the specific types like API, ESB and so on.

Pls let me know your experiences around this.

Cheers,

Ed  

[Alec Hanson]

That is how I would see APIs being setup and configured as well if you want to manage the specifics of the interface.

[David Say]

@jonathanwaldo I am working through this same scenario, currently.  I am curious how you decided to proceed...

[Aaron Butell]

Looking into this as well... I thought initially you would model your APIs as "Technical Services".

"Technical service is a service type that is published to service owners and typically underpins one or more business or application services. Using technical services lets you view and manage the technology you provide to the business. If event management is deployed, you can monitor service performance and identify health issues for related infrastructure configuration items and application services. The operational view of technical services are mapped to cmdb_ci_service with a service classification of  “Technical Service” while Event Management enabled technical services are mapped to cmdb_ci_query_based_service. A technical service may have an operational view made up of one or more technical service offerings."

Reference:

Common Service Data Model (CSDM) 2.0 White Paper

https://community.servicenow.com/community?id=community_article&sys_id=f54be0f7db984c146064eeb5ca961...