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

231–240 of 447 posts

Re: In Defense of Simple Architectures (2022)

#231

Post by bebop »

throwaway2037 wrote: post #113
xnorswap wrote: post #79

Earlier quoted context omitted.

One answer to your question is C# / .Net. Combines excellent concurrency primitives, very good performance, and a deep reservoir of packages and libraries. Of course it's almost never worth switching languages for an existing product, you just get left with a mess of half-old and half-new tooling and invariably get left having to support both languages.

Real question: From your specific comment, are there any advantages of C# vs Java here?

Not the parent, but C# and Java are very similar in their feature set. One thing that I find interesting about the respective communities is, Java tends to develop JSR's where a standard is worked on by multiple vendors and published essentially as an interface. Many vendors then provide an implementation of the interface.

In C# Microsoft often provides the most popular tooling for common problems. For instance, in web development, Microsoft publishes ASP.net and Entity Framework. In Java there is Jax-rs (JSR 339) and JPA (JSR 317).

So depending on your preference for a strong centralized environment provided by a single vendor, or a decentralized standards based solution with many vendors, you might lean towards Java or C#.

Re: In Defense of Simple Architectures (2022)

#232

Post by lxe »

> Our architecture is so simple I’m not even going to bother with an architectural diagram.

What's described is far from a simple architecture. Synchronous python? Kubernetes? I'm guessing there's a legacy monolith with a few microservices or load-balancers? Then... GraphQL... why? This is just a hodgepodge of stuff in dire need of actual refactor.

Re: In Defense of Simple Architectures (2022)

#233

Post by troupe »

popcorncowboy wrote: post #135

Not to take anything away from the angle (which is bang on), but the "we're X people valued at $YBILLIONS" is a weird way to open and detracts from the message. I suppose it's a proxy for.. seriousness? I dunno. Valuations are just bets on NPV given "what could go right" scenarios, so congrats on having a convincing story to tres commas your val. But opening a pitch on architecture with "we're a small team building a…

> "we're X people valued at $YBILLIONS" is a weird way to open and detracts from the message.

The most common argument against simpler architecture is, "but that won't scale and we are going to grow to be a valuable company." So the idea that they aren't a $10 million company does seem somewhat relevant.

Re: In Defense of Simple Architectures (2022)

#234

Post by naasking »

mjr00 wrote: post #212
camgunz wrote: post #204

Earlier quoted context omitted.

> Services, or even microservices, are more of a strategy to allow teams to scale than services or products to scale. I've never really understood why you couldn't just break up your monolith into modules. So like if there's a "payments" section, why isn't that API stabilized? I think all the potential pitfalls (coupling, no commitment to compatibility) are there for monoliths and microservices, the difference is in…

> You never have the problem of "how do we update the version of Node on 50 microservices?" And instead you have the problem of "how do we update the version of Node on our 10 million LOC codebase?" Which is, in my experience, an order of magnitude harder. Ease of upgrading the underlying platform versions of Node, Python, Java, etc is one of the biggest benefits of smaller, independent services.

Upgrading the platform also happens at least 10x less frequently, so that math doesn't necessarily work out in your favour though.

Re: In Defense of Simple Architectures (2022)

#236

Post by mjr00 »

naasking wrote: post #234
mjr00 wrote: post #212

Earlier quoted context omitted.

> You never have the problem of "how do we update the version of Node on 50 microservices?" And instead you have the problem of "how do we update the version of Node on our 10 million LOC codebase?" Which is, in my experience, an order of magnitude harder. Ease of upgrading the underlying platform versions of Node, Python, Java, etc is one of the biggest benefits of smaller, independent services.

Upgrading the platform also happens at least 10x less frequently, so that math doesn't necessarily work out in your favour though.

It's much easier to make smaller scope changes at higher frequency than it is to make large changes at lower frequency. This is the entire reason the software industry adopted CI/CD

Re: In Defense of Simple Architectures (2022)

#237

Post by a1o »

imiric wrote: post #224
a1o wrote: post #179

Earlier quoted context omitted.

I don't like this grugbrain approach because complexity is subjective, as you mentioned, and the grugbrain mentions simply saying "no" instead of telling a dev to articulate why something shouldn't be in the codebase properly. I mention this because I've been a lot of times in a place where instead of adopting "well maintened library that everyone is using since more than a decade" I had to write and maintain my own…

I mean, I think that grug also agrees that saying "ok" to complexity makes sense sometimes. :) I agree that this is a deep topic that requires a nuanced discussion, but my point is that I like the pragmatic approach mentioned in the article. You see threads here arguing that GraphQL and k8s are not simple, which is true, but I think it's wrong to hardheadedly avoid these technologies because of their "complexity", th…

Yes, I agree with you, nuance is key. I just have bad experiences of people throwing me sentences stolen from these types of articles as an argument of "why I should not do X" and then these people just never do anything throughout the development cycle just keep arguing as dead weight and failing to deliver cycle after cycle. Sorry, lots of trauma here.

Re: In Defense of Simple Architectures (2022)

#239

Post by quaunaut »

DonnyV wrote: post #121
quaunaut wrote: post #68

Earlier quoted context omitted.

Why? What inherent advantage do those languages have with financial logic?

Python will let you use float division on integers. Compiled type languages won't do that. This would be solved by using a double data type. But python doesn't have it.

You'd almost certainly just use a library dedicated to mitigating this problem though, of which there are many.
Post reply on HN