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

251–260 of 447 posts

Re: In Defense of Simple Architectures (2022)

#251

Post by chasd00 »

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…

> And an engineering coordination strategy.

i've always felt the org chart defines the microservice architecture. It's a way to keep teams out of each other's hair. When you have the same dev working on more than one service then that's an indication you're headed for trouble.

Re: In Defense of Simple Architectures (2022)

#252

Post by valenterry »

palata wrote: post #99

I believe it is as easy to over-engineer as it is to under-engineer. Architecture is the art of doing "just enough"; it must be as simple as possible, but as complex as necessary. But that is hard to do, and it takes experience. And one thing that does not describe the IT industry well is "experience": don't most software developers have less than 5 years experience? You can read all the books you want and pass all t…

Well summarized.

Also, the area of experience matters. I myself for instance have become pretty good at designing systems and infrastructure both from scratch up to corporate level. However, that will not help me too much when it comes to mega-corp level (think: FAANG) and other things such as designing public opensource libraries. (libraries and systems/applications require very different tradeoffs).

Re: In Defense of Simple Architectures (2022)

#253

Post by ijidak »

It's the same reason that cooking recipes often become overly complex. (A sprig of this and a pinch of that.)

We are often embarrassed by the simple.

The simple makes us feel small, unsophisticated, and unimportant.

I always find it amusing when I find a way to solve a problem simply, and my coworkers answer somewhat directly that it seems very simple.

To me that's mark of success, but to many it's uncomfortable.

Of course if we didn't work on it then it's over complicated it needs to be rewritten. Go figure.

Re: In Defense of Simple Architectures (2022)

#254

Post by kulikalov »

I like the article and am a big proponent of simple architectures.

But.

The described use cases have homogenous workloads. Hence simple architecture. Extrapolate the rest.

And of course there are for sure cases of people increasing complexity for the sake of being needed. That's a topic for sociologists/psychologists to reason about, not for engineers.

Re: In Defense of Simple Architectures (2022)

#255

Post by ryandrake »

JAlexoid wrote: post #193
Swizec wrote: post #154

Earlier quoted context omitted.

> So, not fun, not rewarding, no intellectual challenge, no career benefit. Why exactly should I want to do it? It does help you get the next job. You’re just pitching it wrong. Instead of “Built boring tech” try “Delivered $5,000,000 return 2 months early”. Watch your inbox blow up. Business leaders don’t care about what you do, they care about results. What you do to get those results is just an unfortunate cost an…

Exactly. People forget that the final and most important decision for hiring will be at a less technical and much more bean-counting level. That's the reason why CS graduates with only bells and whistles in their CV have hard times getting a relevant position - glitter over your resume doesn't deliver value at all.

> That's the reason why CS graduates with only bells and whistles in their CV have hard times getting a relevant position - glitter over your resume doesn't deliver value at all.

If this is true, why does everyone still think that filling up their Technology Bingo card will get them their next job, rather than delivering business value?

Re: In Defense of Simple Architectures (2022)

#256

Post by abetusk »

TeMPOraL wrote: post #97
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…

> 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…

This is the kind of comment I come to HN for.

I think this is an absolutely right read on the situation. To put it in a slightly different context, the magpie developer is more akin to a "sociopath" from V. Rao's "Gervais Principle" [0], doing the least amount of work for the company while forging a path forward for their career. In this case, it just happens to not be within the same company.

[0] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

Re: In Defense of Simple Architectures (2022)

#257

Post by jakewins »

Shrezzing wrote: post #11

I'd argue that this article could be read more like "start as a monolith, and then move towards microservices when sensible", except the penny hasn't fully dropped for the author that the sensible time for their organisation is right now. The company appears dogmatically locked into their idling python code, their SQL making unpredictable commits, and their SQL framework making it difficult to make schema migrations.…

The author is ex Microsoft, Google and was a senior staff eng at Twitter; i don’t know them but my experience with their blogging over the last decade is that they seem generally very well informed. To me it seems unlikely “the penny hasn’t dropped”, like you say.

On the actual criticism you’re raising: In what concrete way would moving to micro services help with reducing data integrity bugs? In my experience I’d expect the exact opposite - micro services systems generally being harder to test and generally having more possible interleavings and partial failure paths.

Re: In Defense of Simple Architectures (2022)

#258

Post by notpachet »

quaunaut wrote: post #240
notpachet wrote: post #118

Earlier quoted context omitted.

Better static analysis, for one.

And that helps in financial analysis how?

I didn't say anything about financial analysis. But static typing is a good defense mechanism against type errors at runtime (I don't think anyone would argue against that). When you're running a financial services product, the cost of a type error in production can be dramatically higher than in non-financial code. Speaking from firsthand experience.

Re: In Defense of Simple Architectures (2022)

#259

Post by IshKebab »

palata wrote: post #99

I believe it is as easy to over-engineer as it is to under-engineer. Architecture is the art of doing "just enough"; it must be as simple as possible, but as complex as necessary. But that is hard to do, and it takes experience. And one thing that does not describe the IT industry well is "experience": don't most software developers have less than 5 years experience? You can read all the books you want and pass all t…

In my experience over-engineering is far less of a problem than badly engineering. I see way more total messes than "enterprise" engineering.

Re: In Defense of Simple Architectures (2022)

#260

Post by IshKebab »

quaunaut wrote: post #240
notpachet wrote: post #118

Earlier quoted context omitted.

Better static analysis, for one.

And that helps in financial analysis how?

I don't think it's specific to financial services. He just meant that financial services is an area where you really don't want bugs! And one of the easiest ways to eliminate entire classes of bugs is to use static typing.
Post reply on HN