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

391–400 of 447 posts

Re: In Defense of Simple Architectures (2022)

#391

Post by Swizec »

loup-vaillant wrote: post #379
HeyLaughingBoy wrote: post #375

Earlier quoted context omitted.

>start questioning their decisions I'm not privy to any discussions you've had, of course, but I will comment on this because I see it in many tech people: don't question people's decisions. No matter how you phrase it, it will appear critical. And people (neurotypical or otherwise!) don't like criticism, no matter how much they claim to welcome it. Those "explicit" requests for feedback? They want positive feedback.…

The reason I speak of "neurotypical bullshit" is because people around me have several times suspected I'm on the spectrum, and I noticed I have a hard time dealing with subtle social cues. One manifestation of this is when someone asks me something with a straight face, I tend to assume they actually want what they asked for. When someone asks them feedback so they can improve, I tend to concentrate on what could ha…

Here's the thing: You're right. And also you're not.

Sometimes, often, feedback is about timing. The time to talk about how better to architect a thing is when it's being architected, not 2 months later. Instead of "This is crap" try "Hey I know this works for now, but there's room for improvement here. Next time we're talking about a system like this can I help with design? I have a few ideas what we might improve".

Volunteering to do the work of implementing your improvements goes a long way to making people more receptive to feedback. Otherwise you're just giving people homework and they almost certainly already have enough of that.

edit to add: Yes, creating change is work and it is exhausting. That's why organizations value people who can pull it off.

Re: In Defense of Simple Architectures (2022)

#392

Post by jameshart »

There's a weird belief that monoliths are a 'simple' architecture and micro services are 'complicated'.

Microservices are simple. Request handlers or queue listeners, transformation and data layers, caching, database connection pools, clients to other systems. They're easy.

Monoliths are where you come across some of the most godawful complicated architectures. Unified object-relational mapping layers. Shared cache systems with per-value QoS support. Hacked runtime hooks that tweak the garbage collection or memory management for particular use cases. Homegrown monitoring stacks and instrumentation systems. External configuration management tools. Custom build tool integrations with Jira.

And the upgrade slogs... when the database engine needs to be updated, or a new version of the underlying web technology is released.

Simple to build and simple to add to are not the same thing as 'simple'.

Re: In Defense of Simple Architectures (2022)

#393

Post by Uptrenda »

I grant him his point about simple architectures but now I'm interested in more technical details about Wave's architecture? He mentioned synchronous Python... everything about that sentence goes against what I've learned about network programming. Python is single-threaded, and blocking I/O means that any APIs built with it couldn't handle other customers waiting. Unless they're processed so fast that there's no appearance of delays?

Something that seems apparent with handling money in accounting systems (and trading systems) is you can't really do concurrency any way. If someone changes their account you need to lock those database records from access to any other thread and make everything atomic. Otherwise it can lead to race conditions where the same funds can be spent multiple times (this is something that has effected Bitcoin exchanges before quite ironically.) So maybe they use a sequential design because it makes more sense from an accounting perspective and eliminates the potential for race conditions? But then I'm still very curious about how performant such an approach is?

Re: In Defense of Simple Architectures (2022)

#394

Post by yen223 »

loup-vaillant wrote: post #376
aprdm wrote: post #364

Earlier quoted context omitted.

Napkin math and ROI, no one is asking for the cents. For example, build system improvement on 10% of build time across 200 developers who on average get paid 300k a year - that's a very easy math, no ? Same for time to deploy, improvements on time to fix a bug, etc. etc. You can extrapolate and compare initiatives and projects on t-shirt sizes and ROIs. Knowing where yours sit as well. What places I've worked at ? Mo…

I rarely got to know the actual deployment scale of anything I've done. Let's make a list: Ground software for an observation satellite. My internship was about implementing a dead simple neural "network" (2 hidden layers, no feedback), everything was specified from up top, we didn't even get to touch the learning algorithms. Impact? I guess a big flat zero, since all the differentiators was in the learning parameter…

If I could offer one piece of unsolicited advice: in whatever you do next, make it a point to understand a) how the business is doing and b) what your impact to the business will be.

Make it a point to gather numbers like e.g. revenue figures, growth rates, costs, usage metrics. It is true that us underlings aren't usually handed these numbers, but you might be surprised by how easy it is to get them once you start looking. And once you have those numbers, you can derive some good estimates around your own impact towards the business.

Having those numbers will help you understand your own impact. They will also help you avoid companies that, for a lack of a better word, are destined to fail.

(I'm a fan of your blog btw. I really liked the article on the Monty Hall problems!)

Re: In Defense of Simple Architectures (2022)

#395

Post by aprdm »

loup-vaillant wrote: post #378
aprdm wrote: post #374

Earlier quoted context omitted.

At a lot of companies I've worked at, the engineers are empowered to decide on what to work at, it's not like they're 100% booked by PMs. Even if PMs, they can argue. "Your manager tells you what to work on" isn't how big tech runs for the most part, in fact it's a bit sad to think that some people work like that

It's how most people had me work. It's how most of my colleagues had to work too. Just doing what my manager tells me to work on is what is considered normal and expected in… 8 of the 10 or so places I've worked at. The empowerment you speak of is but a faint dream in my town.

Interesting. That's different from companies I've worked at, where the sw developer usually asks for clarifications and can fight back if they have something else that they feel should be worked on that has a bigger ROI for the company. Companies I've worked at recently have been much more bottom up than top down

Re: In Defense of Simple Architectures (2022)

#396

Post by rugger »

PeterisP wrote: post #176
rugger wrote: post #64

Earlier quoted context omitted.

A few comments point out that replacing a monolith with micro services doesn't reduce complexity. I agree 100%. That's why I mentioned Event Sourcing pattern, not "microservices". Think of a single event log as a source of truth where all the data goes, and many consumer processes working in parallel alongside, picking only those events (and the embedded data) that concern them, reacting to them, then passing it on n…

"passing it on not knowing what happens later" often is fundamentally not acceptable - you may need proper transactions spanning multiple things, so that you can't finalize your action until/unless you're sure that the "later" part was also completed and finalized.

An individual component participating in a complex operation spanning multiple steps indeed knows nothing about the grand scheme of things. But there will be one event consumer component specifically charged with following the progress of this distributed transaction (aka saga pattern).

Re: In Defense of Simple Architectures (2022)

#397

Post by throwaway2037 »

jerf wrote: post #182
throwaway2037 wrote: post #110

Earlier quoted context omitted.

> But Python's disadvantages can be pretty significant. "Dynamic typing" and "deals with money" is a combination that would make me pretty nervous. YMMV. This is an interesting comment. I do not disagree. In your opinion, if not Python, then what languages would be acceptable to you?

Starting today: Go, C#, Rust, possibly TypeScript (not my personal choice but probably acceptable), Java (which despite being poorly done in a lot of places does have the tooling necessary for this if used by decent programmers). C++ with a super-strong static analysis tool like Coverity used from day one. (I consider C or C++ plus something like Coverity to be essentially a different language than using just a C or…

In my experience writing software that performs financial calculations, it is easy to screw up in any language. I'm not sure that any of those languages provide a great enough advantage specific to financial calculations, considering all of the other baggage. To state the obvious, most apps that perform financial calculations are not performing financial calculations in 99% of the code.

Re: In Defense of Simple Architectures (2022)

#398

Post by default-kramer »

lll-o-lll wrote: post #349
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…

> I've never really understood why you couldn't just break up your monolith into modules You can! We used to do this! Some of us still do this! It is, however, much more difficult. Not difficult technically, but difficult because it requires discipline. The organisations I’ve worked at that have achieved this always had some form of dictator who could enforce the separation. Look at the work done by John Lakos (and v…

> easy way to enforce modularity and does not require the strict discipline required in a monolith

In my experience, microservices require more discipline than monoliths. If you do a microservice architecture without discipline you end up with the "distributed monolith" pattern and now you have the worst of both worlds.

Re: In Defense of Simple Architectures (2022)

#399

Post by whiterknight »

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…

When was the last time you saw a system fail because it was under engineered? I don’t mean bad code. I mean something like a single file with 100k lines with structs and functions, or a MySQL instance serving millions of customers a day.

Re: In Defense of Simple Architectures (2022)

#400

Post by whiterknight »

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

Daily reminder that when one process is blocked others can be working so nothing is “idling” on a web server properly configured.
Post reply on HN