Joey Parsons is the Founder & CEO of effx. He’s spent his career building cloud infrastructure, running microservices and managing platform & reliability engineering teams at companies like Airbnb, Flipboard, SugarCRM, and Rackspace. This article was originally posted on effx's blog.
For engineering teams, getting product into the hands of customers as quickly and reliably as possible is top priority. A move to a “you build it, you run it” and DevOps model has helped.
Microservices have also been the go-to avenue to get there. Teams have clearly understood the benefits of microservices (speed, scale, flexibility, and resilience), but also for many, there’s definitely been some hesitation given the overhead and specialized engineering talent needed to migrate to, operate, and scale this environment.
As more organizations move to building their products and platforms using microservices, engineering teams need an overall view of everything running in their entire, complex infrastructure. This is why now’s the time for a microservice catalog.
So what’s a microservice catalog?
A microservice catalog is a flexible, portable, accurate, and intelligent view of all your microservices. It provides each engineer critical information like an aggregate of all microservices and their metadata, service ownership, dependencies, how to operate, and take action on each service when an incident happens.
At effx, the microservice catalog is the basic building block of how we help our customers along their journey with microservices. Below are just some of the things it helps your engineering teams with based on a combination of what we’ve experienced as practitioners and working with hundreds of the top engineering organizations around the world.
- The ability to search for and discover all of your microservices no matter what infrastructure or platform they’re running on
- Ensuring you build microservices with excellence in mind and emphasizing quality is consistent across your company
- Keeping your microservices up-to-date through the constant change of migrations
- Having confidence and necessary context during complex microservice incidents
However, not all microservice catalogs are built the same. And since this isn’t our first time building a microservice catalog, we’ve found that there’s key tenets to how we’ve built ours that will help you get the most out of it.
There are common challenges that most engineering teams using microservices face on a regular basis. However, if you ask an engineer at two separate organizations for the most important metadata to track for a service, that commonality ends. The language used to describe what are seemingly common attributes may be completely different!
For example, what one organization may describe as a “tier” of service, another may call it a “priority”. A “group” versus “pod”. Some may care deeply about tags for compliance while others may not.
One team may prioritize dashboards that combine both time-series data and logs into one, while others may have a separate dashboard for each pillar of observability. Runbooks could be a separate entity or a team may have a culture of having that information directly in its alert descriptions.
Every company is different -- and at times, those differences exist on a team level!
A flexible taxonomy for how metadata is described and labeled allows your team to build a microservice catalog that makes sense for your cultural engineering norms, versus fitting a strongly-opinionated structure.
Imagine if you could only use data from another common catalog-like service, Wikipedia … on Wikipedia.
When developers build systems to send microservice metadata or events into a platform, they expect to be able to also retrieve it to use in their own applications. An API-first microservice catalog is a must.
Once the metadata for a service is aggregated into a single location, the applicability of that data in other platforms is nearly limitless. Source of truth information like service ownership can help drive priorities or roles and responsibilities in other platforms that require it.
Having a well-documented, easy-to-use API that has strong library support and follows common access patterns like REST helps ensure that your platform is both extensible and portable.
Check out our effx API documentation
In the sales world, folks describe CRMs as only being as useful as the data inside of it. A microservice catalog is no different.
Beyond being appropriately filled out, engineers need to feel confident that the data is up-to-date. A single pane of glass with incorrect information, whether it be broken links or out-of-date data can actually be more harmful than the absence of data.
How does one go about providing an accurate catalog? Most importantly, you want to make it simple and easy to keep up-to-date by having that process live where your engineers are every day: in code.
Last but not least, a microservice catalog needs to move beyond static, searchable information and help engineers derive unique insights to help them in their day-to-day.
Combining microservice event data with the overall connectedness of microservices to one another, you can provide intelligence where even your best engineers have a blind spot.
Dependencies, like which services are talking to one another, can change after a simple deploy. Having this information when the system goes awry and related to events within your infrastructure can up-level your frontline engineer’s incident response ability.
The key benefits of microservices like speed, scale, autonomy and resilience are only unlocked by organizations that invest in their engineers’ abilities to better navigate, operate, and evolve its microservices day-to-day. The effx platform, and its unique approach to a microservice catalog, is here to help your team turn its pain into a competitive advantage.
Want to learn more? Sign up for a free trial and start building your microservice catalog today.