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

In defense of simple architectures

danluu.com

Post reply on HN
Print view View original

181–190 of 196 posts

Re: In defense of simple architectures

#181

Post by midrus »

brundolf wrote: post #117
Beltalowda wrote: post #62

Earlier quoted context omitted.

Another issue with "just a JSON file" as a database is that you need to be a bit careful to avoid race conditions and the like, e.g. if two web pages try to write the same database at the same time. It's not an issue for all applications, and not that hard to get right, but does require some effort. This is a huge reason I prefer SQLite for simple file storage needs.

A normal Express app (assuming it's one process per JSON file) shouldn't have that problem, because JavaScript is single-threaded

You are confusing parallelism with concurrency. It definitely can be a problem.

Re: In defense of simple architectures

#182

Post by midrus »

danielvaughn wrote: post #11
ilovecaching wrote: post #8

The vast, vast, vast majority of organizations don't need micro services, don't need half of the products they bought and now have to integrate into their stack, and are simply looking to shave their yak to meet the bullet list of "best practices" for year 202X. Service oriented architectures and micro services solve a particular problem for companies that are operating on a massive scale and can invest (read waste m…

I'd never worked with micro-services before this latest freelance project. I start working with this platform that is basically "note taking but with a bit of AI/ML". So okay, a bit of complexity with the ML stuff, but otherwise a standard CRUD app. The application itself is a total of 3 pages, encompassing maybe 20 endpoints at the most, with about 100 daily active users. For the backend, some genius decided to buil…

This is so common, sadly. I've seen this happen a lot. And those geniuses advocating for these insane infrastructure usually leave the company after they scratched their itch with kubernetes or whatever they were interested in playing with I'm s strong believer that your first few engineers are very very, very important and you need to hire very experienced people.

In the cases I've seen this, honestly I think the ones to blame where the stakeholders, for hiring very young people, for the cheapest rate they could and giving them full responsibility and the Senior Architecure Something Something title when those people don't have more than a couple years experience and are just building what they read in a blog two weeks ago.

Re: In defense of simple architectures

#183

Post by polio »

nunez wrote: post #145
rendall wrote: post #140

Earlier quoted context omitted.

How would you simplify this?

for starters i wouldnt use kubernetes. love the system, but boy is it complicated. i'd use a few cloud function or stick them in VMs behind a load balancer and call it good.

> As for Kubernetes, we use Kubernetes because knew that, if the business was successful (which it has been) and we kept expanding, we’d eventually expand to countries that require us operate our services in country. The exact regulations vary by country, but we’re already expanding into one major African market that requires we operate our “primary datacenter” in the country and there are others with regulations that, e.g., require us to be able to fail over to a datacenter in the country.

Re: In defense of simple architectures

#184

Post by Calamitous »

DerArzt wrote: post #36
danielvaughn wrote: post #11

Earlier quoted context omitted.

I'd never worked with micro-services before this latest freelance project. I start working with this platform that is basically "note taking but with a bit of AI/ML". So okay, a bit of complexity with the ML stuff, but otherwise a standard CRUD app. The application itself is a total of 3 pages, encompassing maybe 20 endpoints at the most, with about 100 daily active users. For the backend, some genius decided to buil…

> 3 pages .... 74 unique services Just, wat. Sounds like the architect was doing some resume driven development cause damn.

Heh, that beats the ratio at my current job: 7 pages and ~45 unique services.

Re: In defense of simple architectures

#185

Post by kragen »

rendall wrote: post #180
kragen wrote: post #173

Earlier quoted context omitted.

Because he says things that are true and less well known than they should be, and then gives a clearly written argument that shows you that they are true using logic and empirical evidence. So far that just describes any good science paper or math textbook; the difference is that he's writing about questions of great interest to HN, like in this case "how to build a web service", "how to do software version tracking"…

I don't disagree with you, but other people write on these topics more compellingly, and do not include off-putting Wolfram/Doctorow-style self regard. I chalk it up to his being astoundingly prolific. https://news.ycombinator.com/from?site=danluu.com

Perhaps other people don't find his writing uncompelling or read Wolfram-style self-regard into it.

Re: In defense of simple architectures

#186

Post by [deleted] »

scrubs wrote: post #27

Nah, I don't much like the tone of this article. Not at all. The engineering message should be: keep your architecture as simple as possible. And here are some ways (to follow) on how to find that minimal and complete size 2 outfit foundation in your size 10 hoarder-track-suite-eye-sore. Do we really need to be preached at with a warmed over redo of `X' cut it for me as a kid so I really don't know why all the kids t…

[deleted]

Re: In defense of simple architectures

#187

Post by deterministic »

aadvark69 wrote: post #17

Simple architectures work well, until they don't. A good example is ye olde ruby on rails monolith. Dead simple to set up and iterate quickly, but once you reach a certain organization and/or codebase size, velocity starts to degrade exponentially

Complex architectures work well, until they don’t. Fixing complex architectures is much harder than fixing simple architectures. So would you prefer a simple architecture or a complex one? The answer should be obvious.

Re: In defense of simple architectures

#188

Post by [deleted] »

kragen wrote: post #185
rendall wrote: post #180

Earlier quoted context omitted.

I don't disagree with you, but other people write on these topics more compellingly, and do not include off-putting Wolfram/Doctorow-style self regard. I chalk it up to his being astoundingly prolific. https://news.ycombinator.com/from?site=danluu.com

Perhaps other people don't find his writing uncompelling or read Wolfram-style self-regard into it.

[deleted]

Re: In defense of simple architectures

#189

Post by rendall »

kragen wrote: post #185
rendall wrote: post #180

Earlier quoted context omitted.

I don't disagree with you, but other people write on these topics more compellingly, and do not include off-putting Wolfram/Doctorow-style self regard. I chalk it up to his being astoundingly prolific. https://news.ycombinator.com/from?site=danluu.com

Perhaps other people don't find his writing uncompelling or read Wolfram-style self-regard into it.

Evidently.

These two things can be true at once: Intelligent good people with good taste and good will find an author's writing compelling, interesting and valuable. Simultaneously, other intelligent good people with good taste and good will do not. It happens. Neither are wrong.

Re: In defense of simple architectures

#190

Post by sam0x17 »

pavlov wrote: post #34

There are some web apps still in production that I wrote almost a decade ago in Node+Express in the simplest, dumbest style imaginable. The only dependencies are Express and some third-party API connectors. The database is an append-only file of JSON objects separated by newlines. When the app restarts, it reads the file and rebuilds its memory image. All data is in RAM. I figured these toys would be replaced pretty…

I did a very similar setup to this as a boy using a PHP file that re-wrote itself as a sort of key-based data store. This was fantastic on free shared web hosting sites since no free db options were available. This was circa 2005.
Post reply on HN