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

111–120 of 447 posts

Re: In Defense of Simple Architectures (2022)

#111

Post by nijave »

mousetree wrote: post #24
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

In addition, they risk introducing new problems they already solved with their current setup

Re: In Defense of Simple Architectures (2022)

#112

Post by devjab »

throwaway2037 wrote: post #73

> For example, at a recent generalist tech conference, there were six talks on how to build or deal with side effects of complex, microservice-based, architectures and zero on how one might build out a simple monolith. Queue my favourite talk about microservices: David Schmitz - 10 Tips for failing badly at Microservices [1] This guy has amazing delivery -- so dry and funny. He spends 45 minutes talking about all of…

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 places with too much “building like we’re Netflix” because often your microservices can easily be what is essentially a bunch of containerised monoliths.

I think the main issue is that your IT architecture has or should have) very little to do with tech and everything to do with your company culture and business processes. Sometimes you have a very homogeneous focus maybe even on a single product, in which case microservices only begin to matter when you’re Netflix. Many times your business will consist of tens-thousands of teams with very different focuses and needs, and in these cases you should just never do monoliths unless you want to end up with a technical debt that will hinder your business from performing well down the line.

Re: In Defense of Simple Architectures (2022)

#113

Post by throwaway2037 »

xnorswap wrote: post #79
yowlingcat wrote: post #54

Earlier quoted context omitted.

Which language with those characteristics will have the same package ecosystem as Python so that your engineering team isn't left constantly reinventing the wheel? Do you think it's worth rebuilding stable packages that do a job well just because you don't think the language it was written in was perfect?

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?

Re: In Defense of Simple Architectures (2022)

#114

Post by ranjanprj »

Micro services is a deployment pattern and not a development pattern you could build monolith and expose various services to and various parts with an Ingress and point of to the same monalic and for example in java project these various end points of the services inside the same on it would only load up the classes/objects which are relevant to that service. There is no overhead in terms of memory or CPU by placing monolith as micro services exposed by end points

Re: In Defense of Simple Architectures (2022)

#115

Post by perrygeo »

bunderbunder wrote: post #87

I think a lot of this comes from the additive cognitive bias, which is really deeply entrenched in most of our thinking. Here's a concrete example, stolen from JD Long's great NormConf talk, "I'd have written a shorter solution but I didn't have the time", which is itself drawing from "People systematically overlook subtractive changes" by Adams, et al., 2021: Give people a Lego construction consisting if a large, st…

In software, it's clear why we don't prefer subtractive changes - complexity. If there's any chance that the code in question has non-local effects that can't be reasoned about at the call site, it's risky to make subtractive changes.

Additive changes have the advantage of having a corresponding additive feature to test - you don't need to touch or even understand any of the existing complexity, just glue it on top.

So the cost structure is likely inverted from the study you describe. Additive changes are (locally) cheap. Subtractive changes are potentially expensive.

Re: In Defense of Simple Architectures (2022)

#116

Post by treflop »

The problem is that most people have never actually built something in all the architectures they are considering.

They just read blog posts of what to do.

As an analogy, I’ve manufactured a lot of stuff out of wood, concrete, plastic (3D printed) and increasingly more metal. When I need a jig, I know what each material will be like and what I will be getting out of it.

Re: In Defense of Simple Architectures (2022)

#117

Post by nijave »

dns_snek wrote: post #84
nijave wrote: post #72

Earlier quoted context omitted.

Microservices can help with performance by splitting off performance critical pieces and allowing you to rewrite in a different stack or language (Rust or go instead of Ruby or Python) But yeah, they also tend to explode complexity

An important point that people seem to forget is that you don't need microservices to invoke performant native code, just a dynamic library and FFI support. The entire Python ecosystem is built around this idea.

You don't need it but you can also explode your repo, test, and build complexity when it'd be easier to keep them isolated.

For instance, you might not want to require all develops have a C tool chain installed with certain libraries for a tiny bit of performance optimized code that almost never gets updated.

Re: In Defense of Simple Architectures (2022)

#118

Post by notpachet »

quaunaut wrote: post #68
DonnyV wrote: post #42

Earlier quoted context omitted.

For a financial services company they should be using a compiled language. Something like C# or Java or Rust or Go with Postgres.

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

Better static analysis, for one.

Re: In Defense of Simple Architectures (2022)

#119

Post by randomdata »

ranjanprj wrote: post #114

Micro services is a deployment pattern and not a development pattern you could build monolith and expose various services to and various parts with an Ingress and point of to the same monalic and for example in java project these various end points of the services inside the same on it would only load up the classes/objects which are relevant to that service. There is no overhead in terms of memory or CPU by placing…

Micro services is a team organization pattern, emulating the software service model, except within a micro economy (i.e. a single business). In practice, this means that teams limit communication to the sharing of documentation and established API contracts, allowing people to scale without getting bogged down in meetings.

Re: In Defense of Simple Architectures (2022)

#120

Post by bluGill »

devjab wrote: post #112
throwaway2037 wrote: post #73

> For example, at a recent generalist tech conference, there were six talks on how to build or deal with side effects of complex, microservice-based, architectures and zero on how one might build out a simple monolith. Queue my favourite talk about microservices: David Schmitz - 10 Tips for failing badly at Microservices [1] This guy has amazing delivery -- so dry and funny. He spends 45 minutes talking about all of…

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…

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 Netflix has actually documented their architecture in enough detail that you could use it. Even if you hire Netflix architects they may not themselves know some important parts (they will of course know the parts they worked on)

Post reply on HN