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

161–170 of 447 posts

Re: In Defense of Simple Architectures (2022)

#161

Post by imiric »

Good article! I like that it suggests a pragmatic approach, and introduces complexity only when it's necessary and makes sense to do so. Often engineers advocating for KISS end up (poorly) reimplementing the complex version, when just adopting the "complex" alternative would've avoided them all the development and maintenance headaches.

That said, "simple" and "complex" are subjective terms, and they're not easily defined. Even when everyone aligns on what they are, complexity can still creep in. So it takes constant vigilance to keep it at bay.

In the infinite wisdom of grug[1]:

> given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex

> grug no able see complexity demon, but grug sense presence in code base

[1]: https://grugbrain.dev/#grug-on-complexity

Re: In Defense of Simple Architectures (2022)

#162

Post by bluGill »

treflop wrote: post #116

The problem is that most people have never actually built something in all the architectures they are considering. They just read blog posts of what to do. As an analogy, I’ve manufactured a lot of stuff out of wood, concrete, plastic (3D printed) and increasingly more metal. When I need a jig, I know what each material will be like and what I will be getting out of it.

If I tell you that clay is better for your next project then you don't know enough. Am I right or wrong - should you invest a lot of money into clay equipment, and time into learning to use clay? You need to make a decision based on what others say about the advantages of clay - maybe clay isn't better, maybe it is better but not by enough to be worth learning. If this is just for fun maybe you say you want to learn clay so you spend months learning to do it, but if this is for a job your really wants some confidence that clay is worth learning before investing your time to learn it.

Re: In Defense of Simple Architectures (2022)

#163

Post by PeterisP »

zer00eyz wrote: post #14
gherkinnn wrote: post #4

I'm going to agree with Dan Luu by asking where I can find more of these sane companies. I want to spend an honest 6h a working day improving a product (Terraform and Webpack are not the product) and spend the rest of my time tending to my garden.

You aren't looking for a job. You're looking for a lifestyle business. They are great. You will get time in the garden, that's awesome. Vacation someplace with no phones? Out of the question. Weekend in a 3rd world country with character and food and sketchy internet. Not gonna happen. You want to optimize for free time in the garden by all means you can do it, but you loose out in other places, you pick up other wor…

Running a business, even a "lifestyle business" is so substantially different from a job - requiring all kinds of very different tasks, and risk-taking profile - that it doesn't seem reasonable to assume that someone who's looking for such a job is actually looking to run some business.

Re: In Defense of Simple Architectures (2022)

#164

Post by lelanthran »

2d8a875f-39a2-4 wrote: post #93
lelanthran wrote: post #62

Earlier quoted context omitted.

> shit is falling over due to synchronous IO even at laughably low volumes. Like? I ask because even synchronous IO let's you serve millions of requests per month on a cheap VPS. That's enough in the b2b space to keep a company of 1000 employees in business.

Until one of your IO destinations develops some latency. Or your workflow adds a few more sync IOs into each request. Or you suddenly run outta threads. Then even if you're only at millions per month you've probably got problems.

> Then even if you're only at millions per month you've probably got problems.

Not in my experience. You may be using metrics for B2C websites which make $1 for each 1 million hits.

B2B works a little differently: you're not putting everyone on the same box, for starters.

I did some contract maintenance for a business recently (had no tech staff of their own, had contracted out their C# based appdev to someone else decades ago and just need some small changes now), and a busy internal app serving about 8000 employees was running just fine off a 4GB RAM VPS.

Their spend is under $100/m to keep this up. No async anywhere. No performance problems either.

So, sure, what you say makes sense if your business plan is "make $1 of each 1 million visitors". If you business plan is "sell painkillers, not vitamins" you need maybe 10k paying users to pay yourself a f/time salary.

Re: In Defense of Simple Architectures (2022)

#165

Post by duped »

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…

> Microservices aren't a performance strategy

Who thinks that more i/o and more frequent cold starts are more performant?

Where I see micoservices as very useful is for elasticity and modularization. It's probably slower than a monolith at your scale but you don't want to fallover when loads start increasing and you need to scale horizontally. Microservices with autoscaling can make that very useful.

But of course, updating services can be a nightmare. It's a game of tradeoffs.

Re: In Defense of Simple Architectures (2022)

#166

Post by marcosdumay »

yowlingcat wrote: post #85
bluGill wrote: post #50

Earlier quoted context omitted.

Just be careful not to go too far in the opposite direction. There are new things coming all the time. You probably don't want to be writing new COBOL anymore even though it was once a good idea (you might have to maintain it, but you should already know what you replace it with and what your interoperability strategy is)

Isn't there a labor shortage for COBOL engineers to maintain the mainframe code that powers $3T of transaction volume in banking and healthcare enabling skilled COBOL contractors to name their price?

Only at the salaries those banks want to pay, that aren't high.

Re: In Defense of Simple Architectures (2022)

#167

Post by tw04 »

TeMPOraL wrote: post #40
zer00eyz wrote: post #29

Earlier quoted context omitted.

> I'm guessing this guy was a serial job hopper who had no expectation of being able to progress up the ladder at the company you were at. The magpie was practically furniture (Over a decade there). We speculated that he had buried a literal body for the CEO based on what he got away with. Shiny objects was an astute call on the part of IT guy (he was setting up another new MacBook for him)

On the other hand, at least someone was exploring new tech. In the exploration/exploitation problem, going 100% exploitation and only ever using the same boring old tech for everything is not the optimal choice either.

This is also part of the reason you find reliable reseller partners. They can burn cycles figuring out what new tech is useful and what is a waste of time so you can spend your cycles actually getting things done with cool new tech that works without wasting your company's time and money on things that have fatal flaws that aren't immediately obvious.

Re: In Defense of Simple Architectures (2022)

#168

Post by artimaeis »

DonnyV wrote: post #42
wavemode wrote: post #36

Earlier quoted context omitted.

In what way does "moving towards microservices" relate to solving "data-integrity bugs"? I would argue the opposite - the more distributed you make the system, the more subtle consistency bugs tend to creep in.

For a financial services company they should be using a compiled language. Something like C# or Java or Rust or Go with Postgres.

He's been talking about the problems/solutions around Wave for a while. Every time I can't help but think if they'd just started with C# or Java, maybe Go or Rust, they'd be in a better position.

Here's what I see them as providing:

- Simple async, no wasted CPU on I/O

- Strong typing defaults

- Reliable static analysis

Half of the "pros" he lists for using GraphQL are just provided out of the box using ASP.NET Core with NSwag to document the endpoints. If they want to keep the client-side composability, create some OData endpoints and you've got it.

> Self-documentation of exact return type

> Code generation of exact return type leads to safer clients

> Our various apps (user app, support app, Wave agent app, etc.) can mostly share one API, reducing complexity

> Composable query language allows clients to fetch exactly the data they need in a single packet roundtrip without needing to build a large number of special-purpose endpoints

Bias flag: I'm primarily a C#/.NET developer. I came up on python and ruby but have had more success in my region getting paid to work on .NET code.

Re: In Defense of Simple Architectures (2022)

#169

Post by bluGill »

emseetech wrote: post #133

Arguing for simple architectures is hard. Everyone wants to argue that yes, they ARE going to need it. Maybe not now but someday, therefore they should have it. Always reminds me of this scene from Arrested Development. https://www.youtube.com/watch?v=VVtOkX-gUxU&t=132s

I've been in the situation where someone argued we didn't need something so go simple - turns out they were wrong (isn't hindsight nice) but now the system was based around this incorrect assumption and really hard to rework into the thing we needed.

This is why architecture is hard. It is about making the decisions in advance that you will regret getting wrong.

Re: In Defense of Simple Architectures (2022)

#170

Post by lelanthran »

marginalia_nu wrote: post #147
lelanthran wrote: post #62

Earlier quoted context omitted.

> shit is falling over due to synchronous IO even at laughably low volumes. Like? I ask because even synchronous IO let's you serve millions of requests per month on a cheap VPS. That's enough in the b2b space to keep a company of 1000 employees in business.

To be fair, a million requests per month is 20 requests per minute...

> To be fair, a million requests per month is 20 requests per minute...

Which, in B2B, is insanely profitable. At 20 rqsts/min, for a paying customer paying you $200/m/user, those numbers are fantastic!

I can only dream of having those numbers!

Post reply on HN