6 ms·

Are they going to regret having 4,000 micro services now?

by schnable 6y ago

PaulWaldman 6y ago
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.
MisterPea 6y ago
Well I think that's one of the benefits of microservices actually. Cut out all the services that have deep tribal knowledge from people let go and replace them with new services if the service is actually important or just remove it altogether.
- schnable 6y ago
  What I wonder is how often the "remove" operation happens. I'd wager it's more likely there are many services doing variations of the same thing, but existing ones are hard to kill because there is a web of dependencies.
  - jakemal 6y ago
    If they're hard to kill because there are a web of dependencies then I would argue they are doing microservices wrong.
    - freeone3000 6y ago
      Ah, the no true microservices idea of webservice architecture. If the idea is that you code to a webservice interface and then providers implement that interface, well, you're going to end up with the same problem, but with different interfaces. If the client specifies the interface using GraphQL or the like, that moves the problem from the incompatible interface to incompatible data naming. And so on. You need global coordination to untangle a mess of interrelated services, or you need continual migration work to adapt from one team's implementation to another.
    - momokoko 6y ago
      I think that’s kind of the rub with microservices, it is actually a successful architecture when the vast majority of teams are unable to do it correctly?
    - creato 6y ago
      No matter what you call it, if something can trivially be killed off, was it providing any real value in the first place? Dependencies aren't just things satisfied by linkers.
ab8 6y ago
It’s another opportunity to rewrite orphaned services
trollied 6y ago
They were already regretting them - they're moving away from them: https://twitter.com/GergelyOrosz/status/1247132806041546754 https://twitter.com/GergelyOrosz/status/1247132806041546754

Are they going to regret having 4,000 micro services now?

PaulWaldman 6y ago

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.

MisterPea 6y ago

Well I think that's one of the benefits of microservices actually. Cut out all the services that have deep tribal knowledge from people let go and replace them with new services if the service is actually important or just remove it altogether.

schnable 6y ago
What I wonder is how often the "remove" operation happens. I'd wager it's more likely there are many services doing variations of the same thing, but existing ones are hard to kill because there is a web of dependencies.
- jakemal 6y ago
  If they're hard to kill because there are a web of dependencies then I would argue they are doing microservices wrong.
  - freeone3000 6y ago
    Ah, the no true microservices idea of webservice architecture. If the idea is that you code to a webservice interface and then providers implement that interface, well, you're going to end up with the same problem, but with different interfaces. If the client specifies the interface using GraphQL or the like, that moves the problem from the incompatible interface to incompatible data naming. And so on. You need global coordination to untangle a mess of interrelated services, or you need continual migration work to adapt from one team's implementation to another.
  - momokoko 6y ago
    I think that’s kind of the rub with microservices, it is actually a successful architecture when the vast majority of teams are unable to do it correctly?
  - creato 6y ago
    No matter what you call it, if something can trivially be killed off, was it providing any real value in the first place? Dependencies aren't just things satisfied by linkers.

ab8 6y ago

It’s another opportunity to rewrite orphaned services

trollied 6y ago

They were already regretting them - they're moving away from them: https://twitter.com/GergelyOrosz/status/1247132806041546754 https://twitter.com/GergelyOrosz/status/1247132806041546754