Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The costs of microservices (2020)

robertovitillo.com

Post reply on HN
Print view View original

181–190 of 410 posts

Re: The costs of microservices (2020)

#181

Post by foobiekr »

nevinera wrote: post #35
jeffbee wrote: post #9

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. 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…

You're certainly misunderstanding me. Microservices are definitely justifiable in plenty of cases, and _services_ even more often. But they _need to be technically justified_ - that's the point I'm making. The majority of SOA adoption in small-to-medium tech companies is driven by the wrong type of pain, by technical leaders that can see that if they had their domains already split out into services, their problems w…

Whenever someone on the projects, I’m attached to tries to create a new service, first I asked them what data it works with, and then I ask them what the alternative to making this a service would be. Usually, by the time we start answering the second question, they realize that, actually, adding the service is just more work.

To me, what’s amazing is that in almost no organization is there a requirement to justify technically the addition of a new service, despite the cost and administrative and cognitive overhead of doing so.

Re: The costs of microservices (2020)

#182

Post by mrinterweb »

A bit over a decade ago, I was sold on the concept of microservices. After implementing, maintaining, and integrating many microservices; I have realized how incredibly exhausting it is. Sure microservices have their place, but understanding the often higher costs associated with microservices should be considered when developing a new service. Focus on the costs that are less tangible: siloed knowledge, integration costs, devops costs, coordinating releases, cross-team communication, testing, contract versioning, shared tooling. I could go on, but that's just a sample of some of the less obvious costs.

I feel that the collective opinion of microservices has shifted towards being trepidatious of microservices as many have experienced the pains associated with microservcies.

Re: The costs of microservices (2020)

#183

Post by mattbillenstein »

I think most organizations should take a stab at scaling out with in-process services first - ie, instead of an rpc it's a function call, instead of a process, it's a module, etc.

In a well-factored app, stepping on one another's toes should be the exception, not the rule.

Unfortunately, I think modern web frameworks don't do a good job of enabling this. They often encourage "God object" patterns and having code/data very tightly coupled.

Re: The costs of microservices (2020)

#184

Post by mark_undoio »

bingemaker wrote: post #79
paulddraper wrote: post #64

Earlier quoted context omitted.

Those dependencies might cross language boundaries, or interfere with your other dependencies running in the same process.

On the contrary, when they fail silently, it is hard debug "dependent" services

In the Java world, we've developed record/replay across microservice boundaries, so it's effectively possible to step from a failure in one microservice and into the service that sent it bad data.

https://docs.undo.io/java/Microservices.html

[Edit: for which, by the way, any feedback is welcome - it's technically quite promising but real world experience is worth a lot!]

Re: The costs of microservices (2020)

#185

Post by tsss »

bob1029 wrote: post #157

> And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g…

No one says you can't have all of your microservices use the same language...

Re: The costs of microservices (2020)

#186

Post by hinkley »

wongarsu wrote: post #156
lr4444lr wrote: post #142

Earlier quoted context omitted.

I don't want to get too tied up in the terminology, but "microservices-first" does not seem to be the problem the post is describing: One way to mitigate the growing pains of a monolithic backend is to split it into a set of independently deployable services that communicate via APIs. The APIs decouple the services from each other by creating boundaries that are hard to violate, unlike the ones between components run…

Without getting tied up in the whole "every language except assembly, Python and possibly JavaScript already solved this problem by forcing people to adhere to module-level APIs" argument, I think the crux of the issue is that the article just defines microservice architecture as any architecture consisting of multiple services, and explicitly states "there doesn’t have to be anything micro about the services". Which…

I think we should start calling this Pendulum Blindness.

We just go from 'one' to 'too many' as equally unworkable solutions to all of our problems, and each side (and each person currently subscribed to that 'side') knows the other side is wrong. The assumption is that this means their side is right instead of reality, which is nobody is right.

The moderates are right, but their answers are wiggly and they're too busy getting stuff done to argue with the purists. But the optics are bad so here we go again on another swing of the swingset.

'Some Services' is probably right, but it varies with domain, company size, and company structure (Conway's Law). And honestly developer maturity, so while 7 may be right for me and my peers today, in a year it might be 6, or 9. There's no clever soundbite to parrot.

Re: The costs of microservices (2020)

#187

Post by nevinera »

insanitybit wrote: post #171
nevinera wrote: post #134

Earlier quoted context omitted.

With no customers, one of the purposes of code-review is removed, but it's the lesser one anyway. The primary goal of code-review should _not_ be to "catch mistakes" in a well-functioning engineering team - that's a thing that happens, but mostly your CI handles that. Code-review is about unifying approaches, cross-pollinating strategies and techniques, and helping each other to improve as engineers. Your attitude to…

You have no idea what my attitude towards code-review is.

Well, partly that was a mistaken impression because I thought that your comment was also from vrosas. But I think there's enough in there to assess your attitude toward code-review at least a _bit_:

> They have 12 people and no customers, they can almost certainly adopt a very aggressive developer cycle that optimizes almost exclusively for happy-path velocity. You'd never do that at 50+ engineers with customers but for 12 engineers who have no customers? It's fine, in fact it's ideal.

12 engineers churning out code with no code-review at all? That'll produce velocity, for sure. It'll also produce not just an unmaintainable mess, but an interesting experiment, in which you get to find out which of your engineers are socially capable enough to initiate technical communication independently and construct technical rapport _without_ that process helping them to do so. Hope none of them hold strong technical opinions that clash!

Re: The costs of microservices (2020)

#188

Post by andersrs » 

        Goldilocks went inside the Git Hut. First she inspected the git repo of the great, huge bear, and that was 2TB which was far too large and monolithic for her. And then she tasted the 281 repos of the middle bear, and they were far too small and numerous for her. And then she went to the 10 repos of the little, small wee bear, and checked out those repos. And they were neither too large nor too small and numerous, but just right; each had it's own reason to be and she liked it so well, that she sat down and cloned it all.

Re: The costs of microservices (2020)

#189

Post by hu3 »

wnolens wrote: post #123

If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optima…

> Probably just the interface - function calls become RPC.

Network calls introduce new failure modes and challenges which require more plumbing.

Can I retry this RPC call safely?

How about exponential backoff?

Is my API load-balancer doing its thing correctly? We'll need to monitor it.

How about tracing between microservices? Now we need OpenTelemetry or something like that.

How harder is it to debug with breakpoints in a microservice architecture?

How can I undo a database transaction between 2 microservices?

Suddenly your simple function call just became a lot more problematic.

Re: The costs of microservices (2020)

#190

Post by ahoka »

wg0 wrote: post #165
sethammons wrote: post #19

Earlier quoted context omitted.

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 enforce…

How the whole open source ecosystem is working fine and delivering software while depending upon each other for almost decades all the while not ever being in the same room and yet having no microservices? I mean take your pick, anything open source be it desktop or web has a huge and deep dependency tree all the way down to libc. Just wondering. EDIT: Typos and desktop.

Someone does the integration work for you, that’s why it works. Try running some distro that just grabs the latest upstream versions and see how often things break.
Post reply on HN