The service catalog is an indispensable component of a team’s software development infrastructure. Anything you need to know about your microservice architecture - whether it is knowing who owns a particular service or what another service’s dependencies are - lives inside this repository. Its potential, however, is not limited to being a storehouse for all the data about your microservices.
To make the most of your catalog, you can run custom queries that allow you to receive and analyze that information in specific ways. Only when you use the data in a manner that is relevant to the development process can you build better software. Here is how Cortex can help you do that.
What purpose does the service catalog serve?
A service catalog maintains a record of all the microservices in your architecture. The core purpose of having one in your developer toolkit is to have access to all the information there exists on each of your microservices, which would otherwise be stored in disparate locations. The catalog pulls this data together into a centralized system that treats it as structured data. Its value proposition then lies in the fact that the information becomes computer-readable, in addition to being displayed in a human-readable format on top of that. The latter allows teams to view and access the data directly, as is. The former, on the other hand, means that it can be manipulated to present insights and provide answers to specific questions that developers may have about their microservices and any related metrics.
So once you have this information in your service catalog, in addition to integration data and other custom data, you want to be able to query across the data. The power of structured data goes beyond being able to generate a few data visualizations. Instead, you should be able to filter it arbitrarily and run complex queries against it with the help of automation.
This is where the Query Builder steps in. Now that your service data is available to the system as structured data, the Builder uses CQL to query across it, as well as across the integration data that is exposed through Cortex’s integration mechanisms. Ultimately, the Query Builder’s job is to help teams retrieve the service data stored in their catalogs and use it to support their development processes. It also transforms your service catalog into an up-to-date source of information that is essential to your documentation efforts in the long term.
Introducing Cortex’s Query Builder
The Query Builder is one of Cortex’s unique features that enables teams to understand their microservices better by querying the metadata available via their service catalogs and integrations. This tool uses the Cortex Query Language to make such requests.
CQL is an abstraction on top of all the data in your service catalog. So the metadata about your services, the customer data, and the integration data are accessible through CQL as an arbitrary integration system. The Query Builder lets you then run arbitrary queries against all that data. CQL’s strength lies in its flexibility, as it opens up various possibilities for the kinds of queries and rules you can define, ranging from identifying edge cases to combining various data sources.
Because integrations are indispensable to the development process, the information they contain is also of great value. Leaving this data out would only allow the Query Builder to paint half the picture, severely limiting the visibility that teams can get.
How can you use the Query Builder?
Say, for instance, that you are interested in identifying all the microservices in your architecture that do not have a description. If you are using Confluence or some sort of static definition, how can you parse your wiki and note which services don't have the relevant documentation? In Cortex, on the other hand, because the data is structured, there will be a description field. As a result, you can easily query against that by saying you want to find all the services that don't have a description. Cortex will find all the services that conform to that particular query, update that information for you, and display it as the result. This is how the Query Builder works with the information that exists inside your service catalog.
It works slightly differently for any integration data that you might want to query. For instance, you want to use the Git repository for a service, load a file from that repository, parse it as JSON, and then run a query to learn about something specific. Then, you want to find all the services that conform to this query. For example, you want to find all the services that are using an outdated version of your CI/CD pipeline and are interested in doing this kind of exploratory analysis on the integration data. In this case, the Query Builder allows you to do that via an API or by parsing a few wiki files.
That is the value proposition of having queryable data. The search capabilities improve massively, and queries can be customized such that they are of use to developers. The contribution of the Query Builder makes it significantly easier for teams to access and retrieve what they need.
How can the Query Builder support you over the long-term?
The Query Builder also lets you create a strong ROI calculation internally for investing in the service catalog. Maybe today you only need answers regarding service ownership or need to list all the tier-one services and write an applicable scorecard. However, a year from now, someone might have a different question about all your services. Not only could the services have changed, but that question may leave the team scratching their heads with no efficient way to furnish an answer. A query builder ensures that you can quickly get the analysis or response you need.
Or perhaps your system experiences a log4j vulnerability, and you need to immediately identify all the services that have not been deployed in 24 hours and have an additive version for log4j. How do you answer a question like that? You can refer to the service catalog and run your query because it is now a source of truth containing all the relevant metadata about your microservices.
Think about the long-term use case of your service catalog, and how to make the catalog more useful for your organization, not just now but even a year or two from today. The Query Builder guarantees that if you make that upfront effort of getting information into the service catalog, you are going to be able to query across all the data that you have put in there. In that case, the catalog is not merely an arbitrary data store but a provider of answers and complex analyses. So the only way that a service catalog is going to be useful to your team for more than six months is if you can tap into the data that you have at present put in there in more arbitrary ways that help you answer questions about it.
Being able to run queries on your microservices data quickly and efficiently is also beneficial when it comes to collaborations. Developers that have not worked closely on or with a particular microservice in the past can make use of the Query Builder to access the information that is relevant to their work. This ensures that despite its complexity, the microservices architecture is not difficult to access by the team. This prevents team isolation by making for smoother collaborations between developers.
Try Cortex’s Query Builder today
The service catalog is indispensable to any internal developer system as it stores and maintains all the data on your microservices. However, it is virtually meaningless to store it somewhere and not actively use it in ways that align with your workflows. It is important, then, to move beyond accessing information about your SLOs, for instance. You have to be able to query that data once you put it somewhere in a structured format. The Query Builder is the only way of doing that effectively. Entering the data into your service catalog is a significant time and energy investment. It is not worth it if, in the long term, you are unable to extract that same data with five times the amount of information and usability. The information from your integrations, including the live data, is equally meaningful and can provide additional value to your development process.
The Query Builder extends the capabilities of your service catalog, turning it into a queryable, dynamic database. Being able to query vast amounts of rich data and receiving pertinent insights in return has the potential to considerably enhance your knowledge of architecture, which is ultimately essential to making any meaningful improvements to it. Book a demo with us to learn more.
