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

21–30 of 447 posts

Re: In Defense of Simple Architectures (2022)

#21

Post by CuriouslyC »

zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

That guy was just optimizing for future employability, albeit in a short sighted way. Being able to talk in an interview about how you have professional experience with various tech stacks is valuable. That being said, optimizing for that at the cost of current job performance and coworker alienation is just dumb, since job performance and networking leads are more important for landing good jobs. I'm guessing this guy was a serial job hopper who had no expectation of being able to progress up the ladder at the company you were at.

Re: In Defense of Simple Architectures (2022)

#22

Post by nickserv »

zer00eyz wrote: post #14
gherkinnn wrote: post #4

I'm going to agree with Dan Luu by asking where I can find more of these sane companies. I want to spend an honest 6h a working day improving a product (Terraform and Webpack are not the product) and spend the rest of my time tending to my garden.

You aren't looking for a job. You're looking for a lifestyle business. They are great. You will get time in the garden, that's awesome. Vacation someplace with no phones? Out of the question. Weekend in a 3rd world country with character and food and sketchy internet. Not gonna happen. You want to optimize for free time in the garden by all means you can do it, but you loose out in other places, you pick up other wor…

Not sure I understand your point. I do my work, doing development work and managing a small team.

Still never work weekends (no phone, no email, no slack), spend time in my garden and just came back from a no-phone vacation.

Salary is above the going rate where I live - the work is remote and salary is based on company headquarters. Taxes are in line with the country I live in.

Not really seeing any downsides here, and as expected morale is quite good overall at work... But finding this company was extremely lucky/difficult.

Re: In Defense of Simple Architectures (2022)

#23

Post by CuriouslyC »

thimp wrote: post #19
zmgsabst wrote: post #16

Earlier quoted context omitted.

When has a decision that’s bad for the decision maker ever been popular? We see it in the C-suite; we see it with engineers. I think the travesty of so-called “principal engineers” and “engineering leaders” is their adamant refusal to make doing the Right Thing (TM) sexy. Your employees are monkeys: act like it.

Yep. Microservices! AWS! Everything Gartner and Thoughtworks says! It'll look good on my resume... ..several years later.. Escalating cloud costs, high staffing cost, staff turnover, heavily reduced margins, decreased productivity, burnout, clients unsatisfied, C-suite paving over this by hiring more marketers...

I wonder how many early stage businesses went tits up because they drank the microservice kool-aid and burned valuable engineering cycles that should have been spent on features on docker spaghetti.

Re: In Defense of Simple Architectures (2022)

#24

Post by mousetree »

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

These are all specific problems that can be individually solved. Personally I don’t see how changing their architecture or programming language would solve those

Re: In Defense of Simple Architectures (2022)

#25

Post by CuriouslyC »

throwawayanothe wrote: post #5

Writes simple and then drops GraphQL and K8s.

As someone who dissed GraphQL for a long time, Hasura/Apollo are in a really good place now, the amount of code you don't have to write and the performance/features you get for free are really compelling. The setup isn't conceptually simple, but it sure does keep your codebase lean.

Re: In Defense of Simple Architectures (2022)

#26

Post by namaria »

simonbarker87 wrote: post #20

Our stack is a NestJS server, Handlebars templates for SSR, htmx and a PostgresSQL database. Deployed as a container on GCP Cloud run with a Github action. It's delightful to work on and very responsive in a way that a React app with the same data load wouldn't be. At this point it would take a pretty massive reason to get me to adopt the SPA approach again.

I usually also use Cloud Run for running my containers. But I use Cloud Build instead of GH Actions. I'm curious, what's your reasoning? I prefer my repository to just hold code and run build actions close to where it's deployed.

Re: In Defense of Simple Architectures (2022)

#27

Post by nickserv »

rugger wrote: post #8

Monolith is fine if you have a fairly simple process for manipulating your data. Like posting an article, then a comment, with some moderation thrown in. But when you start adding business rules, and start transforming your data and moving it around, then your monolith will become too complex and often too expensive to run. Lots of moving parts tightly coupled together, long-running transaction wrapping multiple join…

Ironically, business rules are often much easier done in a monolith, since they tend to require access to basically the entire database, and have impact across your code base.

Not saying it needs to be spaghetti all over the code mind you. Just that it's easier to have a module within the monolith rather than a dedicated service.

Re: In Defense of Simple Architectures (2022)

#29

Post by zer00eyz »

CuriouslyC wrote: post #21
zer00eyz wrote: post #10

Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…

That guy was just optimizing for future employability, albeit in a short sighted way. Being able to talk in an interview about how you have professional experience with various tech stacks is valuable. That being said, optimizing for that at the cost of current job performance and coworker alienation is just dumb, since job performance and networking leads are more important for landing good jobs. I'm guessing this g…

> I'm guessing this guy was a serial job hopper who had no expectation of being able to progress up the ladder at the company you were at.

The magpie was practically furniture (Over a decade there). We speculated that he had buried a literal body for the CEO based on what he got away with. Shiny objects was an astute call on the part of IT guy (he was setting up another new MacBook for him)

Re: In Defense of Simple Architectures (2022)

#30

Post by kaba0 »

rugger wrote: post #8

Monolith is fine if you have a fairly simple process for manipulating your data. Like posting an article, then a comment, with some moderation thrown in. But when you start adding business rules, and start transforming your data and moving it around, then your monolith will become too complex and often too expensive to run. Lots of moving parts tightly coupled together, long-running transaction wrapping multiple join…

Why do we need "scale"? The 2nd cheapest Hetzner offering can probably serve a hundred thousand people a basic CRUD app just fine, with the DB running on the same machine. And you can just buy a slightly more expensive machine if you need scale, horizontal scaling is very rarely necessary actually.

Stackoverflow runs on a couple of (beefy) machines only.

Post reply on HN