A Brief Context
The good thing about working with enterprises, are the problems that you encounter, when you are doing something at scale.
All my life, I have worked with big enterprises that spanned hundreds of teams, thousands of projects/products, and millions of lines of code.
While I always envied the kind of passion and velocity, that my friends at startups experienced, the different category of problems that crop up at scale (in an enterprise) kind of made up for it.
One such problem, that normally looks trivial when you start your journey, but can assume magnanimous proportions when you start to scale, is how to identify the ownership of services across your organization, especially when you need some details/need to report an issue related to that service.
Service management at scale
In today's world, it is widely accepted that microservices are a better way to design systems, rather than monoliths ( there could be a few exceptional circumstances, but we will not go over them in this article).
Especially for Cloud native workloads, which are supposed to take the full benefit of cloud services and its advantages, it makes sense to go with a distributed, loosely coupled architecture that is comprised of individual microservices talking to one another.
And it is indeed a valid argument that microservices lets an engineering organization grow and scale, by providing better constructs for isolation and independence to engineering teams.
All of these looks great, when you have 5-10 services in a single product. Every developer knows who is responsible for each service, and if something goes wrong, they can contact the developer/owner of that service, and get the issues resolved.
Fast forward to a time, when there are hundreds or thousands of services across a multitude of teams across your enterprise. Every day, new services are being created and added on to that list.
The chaos that comes with microservices, start appearing as cracks in the system, and becomes noticeable when you have 30+ microservices.
Over time, this becomes unmanageable, and when something breaks, your operations team have no idea who to reach, to handle/fix that issue.
The below image is a snapshot depicting the tremendous scale of microservices at Uber , mid-2018, observed by the distributed tracing tool Jaeger -
And, here's Netflix -
Even if your company isn't the next Uber/Netflix, there is a high probability, that over time, your service landscape will also start to look like the above.
Everything breaks at scale
These issues start exploding at scale.
Once your enterprise as a whole starts adopting the microservices architectural style of functioning, it wont take long for each team/product/project to ship hundreds of services.
Over time, this effect will get compounded and you will get thousands of services across your enterprise, with no governance or oversight.
Problems with managing services at scale
- There is no clear ownership, nobody knows who to contact if a particular service breaks.
- No easy way to search for a service to be able to reuse/consume it across the enterprise.
- No way to easily access documentation/related information about a service, and how to consume it.
As pointed out by John Laban, in his blog - https://www.opslevel.com/2020/04/21/why-you-need-a-microservice-catalog/,
A catalog to the rescue
A microservice catalog is a record/list of all the microservices that an enterprise has in its ecosystem. It tracks all the services that an enterprise is running in production, and describes information about those services - what each service does, who owns it, and how to operate it.
It has specific details on each service like :
- Owner of the service.
- DL/SNOW queue of the team managing the service.
- Language/framework of the service.
- Supported consumption types.
- Links to approved documentation for that microservice.
Using a microservice catalog, any user in the enterprise can quickly find a service, it's usage, it's owners, and so on.
It gives an enterprise a sense of governance and control at scale, as you have a single source of truth that you can start to refer to, while trying to answer other questions.
Modern day microservice catalogs can move a step further and even show you dependencies between services, consumer details, usage metrics and so on.
So, you can build quite a lot of analytics on top of the data once you have centralized it to some extent.
As you can see above, services will publish their information to the catalog, while consumers will leverage the same catalog to find relevant information about what they want to consume.
How to start
An enterprise can start small, as in documenting services on a shared spreadsheet, and capturing information like :
- Name of service
- Owner Team
- Director/manager of the service
- Lifecycle of the service ( GA / Beta / Deprecated )
- Slack channel link
- JIRA board link
- Health URL/endpoint to check service status
- Dashboard/centralized location to search for logs
However, as the number of microservices start to grow, say between the 50-200 mark, the spreadsheet/manual way of documenting and cataloging microservices do not scale, and this leads to the enterprise searching for better, more enterprise-grade options.
From there, it might start using an enterprise grade service catalog tool like OpsLevel, or Cortex to manage the myriad of services at scale.
Many companies might even invest a lot of money, effort and time in building an in-house microservice catalog, from scratch as part of their engineering effort.
It depends upon the organization and the Build vs Buy pattern they follow, but normally speaking, it might be a better decision to go for a 3rd party tool, rather than investing in the same thing, especially if the 3rd party tool ticks all the boxes you need.
When you start using an enterprise-grade microservice catalog tool, it abstracts way the required information behind an intuitive UI, and provides the ability for the consumer to query the catalog for specific questions on a particular service or a set of services.
You can tag services using rich metadata like environment, service tier, SLA, etc. which makes it easier for consumers to filter the data, and also to decide whether they should call the service or not.
Conclusion
Scaling microservices and the challenges associated with it, particularly when it comes to needing an enterprise-grade tool to manage it, might appear trivial at first, when you only have a few services, but once you cross the magic mark of 30-50 services, it actually starts making sense to invest in a solution to this problem.
Fortunately, there are quite a few tools, and approaches available in the market, which focus on how an engineering team can start solving this issue, at scale.
You can start small, but ensure this is a part of your overall engineering strategy, and approach, so that you at least have all the information and metadata handy, when you do decide to go for an enterprise-grade service catalog office.
References -
https://www.opslevel.com/2020/04/21/why-you-need-a-microservice-catalog/
https://www.cortex.io/post/why-you-need-a-microservices-catalog-tool#:~:text=A%20microservices%20catalog%20is%20a,track%20of%20several%20disparate%20microservices.
https://www.youtube.com/watch?v=mwsfNio2Dho
Top comments (0)