3 ms·

The thinking is backwards, if you are only 10 people, there I no need to shape the system in a microservicr fashion. You just extract the pieces that need scali

The thinking is backwards, if you are only 10 people, there I no need to shape the system in a microservicr fashion. You just extract the pieces that need scaling. If you are 60 devs, you need to split the system so that everyone can work on it without walking on each other.

therealdrag0 7y ago
Also you can have so few devs when your value is in your network. Most other businesses' value is in their features. We have customers constantly begging for features, so we have to have more engineers to produce more value to our customers.
papito 7y ago
As someone said, microservices is a technical solution to a people problem. Devs don't want to talk to each other so they wall off behind their own API. Boom, no need to talk to each other. Ever. Or is there?
- barrkel 7y ago
  Requiring everyone to talk to everyone so everyone has global context isn't just "devs don't want to talk to each other"; it is actually an information dissemination and coordination problem which scales non-linearly (at least n^2), and needs some kind of modularity to be tractable to normal humans. Microservices are like modules but for SaaS rather than shrinkwrap, and are where you end up when you follow SLAs, encapsulation of resource consumption, etc. to their logical conclusion.
  - majormajor 7y ago
    "Microservices" don't guarantee that everyone doesn't have to talk to everyone. Good thoughtful design is necessary regardless of how you're building/organizing/deploying/operating the code.
  - vikiomega9 7y ago
    > scales non-linearly Indeed, https://en.wikipedia.org/wiki/The_Nature_of_the_Firm https://en.wikipedia.org/wiki/The_Nature_of_the_Firm
marcosdumay 7y ago
Microservices are not the only way to split a system. Far from it. They are the most onerous, least tractable way to get what you are going for.
hinkley 7y ago
I believe that the instinct to over-engineer is based in part on bad prior experiences with trying to separate concerns after it's 'too late'. Either your own personal experiences, or those of your mentors. Lacking any better skills to identify and avoid those problems when they begin, they try to stop it from happening in the first place. Fences get erected everywhere in case they might be needed, and they frequently turn out to be in not quite the right spot or shape. The code becomes coupled to the bad interface instead of to other code, and the fixes are just as bad. YAGNI in theory is about trying to develop those other skills, but gets twisted into an excuse for bad tech debt loads.

therealdrag0 7y ago

Also you can have so few devs when your value is in your network. Most other businesses' value is in their features. We have customers constantly begging for features, so we have to have more engineers to produce more value to our customers.

papito 7y ago

As someone said, microservices is a technical solution to a people problem. Devs don't want to talk to each other so they wall off behind their own API. Boom, no need to talk to each other. Ever. Or is there?

barrkel 7y ago
Requiring everyone to talk to everyone so everyone has global context isn't just "devs don't want to talk to each other"; it is actually an information dissemination and coordination problem which scales non-linearly (at least n^2), and needs some kind of modularity to be tractable to normal humans. Microservices are like modules but for SaaS rather than shrinkwrap, and are where you end up when you follow SLAs, encapsulation of resource consumption, etc. to their logical conclusion.
- majormajor 7y ago
  "Microservices" don't guarantee that everyone doesn't have to talk to everyone. Good thoughtful design is necessary regardless of how you're building/organizing/deploying/operating the code.
- vikiomega9 7y ago
  > scales non-linearly Indeed, https://en.wikipedia.org/wiki/The_Nature_of_the_Firm https://en.wikipedia.org/wiki/The_Nature_of_the_Firm

marcosdumay 7y ago

Microservices are not the only way to split a system. Far from it. They are the most onerous, least tractable way to get what you are going for.

hinkley 7y ago

I believe that the instinct to over-engineer is based in part on bad prior experiences with trying to separate concerns after it's 'too late'. Either your own personal experiences, or those of your mentors. Lacking any better skills to identify and avoid those problems when they begin, they try to stop it from happening in the first place. Fences get erected everywhere in case they might be needed, and they frequently turn out to be in not quite the right spot or shape. The code becomes coupled to the bad interface instead of to other code, and the fixes are just as bad. YAGNI in theory is about trying to develop those other skills, but gets twisted into an excuse for bad tech debt loads.