undefined | Better HN

0 pointsLawTalkingGuy3y ago0 comments

All guidance assumes it's for a thinking person. You should look at what could be learned, not insist that there be one unambiguous message and that it be earth-shaking.

> I find that “microservices should only perform a single task” is a really dangerous way to phrase it because we have no idea what the article means by “task.”

First off, it's not dangerous. It's just loosely defined.

Second, it's not important to know their task size to still know that two different (to them!) things shouldn't be shoved together.

If the two tasks fit together so well that it's a mere 5% extra code to do them both, then maybe they are two sides of the same coin. But if "one simple thing" is painful to implement maybe it's really two separate things under one blanket.

> often they settle on “one microservice per bounded context” where “bounded context” means “separated however I want it separated at the time,”

Right, because sometimes 'bounded context' is what Legal tells you about data residency and sometimes it's about optimal latency.

> Don't get me started on how “strong coupling” is shorthand for “coupled in ways I don't like”

Strong coupling is generally easy to define, relative to loose coupling, in any given language/platform. The value of engineering around it depends on the value of doing the thing which requires it multiplied by how often you have to do it.

0 comments

3 comments · 1 top-level

KronisLV3y ago· 2 in thread

> First off, it's not dangerous. It's just loosely defined.

I'm not sure about this. Some people might take it at face value and end up with dozens if not hundreds of services for a domain that doesn't quite need them. Ergo, the project that they work on might have the development velocity plummet, because it has too much accidental complexity and ops overhead.

That's how you get humorous parody videos like these ("Microservices" by KRAZAM): https://www.youtube.com/watch?v=y8OnoxKotPQ

As anyone who has ever seen SOLID or DRY taken as gospel, many people out there would probably agree with the claim that some general advice can definitely be dangerous.

LawTalkingGuyOP3y ago

> Some people might take it at face value and end up with dozens if not hundreds of services

You're worried that someone junior enough to run with random advice is going to be able to rearchitect their entire codebase into hundreds of microservices and deploy it to production without testing its performance/stability/etc?

I think they should try. It's a great way to learn why, and why not.

> many people out there would probably agree with the claim that some general advice can definitely be dangerous.

It's just mouth noises which aren't dangerous. We need to be able to hear other people's opinions (advice is just an opinion after all) without immediately adopting it.

KronisLV3y ago

> You're worried that someone junior enough to run with random advice is going to be able to rearchitect their entire codebase into hundreds of microservices and deploy it to production without testing its performance/stability/etc?

No, I'm worried that someone senior will do that, because they want microservices on their CV. This has happened in the past and will continue happening in the industry with every new technology or approach - as I'm sure many have seen projects get burned due to being an early adopter of Kubernetes or Kafka, or even microservices in general.

As for how much testing should be done vs how much actually is done, you'd be surprised. While some orgs absolutely do things right, for a large part of them out there it's basically the Wild West - ship stuff and hope it works well enough. The entire e-health system of my country is a good example of this (though I cannot comment on the architecture itself): https://www-lsm-lv.translate.goog/raksts/zinas/zinu-analize/...

Some excerpts:

  In December, the availability of e-health was disrupted for seven days (with one exception - on weekdays), but it actually did not work for five more weekdays. For example, on December 7, none of the e-health services were available for more than four hours (4 h 13 min) during the working day. January looks a little better - there are disruptions on six working days, while in February e-health is disrupted for three days, but for four days it can be said that the system does not work.
  
  "If there are three, four interruptions for more than 10-15 minutes during an hour, then of course the user can be lucky to hit during the time when the system is working, but there are users who can only hit during the times when the system is not working, so I also marked red," explains Edgars Goba, deputy director of the National Health Service for information and communication technologies.
  
  One of the users of the system, family doctor Ingars Burlaks says: "I have been working with e-health from the very beginning, since it appeared. Unfortunately, those problems that were there from the beginning, those chronic problems, like the system hanging up or getting kicked out of the system when you get a screen with an exclamation mark, those problems persist."

I've brought it up before, because it's one of the locally more well known examples. Furthermore, you'd think that it'd be the kind of system that should work: it's supposed to help with national healthcare, with millions spent on developing it, for the population of a small country. And yet, that's not the case.

> I think they should try. It's a great way to learn why, and why not.

This is something I can get behind for internal pilot projects, side projects, or hackathons and such. This is not something that I can get behind for projects with potential contractual penalties.

> It's just mouth noises which aren't dangerous. We need to be able to hear other people's opinions (advice is just an opinion after all) without immediately adopting it.

As long as no adopting advice at face value and no cargo culting follows, sure.

1 more reply

j / k navigate · click thread line to collapse