Live data from Hacker News

In Defense of Simple Architectures (2022)

danluu.com

321–330 of 447 posts

Re: In Defense of Simple Architectures (2022)

#321
post #19

Earlier quoted context omitted.

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

Well, did it look good on the resume?

Someone had to stay behind and muck out the stables...

Re: In Defense of Simple Architectures (2022)

#322

Earlier quoted context omitted.

I work on embedded systems so userbase isn't really a concern. However we have > 10 million lines of C++, and the change would have been a major refactoring of most of them.

So I'm assuming this decision was made quite a while ago? Years, maybe even over a decade?

It took a decade to find the data to show that this decision we made 10 years ago was bad - for those entire 10 years we all thought it was good until we we looking at a performance issue and realized the roots case what a decision made in the early days had an unexpected side effect.

Re: In Defense of Simple Architectures (2022)

#323

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…

> Your pipe has to be big enough for all of it.

What do you mean by "pipe" here? It's easier to share CPU and network bandwidth across monolith threads than it is across microservice instances. (In fact, that is the entire premise of virtualization - a VM host is basically a way to turn lots of disparate services into a monolith.)

Re: In Defense of Simple Architectures (2022)

#324
post #154

Earlier quoted context omitted.

> Workman like functionality isnt sexy, it wont be the hot bullet point on your resume, it wont get you your next job, but it is dam effective. So, not fun, not rewarding, no intellectual challenge, no career benefit. Why exactly should I want to do it? This isn't the goddamn United Federation of Planets, nor is the company a church - why exactly should I go above and beyond what I agreed to in exchange for my salary…

> So, not fun, not rewarding, no intellectual challenge, no career benefit. Why exactly should I want to do it? It does help you get the next job. You’re just pitching it wrong. Instead of “Built boring tech” try “Delivered $5,000,000 return 2 months early”. Watch your inbox blow up. Business leaders don’t care about what you do, they care about results. What you do to get those results is just an unfortunate cost an…

Most companies out there want you to have certain technologies / keywords in your resume and will automatically reject you if you don't have them.

Yes, building a solid project with boring technology that delivers real business value sounds good in theory but not so good when applying for a new job. Maybe it can help after you somehow manage to pass some initial screening.

Re: In Defense of Simple Architectures (2022)

#325

Earlier quoted context omitted.

Building like NetFlix is better than random unguided architectures that result from not thinking. It might not be the best for your problem though. If you don't need thousands of servers, then the complexity that Netflix has to put into their architecture to support that may not be worth the cost. However if you do scale that far you will be glad you choose an architecture proven to scale that large. However I doubt…

It's a very bold assumption that a team that cannot manage a monolith will somehow lay a robust groundwork that will be the foundation of a future Netflix-like architecture. By the way - Netflix started as a monolith, and so did most other big services that are still around. The rest faded away, crushed by the weight of complexity, trying to be "like Netflix".

There are much better options above copying someone else. Copy is better than letting anything happen, but you should do better. You should learn from Netflix, stackoverflow and the like - no need to remake the same mistakes they did - but your situation is different so copy isn't right either.

Re: In Defense of Simple Architectures (2022)

#326
post #66

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 think thats one of the biggest misconceptions for engineers. On the other end you have the monorepo crew, who are doing it for the same reasons. On your note about resiliency and scale - its always a waste of money until shit hits the fan. Then you really pay for it.

How do you square that with the fact that shit usually hits the fan precisely because of this complexity, not in spite of it? That's my observation & experience, anyway. Added bits of "resiliency" often add brand new, unexplored failure points that are just ticking time bombs waiting to bring the entire system down.

Microservices almost always increase the amount of partial failures, but if used properly can reduce the amount of critical failures.

You can certainly misapply the architecture, but you can also apply it well. It's unsurprising that most people make bad choices in a difficult domain.

Re: In Defense of Simple Architectures (2022)

#327
This post read like a “we want an operationally simple setup,” until the bit about selecting Kube as an orchestration technology. I think it’s still a service oriented architecture and still has to reason about asynchronicity given it uses celery and queues.

Re: In Defense of Simple Architectures (2022)

#328
post #223

Earlier quoted context omitted.

> delivered a project very fast with X,Y and Z and saved the company $100mil The problem is that $100mil is all pixie fairy dust when you're working on a new project. I wish this wasn't true but it works out better for you to implement it as costly and complex as possible, show off how smart you are, then simplify it during a cost cutting initiative (wow they must be so smart to make such an obviously complex system…

> ...while you think you're getting away with something playing this game you're actually doing exactly what the business wants. How so? I would think the business wants to spend as little money as possible.

Well maybe not what it wants, but probably (depending on culture) what it _rewards_.

Re: In Defense of Simple Architectures (2022)

#329
This one is a classic (instant classic), I can't say anything about this better than Dan did.

What I can offer is a personal anecdote about what an amazing guy he is. I had been a fan of his blog for a while, and at one point I decided to just email him and offer to fly to wherever he was because I wanted to hear his thoughts on a number of topics.

This was in maybe 2016, but even then I didn't expect someone who must get a zillion such emails to even reply, let alone invite me up to Seattle at my leisure! I think I had the flight booked on a Wednesday for a departure on Friday, for one night's stay, and Dan was profoundly generous with his time, we stayed up late into the night chatting and I learned a great deal, especially about the boundary between software and hardware (a topic on which he is a first-order expert with an uncommon gift for exposition).

I had the great fortune of spending some real time with Dan not just once but twice! When I went to NYC to get involved with what is now the Reels ML group, he happened to also be in NYC, and I had the singular pleasure to speak with him at length on a number of occasions: each illuminating and more fun than you can have without a jet ski.

Dan is a singularly rigorous thinker with the dry and pithy wit of a world-class comedian and a heart of gold, truly generous with his expertise and insight. I'm blessed to have met and worked with a number of world-class hackers, but few, few if any are such a joy to learn from.

Re: In Defense of Simple Architectures (2022)

#330
post #154

Earlier quoted context omitted.

> So, not fun, not rewarding, no intellectual challenge, no career benefit. Why exactly should I want to do it? It does help you get the next job. You’re just pitching it wrong. Instead of “Built boring tech” try “Delivered $5,000,000 return 2 months early”. Watch your inbox blow up. Business leaders don’t care about what you do, they care about results. What you do to get those results is just an unfortunate cost an…

> Instead of “Built boring tech” try “Delivered $5,000,000 return 2 months early”. How do I do that without lying through my teeth? 17 years on the job, I never had the data to even begin estimate that kind of things. It was never my job to know it (I'm a programmer, not an accountant), and it was often actively hidden from me. And how did you do it? How did you get your numbers, and what did you tell recruiters when…

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.

Post reply on HN