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

271–280 of 410 posts

Re: The costs of microservices (2020)

#271

Post by wernercd »

cpill wrote: post #205
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…

> God forbid you find yourself with a need to rewrite one of these shitpiles. Actually, this is much easier with micro services as you have a clear interface you need to support and the code is not woven into the rest of the monolith like a French plat. The best code is the easiest to throw away and rewrite, because let's face it, the older the code is, the more hands it's been through, the worse it is, but more impo…

> The best code is the easiest to throw away and rewrite, because let's face it, the older the code is, the more hands it's been through, the worse it is, but more importantly the less motivated anyone is in maintaining it.

The more testing that's been done and the more stable it should be.

The argument for new can be flipped because new doesn't mean better and old doesn't mean hell.

Re: The costs of microservices (2020)

#272

Post by shoelessone »

Anytime these discussions come up I always wonder if there are any great examples in the form of a deep technical analysis of microservice architecture?

I've built things that I've called microservices, but generally have failed to do a complete job or always left with something that feels more like a monolith with a few bits broken out to match scaling patterns.

I know there are talks and papers by Netflix for example, but if anybody knows if any smaller scale, easier to grok talks or papers that go into common pitfalls and solve them for real (vs giving a handwavey solution that sounds good but isn't concrete) I'd love to check it out.

Re: The costs of microservices (2020)

#273

Post by haolez »

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…

This sounds reasonable and correct, but my personal experience includes more monolithic messes than microservices ones.

Re: The costs of microservices (2020)

#274

Post by nijave »

superfrank wrote: post #203
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…

I think this is a false dichotomy. Most places I've worked with microservices had 2 or 3 approved languages for this reason (and others) and exceptions could be made by leadership if a team could show they had no other options. Microservices doesn't need to mean it's the wild west and every team can act without considering the larger org. There can and should be rules to keep a certain level of consistency across tea…

I think it's fair to say microservices increase the need for governance, whether manual or automated systems. When you start having more than 1 thing, you create the "how do I keep things consistent and what level of consistency do I want" problem

Re: The costs of microservices (2020)

#275

Post by benreesman »

I’ve always thought the monolith vs. micro service debate to miss the point.

Taking an RPC call has costs. But sometimes you need to. Maybe the computation doesn’t fit on any of your SKUs, maybe it is best done by a combination of different SKUs, maybe you need to be able to retry if an instance goes down. There are countless reasons that justify taking the overhead of an RPC.

So, do you have any of those reasons? If yes, take the RPC overhead in both compute and version management and stuff.

If no, don’t.

Why is this so contentious?

Re: The costs of microservices (2020)

#276

Post by Atotalnoob »

jcmontx wrote: post #268
ValtteriL wrote: post #237

Earlier quoted context omitted.

Can't you share them via shared libraries in .NET?

YMMV but I think you can only do that if you have a monorepo with the shared library and all the microservices

You can, but it’s just kind of hinky, you end up relying on a specific path for the shared library

Re: The costs of microservices (2020)

#277

Post by duncan-donuts »

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…

I was in a meeting to talk about our logging strategy at an old company that was starting micro services and experiencing this problem. In the meeting I half heartedly suggested we write the main lib in C and write a couple wrapper libs for the various languages we were using. At the time it felt kinda insane but in hindsight it probably would have been better than the logging mess we created for ourselves.

Re: The costs of microservices (2020)

#278

Post by screamingninja »

shoelessone wrote: post #272

Anytime these discussions come up I always wonder if there are any great examples in the form of a deep technical analysis of microservice architecture? I've built things that I've called microservices, but generally have failed to do a complete job or always left with something that feels more like a monolith with a few bits broken out to match scaling patterns. I know there are talks and papers by Netflix for examp…

This is my gold reference: https://microservices.io/

Most issues I have seen around microservices circle around bad design decisions or poor implementations. Both are also major issues for monoliths, but since those issues do not surface early on, it is easier to start developing a monolith and take on the technical debt to be dealt with later on.

Microservices architecture takes time and effort, but pays huge dividends in the long run.

Re: The costs of microservices (2020)

#279

Post by nijave »

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…

Microservices don't magically fix shared schema headaches. Getting abstraction and APIs right is the solution regardless of whether it's in-memory or over the network.

Instead of microservices, you could add a static analysis build step that checks if code in packages is calling private or protected interfaces in different packages. That would also help enforce service boundaries without introducing the network as the boundary.

Re: The costs of microservices (2020)

#280

Post by fullspectrumdev »

camgunz wrote: post #252

People really underestimate the eventual consistency thing. It's 100% the case your app will behave weirdly while it's processing some sort of change event. The options for dealing with this are real awkward, because the options for implementing transactions on top of microservices are real awkward. Product will absolutely hate this, and there won't really be anything you can do about it. Also fun fact: this scales i…

The joins problem is fucking killing me in some personal projects that will need a total rewrite at this point
Post reply on HN