Why a microservice catalog alone doesn’t cut it for incident management

Just like we don’t say “service proliferation is becoming a thing” anymore because, well, it’s obviously already a thing, can we stop saying that all you need for proper incident management is a microservice catalog? That’s like saying that all you need for a robust modern web application is a database. Maybe you could get away with it, but with so many incredible advances available … why? In the hopes of motivating organizations to think of the service catalog as a component of a larger system, the Internal Developer Portal (IDP), instead of the only thing they need, we’ve collected some of our thoughts and experiences here.

To take a step back, the primary concern that we have with systems that centralize the service catalog in the incident management experience is that there’s a lot more to the story than your microservices. The assumption that most organizations have transitioned completely to microservices is a bold one: it’s almost universally true in our experience that in addition to the shiny, nice microservices that we all enjoy working on, there are … other services too. And there’s always infrastructure. And workflow data. And everything else. The way we look at it, the more inputs you have into your system of record, the more comprehensive your understanding will be of even the most complex scenarios, like when your hair is on fire from an incident. 

Once your IDP is receiving these key inputs, it becomes clear that the class of problems that DevOps, SRE, and Developer teams alike can solve, when compared with a Service Catalog on its own, are considerably more interesting, complex, and vital to the success of modern organizations.

Suddenly, instead of simply browsing your catalog, you’re querying your Developer Portal. Instead of focusing solely on your Microservices, you’re seeing the full picture. Suddenly, you’re able to do things like:

• View, filter, and search all of your global, cross-cloud cross account resources in one place
• Drill into costs at the service level by environment
• Ask questions like “How does that latest cloud provider outage or security vulnerability in a 3P library impact me?”
• Avoid the plethora of tools, and more importantly avoid the slow, complex cloud consoles much of the time
• Enable developers to deploy with confidence because they understand the blast radius in full fidelity via dependency and dependents

In this context, the importance of seeing your system as a whole, having insight not only into your containers and how they link to your services, but really, the whole system, the entirety of the data generated by your Software Development process, becomes very clear.

So yes, you need a service catalog – but that’s just one piece of what modern engineering teams need to stay on top of their growing, complex infrastructure: a fully-feature Internal Developer Portal.

Want to learn more about what teams can do with a software development knowledge graph? Click here. Want to try our end-to-end IDP for free? Get started here.