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!

[Ed Laar1]

Hi community,

Regarding microservices and the modelling in the CMDB I have a new (or perhaps not) view on this.

First of all: What is a microservice? Let's assume that a microservice is a service in itself used in an Application Service. example: Grand access to an Application is often done by an identity manager. If access is granted a 'Yes' is send from the identity manager to the Application Service. I consider the identity manager as a micro service. 

Within the ServiceMap of the Application Service this microservice should be there so if the identity manager fails the Application Service is affected and the users can be informed or when an incident is raised on the Application Service like "I can not login" this incident can be routed to the solver group responsible for the identity manager.

As the identity manager is used in more Application Services (and that's why it also is a microservice) there is absolutely no need to have all the components providing the identity manager under all the Application Services that are using the identity manager.

The identity manager itself and it's components should have a CMDB registration where Indentity manager is the Application Service and the components providing the Identity manager service under it.

You can see Identity manager service USERS (all Application Services using the identity manager) and the Identity manager service PROVIDER.

Question is: How to registrate the Identity manager service (in fact a microservice) within the Application Service using the Identity manager?

My suggestion:

Within the Application Service that uses the Identity manager service, create an Application Service=Identity manager service and relate this one to the Application Service using the Identity manager service

AND

Relate the Application Service=Identity manager service (provider) to the Application Service=Identity manager service. Also register under this Identity manager service (provider) all the components that provide this service.

I think in this way we have modeled a microservice in the 'use' and in the 'provide' environments and all the usual operational processes can run. For sure there is something to do regarding Service Mapping: How to deal with the Identity manager service within the Application Service using the Identity Manager?

Looking forward to your reactions,

Many thanks in advance!!

Ed 

[Paul Kilkelly]

Hi Ed. I think the clue might be your question: the software process in your application service is making a call out to an interface presented by a software process running outside of your direct control that provides an identity service.  You want to know when that identity service is affected as this will impact your application service. 

If I have that correct then the software process your code interacts with (an application CI presenting an Identify API, but more likely some kind of load balanced set of application CIs) must be owned and operated by another application service that offers the identify service.

In this scenario I would use a CI relationship to model the dependency of your application service (as a consumer) on this 'identify' application service (your provider).  If the identify service provider offers a service guarantee then you may also want to make use of the service offering dependency to capture that.

Note I didn't use the word 'microservice' here: I didn't need to but then perhaps I've missed your point? 

[Ed Laar]

Hi Paul,

Thanks for your suggestion of relating the Application Service consuming the Identity Service to the Identity Service Application Service. In this scenario there is no need for an additional Application Service in the Application Service consuming the Identity Application Service.

To be honest I personally should go for the scenario where the Identity Application Service is part of the consuming Application Service servicemap; so consuming and providing Application services are related but within the same servicemap. The providing Application service is related to the Application service in the providing servicemap containing all the components needed for providing this  application service.

This is just to devide between providing and consuming application services and to have from both views a complete servicemap.

What do you think about this idea?

Ed

[vikas_w]

Hi Ed,

Very interesting thread, I am having similar requirement and my initial thoughts are inline with you.

Let me bring in another perspective / requirement here, as it's very much possible that multiple micro-services (belonging to same Business application) make use of same underlying infrastructure component. Should we really create micro-services in application service table and relate it to an application service?

How about creating a new micro-services CI type (may be an extension of cmdb_ci_sevice) and relating these micro-services to business application record?

Pls share you input/feedback.

Cheers

Vikas Wakade

[Ed Laar1]

Hi Vikas,

Thanks for sharing your idea. My thoughts are perhaps a little more practical in a way that I want to a) show which micro services are used/consumed by which application service and b) when a micro service fails which application service(s) are affected.

What do you think about this?

Ed