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

201–210 of 410 posts

Re: The costs of microservices (2020)

#201

Post by crabbone »

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…

Found the author of CISCO / Java Spring documentation.

I honestly expected people used passive-aggressive corpo-slang only for work / ironically. But this reads intentionally obfuscated.

But, to answer to the substance: you for some reason assumed that whoever designed first solution was an idiot and whoever designed the second was, at least clairvoyant.

The problem you describe isn't a result of inevitable design decisions. You just described a situation where someone screwed up doing something and didn't screw up doing something else. And that led you to believe that whatever that something else is, it's easier to design.

The reality of the situation is, unfortunately, the reverse. Upgrading microservices is much harder than replacing components in monolithic systems because it's easier to discover all users of the feature. There are, in general, fewer components in monolithic systems, so less things will need to change. Deployment of a monolithic system will be much more likely to discover problems created by incorrectly implemented upgrade.

In my experience of dealing with both worlds, microservices tend to create a maze-like system where nobody can be sure if any change will not adversely affect some other part of the system due to the distributed and highly fragmented nature of such systems. So, your ideas about upgrades are uncorroborated by practice. If you want to be able to update with more ease, you should choose a smaller, more cohesive system.

Re: The costs of microservices (2020)

#202

Post by PedroBatista »

Similarly with frontend devs thinking a "modern web-app" can only be built with frontend frameworks/libs like React/Vue/Svelte, etc, lately I feel there's an idea floating around that "monolith" equals running that scary big black ball of tar as a single instance and therefore "it doesn't scale", which is insane.

Another observation is the overall amount of code is much bigger and most of these services are ~20% business/domain code and ~80% having to deal with sending and receiving messages from other process over the network. You can hide it all you want, but at the end of the day it's there and you'll have to deal with the network in one way of another.

Just like the frontend madness, this microservice cult will only end once the economy goes to crap and there's no money to support all these Babel Towers of Doom.

PS: microservices have a place, which is inside a select few of companies that get something out of it more than the cost they pay.

Re: The costs of microservices (2020)

#203

Post by superfrank »

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

Re: The costs of microservices (2020)

#204

Post by insanitybit »

nevinera wrote: post #187
insanitybit wrote: post #171

Earlier quoted context omitted.

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…

Who said "no code-review at all"? Not me, not vrosas as far as I saw.

Re: The costs of microservices (2020)

#205

Post by cpill »

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 importantly the less motivated anyone is in maintaining it.

Re: The costs of microservices (2020)

#206

Post by superfrank »

PedroBatista wrote: post #202

Similarly with frontend devs thinking a "modern web-app" can only be built with frontend frameworks/libs like React/Vue/Svelte, etc, lately I feel there's an idea floating around that "monolith" equals running that scary big black ball of tar as a single instance and therefore "it doesn't scale", which is insane. Another observation is the overall amount of code is much bigger and most of these services are ~20% busi…

I think the thing people normally miss about microservices is that the goal of microservices is usually to solve organization and people problems and not technological ones. There's some tech benefits like allowing services to scale independently, but the biggest benefit is clear ownership boundaries and preventing code from becoming overly coupled where it doesn't need to be.

If you're a team small team working on a single product you probably don't need microservices since you likely don't have the type of organizational problems that microservices solve. Microservices are likely premature optimization and you're paying the price to solve problems you don't yet have.

Re: The costs of microservices (2020)

#207

Post by crabbone »

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…

The reality of this situation is that the tool everyone is using to build microservices is Kubernetes. It imposes a huge tax on communication between services. So your aspiration as to improving performance fly out of the window.

On top of this, you need to consider that most of the software you are going to write will be based on existing components. Many of these have no desire to communicate over network, and your micro- or w/e size services will have to cave in to their demands. Simple example: want to use Docker? -- say hello to UNIX sockets. Other components may require communication through shared memory, filesystem, and so on.

Finally, isolation is not a feature of microservices, especially if the emphasis is on micro. You have to be able to control the size and where you want to draw the boundary. If you committed upfront to having your units be as small as possible -- well, you might have function-level isolation, but you won't have class- or module- or program-level isolation, to put it in more understandable terms. This is where your comparison between the actors model and microservices breaks: first doesn't prescribe the size.

Re: The costs of microservices (2020)

#208

Post by ndriscoll »

sethammons wrote: post #125
Pet_Ant wrote: post #106

Earlier quoted context omitted.

> we _can't_ enforce the clear abstractions Really, you can't? Then I struggle to see how'll get anything else right. I've done it by using separate build scripts. That way only the interfaces and domain objects are exposed in the libraries. Now you lock down at the repository level access to each sub-project to the team working on it. There you go: modularity, boundaries, all without network hops.

sure - if you do that from the start. Most don't. The codebase organically grows and then lines are blurred and then you have to come in and refactor. When this refactor affects several teams, it gets harder in combinatorial fashion. With an HTTP API boundary, you don't get to reach into my code - it is literally impossible.

But the work required to factor things out behind an HTTP boundary is a superset of the work required to factor things out into a module as GP describes. So if you were going to do microservices, you could do that same factoring and then just stop when you get to the part where you'd add in networking and deployment scripts.

Re: The costs of microservices (2020)

#209

Post by mardifoufs »

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.

Open source projects rarely involve live services, or providing SaaS. In those situations I think microservices are much more helpful

Re: The costs of microservices (2020)

#210

Post by crabbone »

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…

When discussing microservices, the proponents almost always forget the key aspect of this concept, the micro part. The part that makes this stand out (everyone already heard about services, there's no convincing necessary here, if you feel like you need a service, you just make one, and don't fret about it).

So, whenever someone advocates for this concept, they "forget" to factor in the fragmentation caused by requiring that services be very small. To make this more concrete: if you have a monolith + microservice, you don't have microservices, because the later implies everything is split into tiny services, no monoliths.

Most of the arguments in favor of microservices fall apart as soon as you realize that it has to be micro. And once you back out of the "micro" requirement, you realize that nothing new or nothing deep is being offered.

Post reply on HN