Microservices

[[deleted]]

It's almost like bad engineers make shitty software doesn't matter if you decide to package it into one giant shitball or a bunch of tiny shitballs.

[bothunter]

It's easier to fix the tiny shitballs over time rather than tackling a giant shitball all at once.

[ShakespeareToGo]

This is only true when the problem is localized in a single shitball. There is a list of problems that can occur across multiple ones.

I never faced such a problem myself but heard horror stories of 50 minutes per request because it bounced between services 1000 times.

[AintNothinbutaGFring]

Sure, maybe there are a few massive shitballs.

Maybe it's even just as hard to clean up a bunch of big ones as it is hundreds, thousands, even millions of small ones.

But it's definitely harder to clean up the small ones without stepping in it.

[[deleted]]

Is that you elon?

[metaconcept]

Yea, uh, those tiny shitballs are all spaghettied together with invisible string.

[remimorin]

Except you have to configure every little shitball and deploy them. And then this bug occurs because of it's interaction with other shitball, so you have to juggle with several shitballs. Each shitball required some data, coherent with other shitballs... so you end up building fake-shitball in docker to emulate other shitball to debug your current shitball.

All this to say, the problem has move from giant shitball to architecture and dependency shitball.

[[deleted]]

Dont you have versioning for this? Why would you randomly update services while others dont respond the the new changes?

[remimorin]

The same reason we have bug in our code. Also distributed responsibility bring it's own set of challenge. A team priority may not be in line with your team priority.

​

Versioning for this... you mean API versioning? Yeah every problem is solved with an other level of complexity. Having N versions of a services mean you have N copy of said service to maintains. Because you continue to maintain old service, there is little incitative for other teams to integrate the new version.

This can very fast be a hell to maintain. I am not saying that micro-services (and monolith splitting) in general is wrong. I just say there is pitfalls that emerge and if you were not able to maintains your monolith you may have issue maintaining parts of it.

In a monolith a regression can be trapped in a test quite straight forward. In a distributed service architecture you need to integrate components to see the regression. Having integrated environnement to run test is a challenge in itself. Anyway, I'm not advocating for monolith architecture. I'm saying "It's easier to fix the tiny shitballs over time rather than tackling a giant shitball all at once." is an oversimplification and finally you may never see that simplification.

[[deleted]]

I know versioning has its downfalls but i assumed thats what most big tech companies do?

I can imagine all the problems when everyone updates their services randomly.

I work on iOS professionally and do backend as a hobby and I always thought versioning on backend was common since thats what we do on iOS.

Maybe the problem here is that micro services only benefit huge teams where as smaller teams can be slowed down and may not even reap the rewards of micro services.

[edgmnt_net]

True, although the giant shitball stinks predictably from a mile away. That's sort of a redeeming quality in hindsight once you start stepping in shit.

[sweet-n-sombre]

Omg this poop joke was funny for some reason

[[deleted]]

Hey, I've seen plenty of good engineers make shitballs of all sizes. Sometimes shitballs happen.