3 ms·

I’m fascinated that the service architecture ecosystem seems so fixated with polarity. The right answer is pretty much always medium sized services and medium

I’m fascinated that the service architecture ecosystem seems so fixated with polarity. The right answer is pretty much always medium sized services and medium sized repos. I guess that isn’t edgy enough to make people feel like they are doing something cool

spoiler 4y ago
IMO the best way to split things is either by scalability, or user needs, or sometimes by domain (but this is too nuanced to fit into a comment). I suppose there might be security or certification/regulatory requirements too, but also those are probably rare.
nfw2 4y ago
Engineering types often prefer to think in hard rules…either an approach is absolutely better or absolutely worse. Saying medium-size services are best means that the engineer needs to use their judgment to determine where that threshold is. It becomes more of an art than a science, which many engineers are deeply-uncomfortable with, so they stick to their dogmas.
- Haga 4y ago
- john_the_writer 4y ago
  The issue with this, lies in different judgements. If I'm looking for a bit of code that I plan to extend, I have to understand the judgement of the coder who quit 2 years ago. If the decision to use metric or imperial bolts on a bridge were up to the individual builder... Picking a solid "do x" or "do y" makes for much simpler pull requests. I currently work on a project with some GraphQL, some basic json and some json-api. Some of the app is BFF and other bits are not client to the micro. Using our judgement is working out a treat.
chrisandchris 4y ago
Let's verify that: Kubernetes is not all useful. One can do very good without Kubernetes. Let'em come and tell me I need Kubernetes everywhere! To many people think it's black/white and that there is no grey in between. And more often I realize that the grey is even larger than any of the (hard) sides.

spoiler 4y ago

IMO the best way to split things is either by scalability, or user needs, or sometimes by domain (but this is too nuanced to fit into a comment). I suppose there might be security or certification/regulatory requirements too, but also those are probably rare.

nfw2 4y ago

Engineering types often prefer to think in hard rules…either an approach is absolutely better or absolutely worse. Saying medium-size services are best means that the engineer needs to use their judgment to determine where that threshold is. It becomes more of an art than a science, which many engineers are deeply-uncomfortable with, so they stick to their dogmas.

Haga 4y ago
john_the_writer 4y ago
The issue with this, lies in different judgements. If I'm looking for a bit of code that I plan to extend, I have to understand the judgement of the coder who quit 2 years ago. If the decision to use metric or imperial bolts on a bridge were up to the individual builder... Picking a solid "do x" or "do y" makes for much simpler pull requests. I currently work on a project with some GraphQL, some basic json and some json-api. Some of the app is BFF and other bits are not client to the micro. Using our judgement is working out a treat.

chrisandchris 4y ago

Let's verify that: Kubernetes is not all useful. One can do very good without Kubernetes. Let'em come and tell me I need Kubernetes everywhere! To many people think it's black/white and that there is no grey in between. And more often I realize that the grey is even larger than any of the (hard) sides.