3 ms·

I have a theory that microservices evolved because developers don't know how to write libraries that they publish to or install from private package repositorie

I have a theory that microservices evolved because developers don't know how to write libraries that they publish to or install from private package repositories.

varispeed 6y ago
There are also pushy managers who would insist on slapping another function onto an existing microservice and then cut time spent on writing tests, just so that he can meet his targets and get a bonus. Then the app with time will start to perform worse and worse but when it happens, the manager will be long into a new gig and the developers will get the whipping. Then they'll get new developers to fix the mess and once it gets stable, a new manager will start to insist on adding that function to an existing microservice... and the cycle repeats...
thrower123 6y ago
I always thought microservices were an organizational solution to the problem of bloated headcount on teams meeting the hard reality that if you put more than two cooks in the kitchen, diminishing and counterproductive results are the norm.
- linkdd 6y ago
  Team oriented architecture? I worked in some companies where each team were managing multiple micro services. Micro services answer a very specific problematic: they are small to allow the least technical debt per "business features". The less technical debt there is, the more robust your system is against changing specs.
  - candiddevmike 6y ago
    What is your definition of technical debt here? Just because something has a small LOC, doesn't mean it lacks tech debt. It's just harder to find and quantify. In fact, I would posit they're littered with tech debt, especially from an infrastructure and shared services standpoint.
    - linkdd 6y ago
      Services should be independent of each others (as much as possible). IMHO, technical debt is found in coupling (modules, services, ...), the number of dependencies (not only code dependencies, since making an HTTP request also introduces a soft dependency), and the amount of knowledge required to understand the code. If your service is unaware of its infrastructure (understand: i don't care if i run in docker/k8s/baremetal/...), the infrastructure's technical debt does not leak to the code.

I have a theory that microservices evolved because developers don't know how to write libraries that they publish to or install from private package repositories.

varispeed 6y ago

There are also pushy managers who would insist on slapping another function onto an existing microservice and then cut time spent on writing tests, just so that he can meet his targets and get a bonus. Then the app with time will start to perform worse and worse but when it happens, the manager will be long into a new gig and the developers will get the whipping. Then they'll get new developers to fix the mess and once it gets stable, a new manager will start to insist on adding that function to an existing microservice... and the cycle repeats...

thrower123 6y ago

I always thought microservices were an organizational solution to the problem of bloated headcount on teams meeting the hard reality that if you put more than two cooks in the kitchen, diminishing and counterproductive results are the norm.

linkdd 6y ago
Team oriented architecture? I worked in some companies where each team were managing multiple micro services. Micro services answer a very specific problematic: they are small to allow the least technical debt per "business features". The less technical debt there is, the more robust your system is against changing specs.
- candiddevmike 6y ago
  What is your definition of technical debt here? Just because something has a small LOC, doesn't mean it lacks tech debt. It's just harder to find and quantify. In fact, I would posit they're littered with tech debt, especially from an infrastructure and shared services standpoint.
  - linkdd 6y ago
    Services should be independent of each others (as much as possible). IMHO, technical debt is found in coupling (modules, services, ...), the number of dependencies (not only code dependencies, since making an HTTP request also introduces a soft dependency), and the amount of knowledge required to understand the code. If your service is unaware of its infrastructure (understand: i don't care if i run in docker/k8s/baremetal/...), the infrastructure's technical debt does not leak to the code.