The costs of microservices (2020) • Hacker News Board

Re: The costs of microservices (2020)

#51

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

insanitybit wrote: post #33

mjr00 wrote: post #22

Earlier quoted context omitted.

> I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. There's a few things in play IMO. One is lack of definition -- what's a "microservice" anyhow? Netflix popularized the idea of microservices literally being a few hundred lines of code maintained by a single developer, and some people believe that's what a microservice is. Others are more lax and see…

It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context". > It's definitely preferable to have a poorly-built monolith than poorly-built microservice architectures. I don't know about "definitely" at all. Having worked with some horrible monoliths, I really don't think I agree. Microservices…

> It doesn't lack a definition, there's lots of people talking about this. In general you'll find something like "a small service that solves one problem within a single bounded context".

How small is small? Even within this comment section there are people talking about a single developer being the sole maintainer of multiple microservices. I'm a strong advocate of (micro?)service architecture but I would never recommend doing the "all behavior is 100-line lambda functions" approach.

A horrible monolith vs horrible microservices is subjective, of course, but IMO having everything self-contained to one repository, one collection of app servers, etc. at least gives you some hope of salvation, often by building new functionality in separate services, ironically. Horrible microservices that violate data boundaries, i.e. multiple services sharing a database which is a sadly common mistake, is a much harder problem to solve. (both are bad, of course!)

Re: The costs of microservices (2020)

#52

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

Scarblac wrote: post #45

mjr00 wrote: post #34

Earlier quoted context omitted.

It's funny because the term "microservices" picked up in popularity because previously, most "service-oriented architecture" (the old term) implementations in large companies had services that were worked on by dozens or hundreds of developers, at least in my experience. So going from that to services that were worked on by a single development team of ~10 people was indeed a "microservice" relatively speaking. Now,…

I can understand wanting to split things off so that one team handles one service, roughly. There was a recent thread here where someone mentioned he personally was responsible for about four of their microservices...

Yeah, my last company had 10 microservices (the entirety of their codebase) managed by a single team when I started. Some of them had fewer than 5 API endpoints (and weren't doing anything complex to justify that).

Re: The costs of microservices (2020)

#53

Post by rqtwteye » Mon, Oct 30, 2023, 3:31 PM UTC

jeffbee wrote: post #9

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…

I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example…

"I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified"

I think the problem is the word "micro". At my company I see a lot of projects that are run by three devs that and have 13 microservices. They are easy to develop but the maintenance overhead is enormous. And they never get shared between projects so you have 5 services that do basically the same.

Re: The costs of microservices (2020)

#54

Post by insanitybit » Mon, Oct 30, 2023, 3:33 PM UTC

nevinera wrote: post #46

insanitybit wrote: post #26

Earlier quoted context omitted.

> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.

That's technical, and not architectural. I'm _all about_ technical solutions to lack of discipline, and in fact I think technical and process solutions are the only immediate way to create cultural solutions (which are the long-term ones). I'd even consider minor increases to architectural complexity for that purpose justifiable - it's a real problem, and trading to solve it is reasonable. But architectural complexit…

Can you explain the salient distinction between a "technical" versus "architectural" solution? Candidly, I'm not convinced that there is one.

> But architectural complexity has outsized long-term cost

As do technical solutions, of course. CI/CD systems are very expensive, just from a monetary perspective, but also impose significant burdens to developers in terms of blocking PRs, especially if there are flaky or expensive tests.

> And in this particular case, it doesn't actually solve the problem, since you _can't_ successfully enforce those domain boundaries unless you already have them well-defined.

Ignoring microservices, just focusing on underlying SoA for a moment, the boundary is the process. That is an enforceable boundary. I think what you're saying amounts to, in microservice parlance, that there is no way to prevent a single microservice from crossing multiple bounded contexts, that it ultimately relies on developers. This is true, but it's also just as true for good monolithic designs around modules - there is no technical constraint for a module to not expand into domains, becoming cluttered and overly complex.

Microservices do not make that problem harder, but SoA does give you a powerful technical tool for isolation.

Re: The costs of microservices (2020)

#55

Post by spott » Mon, Oct 30, 2023, 3:34 PM UTC

"Microservices" has always been weird to me.

People argue for them from two different, drastically different, points of view:

* Microservices become necessary at some point because they allow you to independently scale different parts of the application depending on load.

* Microservices become necessary at some point because they allow you to create hard team boundaries to enforce code boundaries.

Personal opinion: micro services are always thrown out there as a solution to the second problem because it is easier to split a service out of a monolith than it is to put the genie of bad code boundaries back in the box.

An application goes through a few stages of growth:

1) When it starts, good boundaries are really hard to define because no-one knows what the application looks like. So whatever boundaries are defined are constantly violated because they were bad abstraction layers in the first place.

2) After a while, when the institutional knowledge is available to figure out what the boundaries are, it would require significant rewrites/refactoring to enforce them.

3) Since a rewrite/major refactor is necessary either way, everyone pushes to go to micro services because they are a good resume builder for leadership, and "we might need the ability to scale", or people think it will be easier ("we can splinter off this service!", ignoring the fact that they can splinter it off within the monolith without having to deal with networks and REST overhead).

Unfortunately, this means that everyone has this idea that micro services are necessary for code boundaries because so many teams with good code boundaries are using micro services.

Re: The costs of microservices (2020)

#56

Post by nicoburns » Mon, Oct 30, 2023, 3:34 PM UTC

insanitybit wrote: post #38

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

Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated. Isolation is not anything to scoff at, it's one of the most powerful features you can encode into your software. Isolation can improve performance, it can create fault boundaries, it can provide security boundarie…

> Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated.

That is not too true at all. I've seen "microservice" setups where one microservice depends on the state within another microservice. And even cases where service A calls into service B which calls back into service A, relying on the state from the initial call being present.

Isolation is good, but microservices are neither necessary nor sufficient to enforce it.

Re: The costs of microservices (2020)

#57

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

jeffbee wrote: post #23

simonw wrote: post #18

Earlier quoted context omitted.

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.

Acculturating new developers is one of the main tasks of an organization. I don't think it's very difficult to communicate that some company uses language[s] X[, Y and Z] only.

That depends on the culture of each specific organization. Are there top-down engineering decisions? Is there a push for more team autonomy?

My experience is that many organizations have something of a pendulum swinging between those two positions, so the current state of that balance may change over time.

Also: many new developers, when they hear "microservices", will jump straight to "that means I can use any language I want, right?"

(Maybe that's less true in 2023)

Re: The costs of microservices (2020)

#58

Post by eterevsky » Mon, Oct 30, 2023, 3:35 PM UTC

lr4444lr wrote: post #27

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment…

1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?

Re: The costs of microservices (2020)

#59

Post by paulddraper » Mon, Oct 30, 2023, 3:35 PM UTC

lr4444lr wrote: post #27

Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment…

And those would apply to < 10% of your total code base.

Re: The costs of microservices (2020)

#60

Post by insanitybit » Mon, Oct 30, 2023, 3:35 PM UTC

vrosas wrote: post #40

insanitybit wrote: post #26

Earlier quoted context omitted.

> Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, And yet we do this all the time. Your CI/CD blocking your PRs until tests pass? That's a costly technical solution to solve an issue of organizational discipline.

The other problem is that these self-imposed roadblocks are so engrained in the modern SDLC that developers literally cannot imagine a world where they do not exist. I got _reamed_ by some "senior" engineers for merging a small PR without an approval recently. And we're not some megacorp, we're a 12 person engineering startup! We can make our own rules! We don't even have any customers...

Indeed, dogmatic adherence to arbitrary patterns is a huge problem in our field. People have strong beliefs, "X good" or "X bad", with almost no idea of what X even is, what the alternatives are, why X was something people did or did not like, etc.