3 ms·

The issue with these articles, is, they assumed, bad architect divided wrong domains into "wrong microservices", then concluded, "microservice" is bad strategy.

The issue with these articles, is, they assumed, bad architect divided wrong domains into "wrong microservices", then concluded, "microservice" is bad strategy. Step 1: Understand the domain first. Step 2: Use microservice for each domain. If you failed at step 1, step 2 is wrong. Monothlich architecture just "skips" step 1, and use one big fat service for all.

and0 4y ago
I don't think it's that simple. As he states, domains change and requirements change. Or maybe you find value providing something adjacent to or on top of the domain you're working in. I can't imagine a situation where this doesn't happen to some extent, except in the absolute simplest of domains. I also strongly agree with the author in that network i/o and distributed transactions (sagas) are huge blockers for all but the most mature organizations. In my experience microservices that aren't in completely isolated domains slow development significantly and accrue much more tech debt, though admittedly these weren't the most mature organizations. You could argue that they simply did it wrong (and, oh BOY, they most certainly did!!), but to some extent these practices need to address that programmers aren't perfect.
drewcoo 4y ago
> bad architect divided wrong domains into "wrong microservices", then concluded, "microservice" is bad strategy The more advanced someone is in their career, the less likely they are to personally take responsibility for failure. https://thecontentauthority.com/blog/what-does-it-is-a-poor-workman-who-blames-his-tools-mean https://thecontentauthority.com/blog/what-does-it-is-a-poor-...
8note 4y ago
Use a microservices for each domain is step 3. Step 2 is to set up your organization so that single teams can own those domains. This is where the difficulty making good microservices lies - your code will match your org structure, and microservices makes future changes to that harder

and0 4y ago

I don't think it's that simple. As he states, domains change and requirements change. Or maybe you find value providing something adjacent to or on top of the domain you're working in. I can't imagine a situation where this doesn't happen to some extent, except in the absolute simplest of domains. I also strongly agree with the author in that network i/o and distributed transactions (sagas) are huge blockers for all but the most mature organizations. In my experience microservices that aren't in completely isolated domains slow development significantly and accrue much more tech debt, though admittedly these weren't the most mature organizations. You could argue that they simply did it wrong (and, oh BOY, they most certainly did!!), but to some extent these practices need to address that programmers aren't perfect.

drewcoo 4y ago

> bad architect divided wrong domains into "wrong microservices", then concluded, "microservice" is bad strategy The more advanced someone is in their career, the less likely they are to personally take responsibility for failure. https://thecontentauthority.com/blog/what-does-it-is-a-poor-workman-who-blames-his-tools-mean https://thecontentauthority.com/blog/what-does-it-is-a-poor-...

8note 4y ago

Use a microservices for each domain is step 3. Step 2 is to set up your organization so that single teams can own those domains. This is where the difficulty making good microservices lies - your code will match your org structure, and microservices makes future changes to that harder