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

361–370 of 447 posts

Re: In Defense of Simple Architectures (2022)

#361

Post by al_borland »

TeMPOraL wrote: post #315
al_borland wrote: post #281

Earlier quoted context omitted.

If the equilibrium is always reached, then why wouldn’t I make it easy on myself by making things that are easy to maintain? I want fixing issues to be like blowing out a birthday candle, not dealing with a forest fire? I’d rather blow out 20 candles than deal with a single forest fire.

Of course you would want to do that. However: 1. It's hard to estimate what will or won't be easy to maintain down the line; 2. New tech becomes hot new tech because it promises to be easy to maintain down the line; 3. Most of the maintenance burden is due to choices of other people anyway, so you have limited control over that. Trying new tech is often a bet on the promise of better maintainability turning out true.…

I tend to stop trusting people/companies/industries which break promise after promise. I want to go with solutions which have proven themselves to be true and stood the test of time. It needs to be worth people’s time to learn, not just today, but in 5 years.

A lot of times tech is so focused on the tech that they forget about real problem they’re trying to solve.

Re: In Defense of Simple Architectures (2022)

#362

Post by loup-vaillant »

aprdm wrote: post #347
loup-vaillant wrote: post #291

Earlier quoted context omitted.

> In my experience the boring "I delivered a project very fast with X,Y and Z and saved the company $100mil" will win over "I rearchitected a massive system to run on microservices Good luck having the opportunity to work in a project where you have even the faintest idea how much money your contribution will make or save. I don't know about you, but never in my 17 year career have I had enough information to even at…

It's crazy that you don't know. I've been in this industry for 20y and apart from when I was extremely junior I always had a sense of the business impact of my work.

Yeah, a sense. A guess. A gut feeling. Based on what exactly? I sure do get a sense of what will require less effort in the long run, or what will makes the user's life easier, or even what is likely to decrease the defect rate… but I dare 95% of programmers, even the subset active here on HN, to reliably assess the monetary impacts of those decisions within one order of magnitude, especially compared to the alternatives.

Not to mention the monetary impacts of decisions totally outside my control. I can tell the architect "you suggest A, but B is simpler to use and makes the API 3 times simpler at no loss of functionality", what's the point of estimating the impact of such a no-brainer when the architect answers is "you're correct, but we'll do it my way" (real story)? And how do you expect me to estimate the monetary impact of pointing out that their TPM provisioning is missing a verification step? That stuff happens inside the factory, a problem at this stage is unlikely anyways. And even if I could somehow divine my monetary impact, the best I can say now is "I did good work for this company, they didn't listen to me, and now they're going under". Not even kidding, they are going under. I just ended my gig there because I couldn't take it any more.

What are those wonderful places you worked at where you could estimate your impact with reasonable accuracy?

Re: In Defense of Simple Architectures (2022)

#363

Post by dustedcodes »

Look I love the http://motherfuckingwebsite.com and think it's hilarious and I totally agree with the underlying message, to cut out a lot of the shit and just keep the web simple sometimes, but is it really necessary to have absolutely no style whatsoever which makes reading this blog post an absolute chore. It's so off putting that I can't bring myself to read it. Anyone else or just me?

Re: In Defense of Simple Architectures (2022)

#364

Post by aprdm »

loup-vaillant wrote: post #362
aprdm wrote: post #347

Earlier quoted context omitted.

It's crazy that you don't know. I've been in this industry for 20y and apart from when I was extremely junior I always had a sense of the business impact of my work.

Yeah, a sense. A guess. A gut feeling . Based on what exactly? I sure do get a sense of what will require less effort in the long run, or what will makes the user's life easier, or even what is likely to decrease the defect rate… but I dare 95% of programmers, even the subset active here on HN, to reliably assess the monetary impacts of those decisions within one order of magnitude, especially compared to the alterna…

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 ? Mostly business that made some money and were stable.. apart from a start up that was VC funded and made no money

Re: In Defense of Simple Architectures (2022)

#365

Post by [deleted] »

aprdm wrote: post #347
loup-vaillant wrote: post #291

Earlier quoted context omitted.

> In my experience the boring "I delivered a project very fast with X,Y and Z and saved the company $100mil" will win over "I rearchitected a massive system to run on microservices Good luck having the opportunity to work in a project where you have even the faintest idea how much money your contribution will make or save. I don't know about you, but never in my 17 year career have I had enough information to even at…

It's crazy that you don't know. I've been in this industry for 20y and apart from when I was extremely junior I always had a sense of the business impact of my work.

[deleted]

Re: In Defense of Simple Architectures (2022)

#366

Post by hcarvalhoalves »

CharlieDigital wrote: post #132
devjab wrote: post #112

Earlier quoted context omitted.

Monoliths aren’t very useful in many organisations where you need to build and connect 300+ systems. They also stop having simple architecture if you try. Most architecture conferences and talks tend to focus more on the enterprise side of things, and really, why would you need full time software focused architects if you’re building something like stackoverflow. I do think things have gotten a little silly in many p…

> Monoliths aren’t very useful in many organisations where you need to build and connect 300+ systems Seems like the mistake is building 300+ systems instead of a handful of systems. A Google team published a paper on this last year: https://dl.acm.org/doi/10.1145/3593856.3595909 > When writing a distributed application, conventional wisdom says to split your application into separate services that can be rolled out…

Full-circle back to mainframe programming model.

Re: In Defense of Simple Architectures (2022)

#367

Post by jmull »

from-nibly wrote: post #51

This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…

> In a shared monolith however 0 people own it because everyone owns it and the repo becomes a disaster faster than you can say "we need enterprise caching".

* I give two teams one repo each and tell each one: "This is your repo, keep it clean."

-or-

* I give two teams one folder each in a repo and tell each one: "This is your folder, keep it clean."

If you've got a repo or folder (or anything else) that no one is responsible for, that's a management problem, and micro services won't solve it.

Repos (and folders) don't really have anything to do with organizing a complex system of software -- they are just containers whose logical organization should follow from the logical organization of the system.

Microservices back you into position where when the code of one team to calls the component of another team, it has to be high-latency, fault-prone, low-granularity, config-heavy. Some stuff falls the way anyway, so no problem in those case, but why burn that limitation in to your software architecture from the start? Just so you don't have to assign teams responsibility for portions of a repo?

Re: In Defense of Simple Architectures (2022)

#368

Post by camgunz »

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.

> And instead you have the problem of "how do we update the version of Node on our 10 million LOC codebase?"

I think if you get to that scale everything is pretty hard. You'll have a hard time convincing me that it's any easier/harder to upgrade Node on 80 125K LOC microservices than a 10M LOC monolith. Both of those things feel like a big bag of barf.

Re: In Defense of Simple Architectures (2022)

#369

Post by leeoniya »

jmull wrote: post #367
from-nibly wrote: post #51

This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…

> In a shared monolith however 0 people own it because everyone owns it and the repo becomes a disaster faster than you can say "we need enterprise caching". * I give two teams one repo each and tell each one: "This is your repo, keep it clean." -or- * I give two teams one folder each in a repo and tell each one: "This is your folder, keep it clean." If you've got a repo or folder (or anything else) that no one is re…

i think doing releases, deployments, and rollbacks is trickier in a monorepo. with multiple services/repos, each team can handle their own release cycles, on-call rotation, and only deal with the bits, tests, and failures they wrote.

you lose some CPU/RAM/IO efficiency, but you gain autonomy and resilience, and faster time to resolution.

https://blog.nelhage.com/post/efficiency-vs-resiliency/

e.g. at Grafana we're working through some of these decoupling-to-microservices challenges, because the SREs that deploy to our infra should not need to deal with investigating and rolling back a whole monolith due to some regression introduced by some specific team to a core datasource plugin, or frontend plugin/panel. the pain at scale is very real, and engineering hours are by far more expensive than the small efficiency loss you get by over-provisioning the metal a bit.

Re: In Defense of Simple Architectures (2022)

#370

Post by loup-vaillant »

HeyLaughingBoy wrote: post #348
Swizec wrote: post #330

Earlier quoted context omitted.

Maybe I’ve been extraordinarily lucky, but I’ve always just asked and people were so excited that an engineer would actually care about things that are on their mind all day every day. Might be more common in companies managed by OKR where you always know the business impact of your work. The business impact is your prime objective and you’re free to figure out the implementation.

Right? I was going to ask OP "have you ever asked anyone?" Because, IME, managers, etc. love it when you show an interest in how the business works and where your part fits in. It also makes their job easier if they can relate the crappy stuff they have to assign you to how much benefit the business gets from it.

I must be doing something wrong because most of the time, getting interested in the wider impact of my work is held against me. I just ask why they want the stuff, suggest alternatives, point out issues, and the next day I'm an uncontrollable Maverick that means to rewrite everything and waste a ton of time…

This also happens after explicit requests for feedback. Maybe they didn't actually meant it and I'm supposed to "take the hint" or some neurotypical bullshit, but when I hear such requests I tend to take them literally, and provide real feedback on the real issues. Unfortunately for all of us those tend to be stuff that ossified years ago and cannot (or will not) be fixed any time soon. Ever, in my experience. Quite the downer.

Last time this happened I ended up being axed from a wave of layoffs. Whether their short term workflow and subsequent technical debt finally caught up to them, or their parent company just wanted to cut costs, I will never know. I do know my technical expertise was highly praised, and middle management felt I wasn't quite aligned with the goals of the company, whatever those were. (I think one significant cause was that I only emailed them about significant problems, and kept to myself and my team lead when it was smooth. I think in the future I will stop trusting them with anything negative.)

So yeah, I can bet they love it when you act interested about their work, but start questioning their decisions (even just the one directly related to your own work and its likely impact on theirs), and the tone of the conversation changes very, very quickly. At least where I've worked.

Post reply on HN