Erik Lindblom has been a full-stack developer for 13 years. During this period, he has tried to understand all that is needed to deliver valuable and high quality software. Today, that means using cloud services, microservices techniques, and container technologies. Tomorrow? Well, he’s ready to find out.
Does this story sound familiar to you? You and your engineers decide that a microservices architecture is right for your software. You hum, build everything, but on the fifth or sixth serve you start noticing problems. You realize you can’t find anything. Then you start wondering why certain parts of the data are duplicated there and there. You notice that a service is failing and you wonder, “How long has this been going on?”
I suspect some of these questions are familiar.
Fortunately, there is something that can help you answer these questions. A catalog of microservices can give you a single pane in your system. This blog post will explain what a microservices catalog is, why it’s important, and how you can get one for your business.
What is a Microservices Catalog? The quick definition
A microservices catalog is a place where you can see all of the different services you’re building and deploying. This gives you a pane of glass that will let you see what apps you have, where the source code for those apps is, and how they deploy. The catalog can also support many other types of data that you can centralize to give you a holistic view of everything.
Depending on your concerns, you can tailor your catalog to any type of critical data you need across all of your departments. The catalog can also help other developers find out what’s already been released. For example, suppose you have deployed an authentication system. To allow other developers to learn about this service and use the API it has exposed, it would be nice if there was a place where they could search and find this service along with its developer documentation. What would be even better is if the catalog contained examples and other useful information to allow developers to quickly start using this service. The goal is to make sure it’s where developers or anyone else can search, find, and use anything your company has created.
Do I need a catalog of microservices for my organization?
What are the signs that your organization needs a catalog of microservices? One thing that’s probably a clear signal is that developers frequently request information. Instead of having a place to look for data or processes, they ask other developers where something is. It’s a signal that there needs to be something all developers can use to research their answers first instead of bothering others about something a catalog might answer.
Another clear signal is when your organization is growing rapidly, as is the number of teams you have. As you grow, you experience exponential growth in your communication channels. This is not a sustainable approach as communication will become increasingly difficult. Instead, giving people a tool to help facilitate certain parts of communication channels would be beneficial.
A catalog of microservices can help you with certain lines of communication.
A catalog of microservices can help you with some of these lines of communication. This is because it contains useful documentation for each service. With a little work, it’s also self-service so people can browse and find the answer they need without having to involve anyone else. It allows users to find the information they need when they need it.
Another clear signal is when you finally have enough services that one person cannot reasonably follow them all. This is a fuzzier metric and will depend on what you are doing. But if you have so much stuff that you need more than one person to explain what’s going on, now’s a good time to start creating a microservices catalog to keep track of everything.
What should I put in a microservices catalog?
Let’s summarize some of the use cases for a microservices catalog:
- A single website that can display information about the type of service or application you are deploying.
- Links to source code and developer documentation.
- Links and endpoint links for API use cases.
- Links to usage examples.
- Information and links on the production system.
- Production system performance statistics.
- Links to the build system that pushes these services or applications into production.
- Anything else that any member of this team might find useful in using your services.
As you can see, there are a variety of good use cases for such a product. This helps to empower everyone involved and allows people to answer their own questions. This product may start small on day one, but you can provide the ability to add information quickly. Then you can also allow its extension with other sources of information. Very soon, this tool can become invaluable to your organization.
The ultimate goal will be to get as much useful information here as possible. This will take time and retention of information. You will find that some data points will be much more valuable than others. And over time, you’ll focus on what people really need.
Don’t be afraid to experiment! Add data and information that people find useful and get rid of what people find unnecessary. As you grow, keep thinking about how to find the best information.
What are effective practices to follow?
An important feature of these catalogs is to make them authoritative and expandable. You want to make sure this is the true source of information for any part of your systems. On top of that, you want to make sure people can add, update, or even remove rooms.
For new organizations, it’s easier to start with a catalog of microservices sooner than later. Once it’s a known source of information, that ball keeps rolling.
For new organizations, it’s easier to start with a catalog of microservices sooner than later.
For larger organizations, you’ll need to slowly integrate features until you achieve mass adoption and usage. It’s not exactly an easy feat. But the important thing is to start small and keep growing the system. Making a simple list of everything a developer deploys to production is a good start. Then add information to each deployable that people regularly search for.
What are some of the challenges?
So you’ve decided you want a catalog of microservices. What could hinder your efforts?
Well, it depends on how entrenched your business is in your development practices. Getting something new in this kind of environment is always a bit of work. There will always be adoption issues because of something new. But this is where you demonstrate the value of the system. First, you try to find a common data point among your services. Then you try to get information in one easy to use place, if possible. This is how you can start dipping your toe into this idea.
The next problem will be trying to keep things up to date.
In any type of information system, preventing things from rotting is always an important task. It takes discipline and organization to ensure success. This is where it makes sense to have things that are easy to update or change – or better yet, to have something that updates automatically. If much of the data in the system is automated, no one has to deal with it. However, there will be parts of the system that just need to be organized manually from time to time. It will take discipline to ensure that the information is accurate and correct. As the system is refined, we hope manual labor will be reduced to as small a footprint as possible.
Conclusion and more
I hope this blog post has given you an idea of what constitutes a good microservices catalog. And maybe that inspired you to start looking for ways to create one.
You have a lot to track, so try to ensure that you don’t have to track all your different services in special bookmarks or in everyone’s browser. Make the microservices catalog a one-stop-shop for every team member. This way, you can make sure everyone on the team can get the answers they need without having to disturb others. Plus, everyone can get an overview of everything that’s going on.
Finally, do you need help managing your distributed cloud architecture and controlling sprawl? To verify configure8. Unlike container-based solutions that stop at service boundaries, configure8 built the first universal catalog with a knowledge explorer interface that organizes your entire software development operation – all of your services, all of your infrastructure, and key data such as performance, security, cost, ownership, documentation, dependencies, and dependents, into one place.
Characteristic picture Going through Pixabay. Interior images provided by the author.