If object oriented design is fundamentally about components sending messages to each other, then microservices are a different route to OO design. If people are bad at OO design, then they're likely bad at designing microservices, as well. The two aren't so separate.

All these programs now need to talk over the network instead of simply communicating in the same process.

This is where things go really wrong. Separating components over the network can be useful, but needs careful consideration. The end result can easily be noticeably slower than the original, and I'm surprised anybody thought otherwise.

[–] 1984@lemmy.today 17 points 6 months ago (5 children)

It's absolutely slower. There is no way to make a network request faster than a function call. It's slower by probably thousands of times.

[–] namingthingsiseasy@programming.dev 9 points 6 months ago (1 children)

There is no way to make a network request faster than a function call.

Apologies in advance if this it too pedantic, but this isn't necessarily true. If you're talking about an operation call that takes ~seconds to run, then the network overhead is negligible. And if you need specialized hardware for it, then it definitely could be delegate it out to a separate machine over the network. Examples could include requiring a GPU, more RAM, or even a faster CPU if your main application is running on more power-efficient CPUs.

I'm not saying that this is true in every case - they are definitely niche cases. But I definitely wouldn't say that network requests are never faster than local function calls.

[–] Corbin@programming.dev 3 points 6 months ago

Well put. And this is a generic pattern; for example, GPUs are only faster than CPUs if the cost of preparing the GPU and retrieving the result is faster than directly evaluating the algorithm on the CPU. This also applies to main memory! Anything outside of the CPU can incur a latency/throughput/scaling tradeoff.

[–] TrumpetX@programming.dev 8 points 6 months ago (2 children)

I have to look it up every time, but this is always worth reading once a year to remind yourself:

https://gist.github.com/hellerbarde/2843375

[–] frezik@midwest.social 1 points 6 months ago (1 children)

Since this is from 12 years ago, have any of these numbers changed much? Especially the SSD numbers.

[–] TrumpetX@programming.dev 1 points 6 months ago (1 children)

Not in any order of magnitude

[–] frezik@midwest.social 1 points 6 months ago

By that chart, 1MB read from an SSD is only 4 times slower than 1MB read from RAM. Wouldn't have to be an order of magnitude improvement to have an important affect there.

[–] 1984@lemmy.today 1 points 6 months ago

Yeah I've seen it before. It's a very good reminder for everyone to keep in mind isn't it. :)

[–] BellyPurpledGerbil@sh.itjust.works 8 points 6 months ago (1 children)

I don't disagree with there being tradeoffs in terms of speed, like function vs network requests. But eventually your whole monolith gets so fuckin damn big that everything else slows down.

The whole stack sits in a huge expensive VM, attached to maybe 3 or 4 large database instances, and dev changes take forever to merge in or back out.

Every time a dev wants to locally test their build, they type a command and have to wait for 15-30 minutes. Then troubleshoot any conflicts. Then run over 1000 unit tests. Then check that they didn't break coverage requirements. Then make a PR. Which triggers the whole damn process all over again except it has to redownload the docker images, reinstall dependencies, rerun 1000+ unit tests, run 1000+ integration tests, rebuild the frontend, which has to happen before running end to end UI tests, pray nothing breaks, merge to main, do it ALL OVER AGAIN FOR THE STAGING ENVIRONMENT, QA has to plan for and execute hundreds of manual tests, and we're not even at prod yet. The whole way begging for approvals from whoever gets impacted by anything from a one line code change to thousands.

When this process gets so large that any change takes hours to days, no matter how small the change is, then you're fucked. Because unfucking this once it gets too big becomes such a monstrous effort that it's equivalent to rebuilding the whole thing from scratch.

I've done this song and dance so many times. If you want your shit to be speedy on request, great, just expect literally everything else to drag down. When companies were still releasing software like once a quarter this made sense. It doesn't anymore.

[–] 1984@lemmy.today 2 points 6 months ago

I agree with you, and that is a hellish environment to work in.

There must be a better middle ground for all of this.

[–] addie@feddit.uk 6 points 6 months ago (1 children)

Think you're understating it there. Network call takes milliseconds at best. Function call, if the CPU has correctly predicted the indirect branch, is basically free, but even if it hasn't then you're talking nanoseconds. It's slower by millions of times.

[–] 1984@lemmy.today 1 points 6 months ago* (last edited 6 months ago)

Yeah it's insane. But of course if scaling different parts of the application, I guess micro services are the way to do it. But otherwise one could scale the entire app by just putting more of the entire app on servers. No need for micro services. It just needs to be written to be able to listen to message queues and you can have any number of app instances.

[–] frezik@midwest.social 2 points 6 months ago

In theory, it can be faster with parallelization. Of course, all the usual caveats about parallelization apply, and you're most likely going to create a slower system if you don't think it through.