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

31–40 of 447 posts

Re: In Defense of Simple Architectures (2022)

#31

Post by kaba0 »

nickserv wrote: post #27
rugger wrote: post #8

Monolith is fine if you have a fairly simple process for manipulating your data. Like posting an article, then a comment, with some moderation thrown in. But when you start adding business rules, and start transforming your data and moving it around, then your monolith will become too complex and often too expensive to run. Lots of moving parts tightly coupled together, long-running transaction wrapping multiple join…

Ironically, business rules are often much easier done in a monolith, since they tend to require access to basically the entire database, and have impact across your code base. Not saying it needs to be spaghetti all over the code mind you. Just that it's easier to have a module within the monolith rather than a dedicated service.

Especially that it must be fun hunting down race conditions across microservices. Like, microservices throw away every benefit of a single code base in a single language (and its guarantees). They sometimes make sense, but arguably that sometimes is quite rare.

Re: In Defense of Simple Architectures (2022)

#32

Post by infecto »

simonbarker87 wrote: post #20

Our stack is a NestJS server, Handlebars templates for SSR, htmx and a PostgresSQL database. Deployed as a container on GCP Cloud run with a Github action. It's delightful to work on and very responsive in a way that a React app with the same data load wouldn't be. At this point it would take a pretty massive reason to get me to adopt the SPA approach again.

FastAPI, Jinja, htmx and Postgres here. Simple to add features, not sure I would use a SPA or other similar JS heavy framework unless I had a feature requiring it.

Re: In Defense of Simple Architectures (2022)

#33

Post by infecto »

namaria wrote: post #26
simonbarker87 wrote: post #20

Our stack is a NestJS server, Handlebars templates for SSR, htmx and a PostgresSQL database. Deployed as a container on GCP Cloud run with a Github action. It's delightful to work on and very responsive in a way that a React app with the same data load wouldn't be. At this point it would take a pretty massive reason to get me to adopt the SPA approach again.

I usually also use Cloud Run for running my containers. But I use Cloud Build instead of GH Actions. I'm curious, what's your reasoning? I prefer my repository to just hold code and run build actions close to where it's deployed.

For me, I had use GH Actions before so it was pretty quick to get up and running. I am sure it was not that much more effort to use a cloud build tool in GCP or AWS but honestly don't see that much of a pro/con.

Re: In Defense of Simple Architectures (2022)

#34

Post by nunez »

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…

to be fair, when you don't have any pathways for working on $COOL_TECH at your job, designing and justifying something overly complex makes sense

Re: In Defense of Simple Architectures (2022)

#35

Post by Cthulhu_ »

rugger wrote: post #8

Monolith is fine if you have a fairly simple process for manipulating your data. Like posting an article, then a comment, with some moderation thrown in. But when you start adding business rules, and start transforming your data and moving it around, then your monolith will become too complex and often too expensive to run. Lots of moving parts tightly coupled together, long-running transaction wrapping multiple join…

This is a fallacy. Adding a network boundary does not make your application less complex. If you can't make a "monolith" make sense, thinking you can do it in a microservices architecture is hubris. If you think long-running transactions / multiple tables are difficult, try doing that in a distributed fashion.

Re: In Defense of Simple Architectures (2022)

#36

Post by wavemode »

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

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.

Re: In Defense of Simple Architectures (2022)

#38

Post by disgruntledphd2 »

dawnofdusk wrote: post #9
disgruntledphd2 wrote: post #6

Earlier quoted context omitted.

Both of which are justified in the post. Like, complexity where it makes sense is a good thing, especially if that complexity brings benefits. Complexity for the sake of complexity is foolish.

Enough of this strawman one-liner "complexity for the sake of complexity". Unnecessary complexity is introduced because someone once thought it was necessary. It may not be necessary anymore, or (even worse) it might have not even been necessary at the time and the person who introduced it was just wrong. But all complex architectures start because people think it will bring benefits.

Agreed, but I rarely see this work out, even in the short term. It certainly seems like complexity for its own sake, and someone once told me that our system was embarrassingly simple so that's why they introduced a load of complexity. Sigh.

Re: In Defense of Simple Architectures (2022)

#39

Post by 2d8a875f-39a2-4 »

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.

Re: In Defense of Simple Architectures (2022)

#40

Post by TeMPOraL »

zer00eyz wrote: post #29
CuriouslyC wrote: post #21

Earlier quoted context omitted.

That guy was just optimizing for future employability, albeit in a short sighted way. Being able to talk in an interview about how you have professional experience with various tech stacks is valuable. That being said, optimizing for that at the cost of current job performance and coworker alienation is just dumb, since job performance and networking leads are more important for landing good jobs. I'm guessing this g…

> 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.
Post reply on HN