Why now’s the time for a new (micro)service catalogue

One thing I’ve been asked frequently over the past few months is why do we at effx feel it’s important to introduce a new service catalogue? From an ITIL perspective, there’s plenty of tools that already exist. What makes something geared around microservices different than the solutions of the past?

The advent of microservices, more recently driven by technology like containers and their orchestration systems, has made it more complex to understand what exactly is what in your architecture.

We’ve found that the cognitive overhead of simply remembering a microservice’s intended purpose becomes difficult once you hit the 20 services mark.

Why is it so difficult? Beyond challenges with service ownership, let’s discuss a few of the reasons:

Naming things is hard

I won’t repeat the quip about the most difficult things in Computer Science, but when it comes to naming services, it’s an incredibly difficult thing to do. No naming scheme scales to hundreds of microservices, much less thousands. Let’s take a microservice whose purpose is pricing as an example:

• You could name it “pricing” and call it a day, but might end up being too ambiguous for all of the different roles a “pricing” service might have. Also, imagine trying to search across a company wiki for “pricing” to get details about it and ending up finding literally every mention of the word across things like pricing of your corporate insurance, marketing documents on pricing & packing or an offhand comment on a design doc unrelated to the “pricing” service.
• Or, let’s say you’ve been naming microservices at your company after Game of Thrones lore and you call it the “ironbank” or “braavos” microservice. Sure, there may be some relation between pricing and those terms, but if everyone hasn’t carefully watched or read The Song of Fire & Ice, they won’t get the reference — and it may not even totally be accurate.

We’ve seen most companies choose the latter option. This makes it critical to be able to search and find based on the name (if you already know braavos exists) or its purpose (“the pricing service”) in the service catalogue.

Using the best language for the job

One clear benefit of having a monolith is that it’s a simple entity: written in one language, one deployment system, and one giant codebase for your engineers to fully grok. However, when you switch to a microservices architecture, most engineering organizations allow the flexibility of choosing the best language possible for the intent of that service.

When you end up using a variety of languages — or even versions of those languages — things can become difficult to track. Was that pricing service written in Go? Or is it one of the few services we decided to build on the JVM? Wait, did we upgrade it to Java 8 and which JDK? Hmm. Was this a data analysis service that we wrote in Python? Did we actually upgrade all of the similar services when the recent vulnerability hit?

All of these questions about what something is can be answered with a new, modern service catalogue that keeps track of the technologies, languages, and libraries — and the versions used! — across your fleet.

The proliferation of dashboards

I’m sure you’ve seen it by now. For each “pillar of observability” you and your team have chosen the best-of-breed tool. You’ve gone through the effort of building custom dashboards in your logging tool or maybe you’re using the canned dashboards for viewing time series data. Your AWS cost tool is on another dashboard and maybe there’s one for operational understanding and another for your finance team.

When things go wrong with your microservice, how do you make sure everyone on your team is starting from the same place before deep diving? Do you share bookmarks? How do you keep them up-to-date and in-sync across the team?

Ensuring that your service catalogue has the most up-to-date links to the different tools you use every day so that everyone on your team — and everyone across your engineer organization — can jump to the right tool at the right time when they need it most.

Different tiers of importance for microservices

Not every microservice is the same — not just from the aspect of being business critical, public facing, or some hierarchical, numerical tier. Each microservice has properties that aren’t necessarily properties that other microservices would inherently share.

Sure, service catalogues may track a singular group that a service belongs to or a tier of service. A modern service catalogue would allow freeform key-value pairs to track things that are important to you with common patterns that we’ve seen. You should be able to track that a service belongs to a group (or many!), has a particular tier that matches how you define tiers internally, and maybe other items like:

• this service is in scope for GDPR, or HIPAA
• how is the service deployed or orchestrated e.g. deployment via kubernetes or ECS
• is it tagged for a large internal migration from one platform to another and where is it along its journey

… and the possibilities are endless.

All of the above are organizational challenges that a modern engineering team faces when fully operating a microservices architecture. At effx, we’ve built our new service catalogue to address these specific concerns and especially, how to ensure that they’re always up-to-date.

With integrations into Kubernetes, serverless platforms, and by hooking into your existing tagging schemes, we can import your catalogue and begin helping you shape it to always be up-to-date, accurate, and dynamic enough to ensure that it’s the most helpful tool to know what something is when you need it most.

Sign up for a demo at https://effx.com to hear about how this can solve your toughest organizational and microservices challenges.