Monoliths are not dinosaurs • Hacker News Board

Re: Monoliths are not dinosaurs

#241

Post by grumpyprole » Thu, May 11, 2023, 5:01 PM UTC

ndriscoll wrote: post #238

grumpyprole wrote: post #237

Earlier quoted context omitted.

Let's imagine Facebook, we can partition the monolith by user, but you would need the entire code base (50+ million lines?) running in each process just in case a user wants to access that functionality. I'm not saying one can't build a billion dollar business using a monolith, but at some point the limit of what a single process can host might become a problem.

Things like Facebook and Google are at a level of scale where they need to do things entirely differently form everyone else though. e.g. for most companies, you'll get better database performance with monotonic keys so that work is usually hitting the same pages. Once you reach a certain size (which very few companies/products do), you want the opposite so that none of your nodes get too hot/become a bottleneck. Unl…

I agree that most will be fine with a monolith, I never said anything to the contrary. But let's not pretend that the limits don't exist and don't matter. They matter to my company (and we're not Facebook or Google, but we're far older and probably have more code).

Re: Monoliths are not dinosaurs

#242

Post by justinclift » Thu, May 11, 2023, 9:46 PM UTC

byyyy wrote: post #240

justinclift wrote: post #239

Earlier quoted context omitted.

> There are less possible atomic configurations for cars then their is for debris. That doesn't really line up logically. :/

You're mistaken and you're intuition is off. It lines up absolutely. Debris is almost any configuration of atoms that are considered trash or unusable. There's are much more ways you can configure atoms to form useless trash then you can to make cars. Case in point "you" can manufacture "debris" or "trash" by throwing something into a trash can. Simple. When's the last time you manufactured a car? Never.

Wow. You're talking atomic scale stuff, but ignoring obvious things like oxidation occurring during an explosion. :/

Seems like a case of you including and excluding things to support your "logic". Ugh.

Re: Monoliths are not dinosaurs

#243

Post by tracker1 » Mon, May 15, 2023, 7:29 PM UTC

kqr wrote: post #216

tracker1 wrote: post #198

Earlier quoted context omitted.

I'd add that abstracting complexity should be done where it makes the rest of the system easier to understand over the abstraction. Too much abstraction can make systems harder to understand and work with instead of easier.

Assuming you are not perfect, you must have implemented too much abstracted systems at some point. What went through your head when you did that? What thoughts legitimized that extra layer of abstraction that turned out to be superfluous?

I think the best example I can think of is implementing the Microsoft Enterprise Library Data Access Application Blocks. EntLib came out of MS consulting as a means of normalizing larger scale application development with .Net. DAB in particular entailed creating abstractions and interfaces for data objects and data access components. In practice in smaller projects, this made things far more difficult, as in general the applications only targeted a single database and weren't really doing automated unit testing at the time.

It was kind of horrible, as VS would constantly take you to the IFoo interface definition instead of the DbFoo implementation when you were trying to debug. Not fun at all. It was much earlier in my career.

Probably the most complex system I designed was an inherited permission interface down to a component level through a byzantine mess of users/groups and ownership for a CRM tool in a specific industry. If I had to do it today, it would be very, very different and much simpler. Also much earlier in my career (about 20 years ago).

These days I've really enjoyed using scripting languages, mostly JS/Node and keeping things simple (I don't care for inversify for example). In general the simpler thing is usually easier to maintain and keep up with over time. Yeah, frameworks and patterns can make boilerplate easier but it's often at the expense of making everything else much harder. Vs just starting off slightly harder from the start, but everything is simpler overall over time.

Aside, been enjoying Rust as well.