Who needs a microservice catalog and how would it solve the challenges of a distributed architecture style? In recent years, an increasing number of enterprises have replaced their monolithic systems with microservices. These single-function modules offer many advantages as they’re easy to integrate and easy to modify. But while microservices make an organization more agile, they also add a whole new level of technical and organizational complexity that needs to be addressed.
This is where a service catalog comes in. As more and more microservices are added to the pile, engineering teams need to keep track of everything running in new and much more complex infrastructure. After all, it’s not unlikely that a company has up to 200 active microservices in place. A microservice catalog aggregates all of their metadata, dependencies, and ownership information and makes it easier to take action on each service if needed.
A microservice catalog or IT service catalog logs and tracks all the services and systems that are part of a company’s IT architecture. It enables an organization to centrally store critical information about each microservice and allows developers to share this information in a live way.
The catalog not only offers a detailed view of the microservices themselves but also their relationships and dependencies with each other. That’s why a microservice catalog is not only intelligent but also continually evolving.
As new services are being developed, new dependencies make changes to the architectural structure of the IT landscape. In order to stay on top, metadata, ownership, and operational information need to be tracked and made accessible to everyone involved. Thus, like any living catalog, a microservice catalog needs to be properly maintained and updated.
Only if best practices are followed it can serve as a useful tool that gives companies the competitive advantage they are looking for when implementing a distributed system of microservices.
A good microservice catalog allows users to quickly locate and access all critical information needed in case of an incident. It also serves as a great tool for new team members to get up to speed and develop an understanding of an enterprise’s services and how they relate to one another. If this information isn’t immediately clear or accessible, there’s a good chance the enterprise isn’t following best practices for service catalogs.
Since these best practices have already been established, development teams don’t need to reinvent the wheel and come up with their own maintenance methods. Thus, companies can avoid investing valuable resources in setting up their own service catalog and simply rely on knowledgeable enterprise architects or use existing microservice catalogs as a blueprint for success.
Below are the four most important best practices for developers and architects that directly work with IT service catalogs.
A microservice catalog that is outdated might as well not exist at all since updated information lies at the core of its usefulness. Thanks to automatic update reminders from the intelligent catalog itself and its ability to discover new services automatically, this doesn’t have to be an all manual and time-consuming task.
Distributed systems are characterized by their dynamic and flexible nature which is also reflected in a good service catalog. While it can be momentarily complete, it’s always evolving and therefore never “finalized”. However, all information that is available at a given moment should be included.
One of the main purposes of a microservice catalog is to save time and resources when problems arise. That’s why searches should be easy and yield quick results. Teams and individuals might not only be searching for a service’s name but also specific functions which should be taken into account when creating the search algorithm.
Failing to keep the microservice catalog updated is the most common mistake and renders it rather useless. That’s why even smaller enterprises are advised to set up a system or tool that manages updating processes. Automatic reminders that go out to all engineers are much more effective than manual spreadsheets.
There are many benefits that come with a distributed IT landscape comprised of microservices. Most enterprises are compelled by the flexibility, scalability, and resilience of single-function applications. Without having to make changes to the entire system, development teams can make quick adjustments to individual code, fix bugs in case of an incident, or launch new services. However, adding more and more microservices to an IT landscape changes its structure.
With many microservices in place all tied to different owners and ongoing migration, it’s nearly impossible to keep the overview. And a growing complex system that creates uncertainty and confusion defies the purpose of microservices. After all, they’re meant to save time, increase efficiency and reduce overall cost.
An organizational system like a good microservice catalog helps enterprises to fully benefit from their microservices and supports development teams. The key facts for a successful service catalog are listed below.
Every company is different and language is fluid, even when it comes to describing the metadata of a service. That’s why development teams might not always use the same terms to describe the same attributes. A good microservice catalog lets you define your own taxonomy code and make adjustments if needed.
A microservice catalog captures all relevant metadata for service and keeps it in a single location. However, it’s not that useful if development teams can’t retrieve this information and use it in their own applications. That’s why the catalog needs to have an easy-to-use API that follows common access patterns to ensure full portability.
A library tool is only as useful as the data it contains. This also applies to a service catalog. And if the data is not up-to-date or correct, it can cause more harm than the actual absence of data. To keep all data as accurate as possible, a microservice catalog should have transparent and easy updating processes.
The service catalog is more than just a static, searchable library. It should provide a clear map of the IT infrastructure including the communication streams between all microservices. This helps developers get an insight view and covers potential blind spots while increasing their incident response-ability.
20 Key Questions a Microservice Catalog Answers
Download this LeanIX poster to see the 20 key questions a microservice catalog can answer.
Microservices @ LeanIX - then, now and tomorrow
Live Recording - EA Connect Day 2020
Per Bernhardt - Staff Software Engineer - LeanIX
Maximize the Development Efficiency of Your Microservices Landscape with..
Watch this on-demand webinar hosted by The Open Group, where LeanIX shares insights on how we can help bring order and clarity to your complex microservices architecture.
Efficiently Navigate your Microservices with LeanIX
Watch this interview-style webinar on how to build reliable software using a microservice catalog - including a product demo
If done right, implementing a microservice catalog comes with numerous benefits. However, it can also be quite challenging to create a living organizational system that is never fully finished but at the same time extremely accurate and continuously evolving.
Furthermore, everyone involved needs to regularly update the information and have a good understanding of its taxonomy. Thus, there needs to be a certain consensus on how the service catalog is structured and how it should be used and updated.
The more microservices are added, the more complex the IT infrastructure gets. That’s why a microservice catalog serves you best, when it’s implemented early on in the process, so it can organically grow with the infrastructure.
But before getting started, companies and development teams should be aware of some challenges when introducing a new service catalog. The most common ones are outlined below.
Even though naming the purpose, roles and functions of microservices seems pretty easy at first, it can actually turn into a big headache as hundreds of microservices that are all built differently quickly outgrow a naming scheme. That’s why the scheme in place should be easily expandable and make logical sense.
A monolith system is comprised of one giant codebase written in one language and one deployment system. A distributed system allows engineers to choose the best language for the individual service. A variety of different languages adds another level of complexity that can be minimized by a good tracking system within the service catalog.
Having a working microservice catalog in place doesn’t mean that everyone uses it the same way. This is due to multiple custom dashboards for different areas that might not be on everyone’s radar. To increase visibility, links to all relevant dashboards need to be up-to-date and easy to find.
Clearly, not every microservices is built the same. This applies to things like business criticality and hierarchical or numerical properties. In addition, some microservices might have properties that are unique and not shared with others. Ideally, a service catalog captures and tracks these differences which can be quite an organizational challenge.
It is wrong to assume that only larger companies need a service catalog to keep track of their microservices. A development team consisting of 10 to 30 engineers taking care of 100 services need a microservice catalog just as much as a big enterprise with thousands of engineers and services.
And the reason is quite simple: If you lived in a town of 100 people, you probably wouldn’t know everybody’s names, jobs and their relationships to one another.
A service catalog not only logs the name and functions of each service and their interdependencies. It also captures what changes were made on which day or in which week, month or year.
And most importantly, it contains all important information about service owners, how to contact them and where they are located. This can be a true life saver in times of crisis.
With the increased complexity of IT infrastructures, more job roles designed to tackle operational and developing tasks have emerged. A site reliability engineer (SRE) applies aspects of software engineering to the IT infrastructure and operational problems to create a flexible and reliable software system.
As a bridge between development and operations teams, a SRE needs to be knowledgeable in both software engineering and administrative tasks.
In a way, both the SRE and microservice catalog create a better collaboration between development and operations. That’s why many site reliability engineers see service catalogs as a much-needed tool to facilitate the communication between the two teams.
As SREs help manage the microservice catalog by keeping it up-to-date with troubleshooting tips, metadata, contact information and the service architecture, their role has become increasingly more important over the past years.
With microservices replacing monolith systems, service catalogs and Value Stream Management have become must-have tools for future-oriented companies. They offer detailed and living maps of the IT services landscape and are in a state of constant evolution.
But as the ultimate resource for engineering and operational teams, a microservice catalog is only as good as the data it contains. After all, incorrect data can cause more harm than missing data. That’s why you can only take advantage of the catalog’s benefits if it is well-maintained and constantly updated.
Learn more about
20 essential questions that a microservice catalog can answer.
Cataloging microservices helps DevOps teams to visualize their microservice landscape including details on ownership, dependencies, and business context.
Learn more about 20 essential questions that a microservice catalog can answer.