Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of Simple Architectures (2022)

danluu.com

Post reply on HN
Print view View original

301–310 of 447 posts

Re: In Defense of Simple Architectures (2022)

#301

Post by renegade-otter »

bluGill wrote: post #120
devjab wrote: post #112

Earlier quoted context omitted.

Monoliths aren’t very useful in many organisations where you need to build and connect 300+ systems. They also stop having simple architecture if you try. Most architecture conferences and talks tend to focus more on the enterprise side of things, and really, why would you need full time software focused architects if you’re building something like stackoverflow. I do think things have gotten a little silly in many p…

Building like NetFlix is better than random unguided architectures that result from not thinking. It might not be the best for your problem though. If you don't need thousands of servers, then the complexity that Netflix has to put into their architecture to support that may not be worth the cost. However if you do scale that far you will be glad you choose an architecture proven to scale that large. However I doubt…

It's a very bold assumption that a team that cannot manage a monolith will somehow lay a robust groundwork that will be the foundation of a future Netflix-like architecture.

By the way - Netflix started as a monolith, and so did most other big services that are still around.

The rest faded away, crushed by the weight of complexity, trying to be "like Netflix".

Re: In Defense of Simple Architectures (2022)

#302

Post by rqtwteye »

dullcrisp wrote: post #209
CuriouslyC wrote: post #23

Earlier quoted context omitted.

I wonder how many early stage businesses went tits up because they drank the microservice kool-aid and burned valuable engineering cycles that should have been spent on features on docker spaghetti.

Alternatively how many later stage business failed because all their features were in a Rails monolith that no number of engineers could maintain.

The Rails monolith companies probably have a better chance at adapting than the 50 microservices maintained by 10 devs companies.

Re: In Defense of Simple Architectures (2022)

#303

Post by renegade-otter »

2d8a875f-39a2-4 wrote: post #39

I agree with the general sentiment that simple architectures are better and monoliths are mostly fine. But. I've dealt with way too many teams whose shit is falling over due to synchronous IO even at laughably low volumes. Don't do that if you can avoid it. "Subtle data-integrity bugs" are not something we should be discussing in a system of financial record. Avoiding them should have been designed in from the start.

So they cannot get data integrity constraints done properly with a single database? Wait until they have to do seven. Also, sounds like not even proper indexes were in place, so database amateur hour.

Re: In Defense of Simple Architectures (2022)

#304

Post by TeMPOraL »

PH95VuimJjqBqy wrote: post #246
TeMPOraL wrote: post #97

Earlier quoted context omitted.

> Workman like functionality isnt sexy, it wont be the hot bullet point on your resume, it wont get you your next job, but it is dam effective. So, not fun, not rewarding, no intellectual challenge, no career benefit. Why exactly should I want to do it? This isn't the goddamn United Federation of Planets, nor is the company a church - why exactly should I go above and beyond what I agreed to in exchange for my salary…

if the pride of a good job done isn't enough motivation for you then you'll never understand because you simply don't have the ability to.

Unless you're working pro bono, the "pride of a good job done" isn't enough motivation for you either. Your employer may wish it was, though.

Point is, there is more to the equation. Employees don't exist in isolation, and when jobs actively refuse to take into account that the workers are real, living human beings, with needs and plans and dependents to feed, then resume-driven work will continue.

Re: In Defense of Simple Architectures (2022)

#305

Post by mhh__ »

zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

I'd argue it's something a little more fundamental than mere CV padding

Taking the CV aspect literally — this is a sleight of hand because it's a metaphor — I know lots of people who do this stuff that don't have a CV at all.

There's levels to it of course, but I don't really view it be any different to people who insist on using old machines as a bit (but in the other way obviously)

Re: In Defense of Simple Architectures (2022)

#306

Post by mhh__ »

from-nibly wrote: post #51

This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…

I view micro services as a risk mainly in a Conway sense rather than technology.

Most companies can run on a VPS.

Re: In Defense of Simple Architectures (2022)

#307

Post by codelobe »

isoprophlex wrote: post #242
rizzom5000 wrote: post #226

Earlier quoted context omitted.

> no intellectual challenge I tend to think that cargo cult programming and resume-driven development are the intellectual path of least resistance. Perhaps it's analogous to, "I'd rather rewrite this than understand how it works", because that requires less intellectual effort. Quality engineering is not achieved by the intellectually lazy, from what I've seen.

You're not wrong, but when you're inheriting a convoluted 50 file React shitfest that could have been a single HTML page and 20 lines of javascript... what are you going to do? Invest time in understanding that, or radically simplify in 20% of the time it takes to grok what you get thrown at you?

Ah, I see you are also a coder of culture...

The trick is to get the Project Management to migrate to a hot new framework: Vanilla JS...

http://vanilla-js.com/

Re: In Defense of Simple Architectures (2022)

#308

Post by TeMPOraL »

cmsefton wrote: post #145
zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

I'm immediately reminded of my favourite Kurt Vonnegut quote: "Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance." I've always felt that the magpie syndrome you describe is because of the desire to build new things, rather than maintain what's there. I watched a repair show recently where a craftsman repaired an old 70s bedside clock. The pride, time and patience…

Is it a flaw though? There's a lot of truth in that eCard: "a clean apartment is a sign of wasted life". How much of technological progress occured to ease the maintenance burden? Is it a flaw that the washing machine is saving people ridiculous amount of time (to the point of, arguably, allowing two-income households to exist in the first place)?

Re: In Defense of Simple Architectures (2022)

#309

Post by nonethewiser »

Wow, this guy's patreon is something else. https://www.patreon.com/danluu

$16/month "Short-form posts"

$256/month "Sponsor"

$2,048/month "Major Sponsor"

$16,384/month "Patron"

You certainly can't fault the guy for trying, although it does make him seem a bit crazy. And I'm aware of scenarios where raising prices doesn't have the negative effect you might expect. You never know what people might spend but I can't imagine this is a tempting proposition for anyone.

Maybe it's all a ploy to get you to spend $16/month to see how many "Sponsor", "Major", and "Patron" level subscribers there are.

Re: In Defense of Simple Architectures (2022)

#310

Post by fwip »

dakiol wrote: post #200
zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

Don’t we get paid the big bucks precisely because we have to fix stuff like this? I mean, if maintaining and fixing software were easy, I guess we wouldn’t be earning 6 figures. In software engineering We have all these principles and patterns and whatnot precisely because we have to deal with a pile of things that don’t work well together.

I think our outsized compensation is less because it's hard, and more because of our industry. In tech companies, labor is a relatively small expenditure, so tripling your labor budget to get 5% more "output" can be a very rational thing to do. (Also, the Mythical Man Month means that a smaller, sharper team is often more useful to solve your task than a bigger one.)
Post reply on HN