this post was submitted on 12 May 2024
610 points (92.1% liked)

Programmer Humor

19594 readers
665 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] 1984@lemmy.today 63 points 6 months ago* (last edited 6 months ago) (21 children)

Problem is that companies are using them for all scenarios. It's often their entire tech stack now, with kubernetes.

It's similar to the object oriented hype that came before it, where developers had to write all their programs in a way so they could be extended and prepared for any future changes.

Everything became complex and difficult to work with. And almost none of those programs were ever extended in any significant way where object oriented design made it easier. On the contrary, it made it far more difficult to understand the program since you had to know which method was called in which object due to polymorphism when you looked at the code. You had to jump around like crazy to see what code was actually running.

Now with kubernetes, it's all about making the programs easier to scale and easier to develop for the developers, but it shifts the complexity to the infrastructure needed to support the networking requirements.

All these programs now need to talk over the network instead of simply communicating in the same process. And with that you have to think about failure scenarios, out of order communication, missing messages, separate databases and data storage for different services etc.

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

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 (12 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.

[–] 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. :)

load more comments (9 replies)
load more comments (9 replies)
load more comments (16 replies)