this post was submitted on 23 Jul 2024
210 points (95.7% liked)
Asklemmy
43958 readers
1307 users here now
A loosely moderated place to ask open-ended questions
Search asklemmy ๐
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- !lemmy411@lemmy.ca: a community for finding communities
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Maybe a niche issue, but "that doesn't scale!" In the context of software development.
We're writing software for usually very well defined user groups, but so many of the architects and seniors want to build a second Netflix, which costs 4 times as much as the simple solution and in the end usually isn't even better, because those morons have no idea how to do that.
Currently, I'm in a project where I fought tooth and nail to avoid having a micro service architecture for a batch job that inserts less than a million entries per day.
premature optimization is a root of all evil.
also when those morons decide to do 'microservices' but end up creating glorified SOA with one messy DB where half the tables are not even used by anything, updates in place are the standard and there is nothing like one team per service, but instead everyone is expected to navigate millions of lines of spaghetti code with poor documentation, barely any reuse and inconsistencies all across the board with this oh too-fucking-common entity service anti-pattern.
and so much fucking coupling that you better start deploying your dev cluster just right after waking up so it maybe is up and running by the time your daily is over.
Fun fact, I used to work at a company where a lot of projects use Elixir and a bulk share of my coworkers have been outspoken critics of microservices precisely because OTP manages to power fault tolerant and scalable systems but not by insane levels of complexity like kubernetes does but by CoC that rarely gets in your way.
Wow, Elixir and OTP. I envy you.
Good old Resume-Driven-Development
I wouldn't even call it that. It's a weird lack of a sense of scale combined with organizational hurdles.
They basically can't estimate, how much resources a proper app would need and they don't know how to manage teams to work on a common codebase. So they simply draw a diagram of the functionalities, spin out each block as a "Service", assign that to a team and call it a day.
I've talked to several of them about this and I had to do very simple math directly in front of them to convince them. I've had to explain to a grown man, an experienced engineer, that 16 cores and 96gb memory are more than enough to handle a million simple inserts per day in a batch mode. He wanted to split the job into 4 services, each essentially running 10 lines of actual business logic, each using the resources mentioned above. Absolute madness.