The costs of microservices (2020) • Hacker News Board

Re: The costs of microservices (2020)

#11

Post by jjtheblunt » Mon, Oct 30, 2023, 2:57 PM UTC

sethammons wrote: post #7

jihadjihad wrote: post #2

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices

grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…

> Team velocity is empowered via microservices and controlling their own data stores.

Bologna. Choosing clear abstractions is an enabler of focus, but that doesn’t necessarily imply those abstractions are a network call away.

Re: The costs of microservices (2020)

#12

Post by alt227 » Mon, Oct 30, 2023, 2:58 PM UTC

jeffbee wrote: post #5

The article sees to take for granted that your development org is completely broken and out of control. They can't decide what to work on during sprints, they furtively introduce third party libraries and unknown languages, they silently ship incompatible changes to prod, etc. I guess microservices are easier if your developers aren't bozos.

Unfortunately there are very often bozos in your team or complete teams of bozos working on the same project as you. Im sure Microservices are easier if you work in a development team of smart, competent, intelligent developers. However Im sure everything would be easier then!

Re: The costs of microservices (2020)

#13

Post by ThinkBeat » Mon, Oct 30, 2023, 2:59 PM UTC

Side issue: What software is used to make those diagrams?

Re: The costs of microservices (2020)

#14

Post by arzke » Mon, Oct 30, 2023, 3:00 PM UTC

nevinera wrote: post #3

The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going…

"The last responsible moment (LRM) is the strategy of delaying a decision until the moment when the cost of not making the decision is greater than the cost of making it."

Quoted from: https://www.oreilly.com/library/view/software-architects-han...

Re: The costs of microservices (2020)

#15

Post by simonw » Mon, Oct 30, 2023, 3:02 PM UTC

sethammons wrote: post #7

jihadjihad wrote: post #2

Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices

grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…

> Team realizes their table wont scale, but their data is provided via API. They plan and execute the migration next sprint.

... followed by howls of anguish from the rest of the business when it turns out they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a long-departed team member's desk.

(I'm not saying this is good, but it's not an unlikely scenario.)

Re: The costs of microservices (2020)

#16

Post by timwaagh » Mon, Oct 30, 2023, 3:02 PM UTC

I liked this well balanced approach. What I think is necessary is more capability to have hard modularisation within a monolith, so decoupling is not a reason to introduce microservices. Performance should be the main/only reason to do it. It's a shame few languages support this.

Re: The costs of microservices (2020)

#17

Post by FL410 » Mon, Oct 30, 2023, 3:02 PM UTC

ThinkBeat wrote: post #13

Side issue: What software is used to make those diagrams?

Looks like Excalidraw

Re: The costs of microservices (2020)

#18

Post by simonw » Mon, Oct 30, 2023, 3:04 PM UTC

jeffbee wrote: post #5

The article sees to take for granted that your development org is completely broken and out of control. They can't decide what to work on during sprints, they furtively introduce third party libraries and unknown languages, they silently ship incompatible changes to prod, etc. I guess microservices are easier if your developers aren't bozos.

Every developer is a bozo for their first few months in a new job, simply because it takes time to absorb all of the information needed to understand how the existing systems work.

Re: The costs of microservices (2020)

#19

Post by sethammons » Mon, Oct 30, 2023, 3:05 PM UTC

jjtheblunt wrote: post #11

sethammons wrote: post #7

Earlier quoted context omitted.

grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 5…

> Team velocity is empowered via microservices and controlling their own data stores. Bologna. Choosing clear abstractions is an enabler of focus, but that doesn’t necessarily imply those abstractions are a network call away.

our team of 300 - we _can't_ enforce the clear abstractions. New dev gets hired, team feels pressured to deliver despite leadership saying to prioritize quality, they are not aware of all the access controls, they push a PR, it gets merged.

We have an org wide push to get more linting and more checks in place. The damage is done and now we have a multi-quarter effort to re-organize all our code.

This _can_ be enforced via well designed modules. I've just not seen that succeed. Anywhere. Microservices are a pain for smaller teams and you have to have CI and observability and your pains shift and are different. But for stepping on eachother? I've found microservices to be a super power for velocity in these cases. Can microservices be a shitshow? Absolutely, esp. when they share data stores or have circular dependencies. They also allow teams to be uncoupled assuming they don't break their API.

Re: The costs of microservices (2020)

#20

Post by ranting-moth » Mon, Oct 30, 2023, 3:06 PM UTC

The article mentions Development Experience, but doesn't mention what I think is an overlooked huge cost.

Bad Development Experience results in unhappy and/or frustrated developer. Unhappy and/or frustrated developer is usually performing considerably worse than his happier self would.