snitko

I've been watching lots of talks on microservices lately - some of them are by people working at big companies that have 1000+ microservices. Strikingly, even at that number, they seem to have a flat structure for those microservices: it is claimed they're all independent, yet there certainly is some coupling happening, obscured by the fact that they manage to catch errors post-deployment by carefully rerouting requests to an instance with the previous release of the said microservice - in case the latest release responds with an error (or they use somewhat different in details but similar in spirit techniques).

The question I have is: wouldn't it make sense to have an hierarchical structure for mircoservices to achieve the following things:

1. Ease of understanding and being able to hide the parts of the system you don't need/want to understand: you'd only need to follow the branches of hiearchy deep enough to satisfy your necessity to know the details.

2. Less chaotic task management: when a task is created by the product manager/owner, they might not know and/or anticipate which microservices need to be changed to complete the task. With an ierarchical structure, they might as well just assign the task to, say "Authentication Service" project, but changes would have to be made to the "Geolocation service", "Personal data" and "Access control and denial" services. As a result, a task is automatically (or semi-manually) devided between the teams responsible for those sub-services.

3. Explicit coupling declaration: while each service might keep its individual team and deployment independence, hierarchy allows us to see which other services might have an issue with the this particular service after the new release is deployed.

What hierarchy actually means - is it purely logical, or does it manifest itself in requests proxying or in some other way - is not that important - it'd be up for the top-level engineering team to decide.

Thoughts?