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]

We utilize both containerized and non-containerized hosting of these services. The unique identification would probably be the github repo name which what we are using to name them currently.

[james ferguson]

As application services demand an endpoint to be defined, it would seem to indicate to me that what you're suggesting would be the right way to model a microservice. These could then be grouped by membership to a business application and the applications related to a capability. As microservices should be independently deployable and scalable, each microservice (application service) can then have its own reliance on hosting infrstructure defined and indepently release managed.

[Mark Bodman]

This is a topic that is coming up more frequently these days.  I'm curious if you expect to treat Microservices the same as API's that are exposed, requiring careful governance and management?  Or are you looking to create the CMDB entities automatically as part of your CI/CD pipeline?  Seems like you cover both in this ask.

[jonathanwaldo]

Hi Mark,

My gut feeling is that the answer to the question of whether or not micro services should be treated the same way as APIs that are exposed is "yes". The reasoning so far behind that assumption is that we currently managing them using same processes we manage external APIs and they are essentially the same thing, just with differing levels of volume or impact to customers.

On the flip side, it feels as if this creates a lot of bloat towards the top of the service stack. We don't currently use Service Mapping, but I can't imagine it would be practical for each of these micro services to be their own unique entry points (on top of the environment and version variables that would also be unique Application Service CIs).

Jonathan

[Ed Laar1]

Hi,

My idea's and considerations about registering API's or MicroServices are the following:

API's functionality is the exchange or data between applications: You can say a specific type of integration

An API is in fact a piece of product with a name, version, supplier group, support group, functionality etc. etc.

There should be the possibility to a) raise a ticket on an API in case of malfunctioning and b) evaluate the impact of an API to services where the API is used

Reviewing all of this I should consider an API or MicroService as a CI. I should suggest to create a specific CI-class for this. As an API can be considered as an integration type it seems a good idea to create a CI-class for Integrations where an attribute=API can determine the integration type. Other types can be MicroService, ESB or something else. I hope a specific CI-class for Integrations becomes available OOB soon.

Doing this the API can be added into the Application Services CI stacks where they are used although this might be manual work ... Impact determination on Application Services is immediately available as the API acts as a 'normal' CI with all it's pro's and con's.

Hope this helps and awaiting any comments or reactions,

Cheers,

Ed