4 ms·

It would be interesting to see the ratio of how many micro services an org maintains vs the number of engineers.

bob1029 6y ago
I think this could be an interesting metric to apply across the board. R = # of micro services / # of engineers If R >= 1, this is potentially problematic and may indicate engineers being unable to work with the code of their peers. Operating in this regime would be viewed as risky. R can go to infinity very quickly if you go down this path without very deliberate planning, involving the consensus of both the entire management and engineering staffs. If R < 1, you have more engineers than micro services. People share code bases and are not afraid of each other. This is probably a safe regime to operate in, even if you completely fuck up the intent of micro services. I think R could also serve as an arbitrary bus impact scalar for the org chart.
- closeparen 6y ago
  Depends. R > 1 can also mean that projects are getting wrapped up and left alone, and their teams moving onto new stuff. Three people per module-project, three project cycles in, will have R = 1. That is not necessarily a bad thing, although it can be a liability if they all suddenly need attention at once. R < 1 can mean that either the same functionality is getting reworked over and over, or people are breaking separation of concerns and concatenating unrelated stuff onto existing modules. Ideally you want to be spotting the common patterns and replacing e.g. five 10k-line modules with one 10k-line module. But there's also an unfortunate tendency to favor consolidation into one 50k-line module. In that case they were separate for a good reason...
- scarface74 6y ago
  There is also a technical reason for microservices -- scaling and releasing independently. The company I work for is a B2B company. We use our APIs for our own (relatively low volume) website. But we also use it for batch jobs and we sell direct access to our APIs to our clients and they use our APIs for their own websites and applications. One large client gets signed, the usage of one API can spike by 30%
lotophage 6y ago
A couple of years ago it was roughly 3 service per engineer.

I think this could be an interesting metric to apply across the board. R = # of micro services / # of engineers If R >= 1, this is potentially problematic and may indicate engineers being unable to work with the code of their peers. Operating in this regime would be viewed as risky. R can go to infinity very quickly if you go down this path without very deliberate planning, involving the consensus of both the entire management and engineering staffs. If R < 1, you have more engineers than micro services. People share code bases and are not afraid of each other. This is probably a safe regime to operate in, even if you completely fuck up the intent of micro services. I think R could also serve as an arbitrary bus impact scalar for the org chart.

closeparen 6y ago
Depends. R > 1 can also mean that projects are getting wrapped up and left alone, and their teams moving onto new stuff. Three people per module-project, three project cycles in, will have R = 1. That is not necessarily a bad thing, although it can be a liability if they all suddenly need attention at once. R < 1 can mean that either the same functionality is getting reworked over and over, or people are breaking separation of concerns and concatenating unrelated stuff onto existing modules. Ideally you want to be spotting the common patterns and replacing e.g. five 10k-line modules with one 10k-line module. But there's also an unfortunate tendency to favor consolidation into one 50k-line module. In that case they were separate for a good reason...
scarface74 6y ago
There is also a technical reason for microservices -- scaling and releasing independently. The company I work for is a B2B company. We use our APIs for our own (relatively low volume) website. But we also use it for batch jobs and we sell direct access to our APIs to our clients and they use our APIs for their own websites and applications. One large client gets signed, the usage of one API can spike by 30%

lotophage 6y ago

A couple of years ago it was roughly 3 service per engineer.