In Defense of Simple Architectures (2022)
1–10 of 447 posts
Re: In Defense of Simple Architectures (2022)
#2> Our architecture is so simple I’m not even going to bother with an architectural diagram. Instead, I’ll discuss a few boring things we do that help us keep things boring.
Maybe that is why everyone goes with the the latest and greatest sophisticated techniques that are popular on the conference circuit. At least it has a diagram.
Re: In Defense of Simple Architectures (2022)
#3Think there's lot of examples of the Fortune 5000 just being a single Rails or Django app for the longest time.
Seems in line with the we're soon going to see a single person billion dollar company narrative.
Re: In Defense of Simple Architectures (2022)
#4I'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.
Re: In Defense of Simple Architectures (2022)
#5Writes simple and then drops GraphQL and K8s.
Re: In Defense of Simple Architectures (2022)
#6Writes simple and then drops GraphQL and K8s.
Both of which are justified in the post. Like, complexity where it makes sense is a good thing, especially if that complexity brings benefits.
Complexity for the sake of complexity is foolish.
Re: In Defense of Simple Architectures (2022)
#7Writes simple and then drops GraphQL and K8s.
[deleted]
Re: In Defense of Simple Architectures (2022)
#8Monolith 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 joined tables etc. Rolling out new features will become very challenging as well.
Something like event sourcing is more complex to set upfront than a monolith, but at least it offers the way to add scale and features later without creating a combinatorial explosion...
Re: In Defense of Simple Architectures (2022)
#9Writes simple and then drops GraphQL and K8s.
Both of which are justified in the post. Like, complexity where it makes sense is a good thing, especially if that complexity brings benefits. Complexity for the sake of complexity is foolish.
Enough of this strawman one-liner "complexity for the sake of complexity". Unnecessary complexity is introduced because someone once thought it was necessary. It may not be necessary anymore, or (even worse) it might have not even been necessary at the time and the person who introduced it was just wrong. But all complex architectures start because people think it will bring benefits.
Re: In Defense of Simple Architectures (2022)
#10Early 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 use. No sense of if it would be better, faster, cheaper, useful.
When cloud was the hot new thing the company that I worked with launched a replatform on AWS. It gave us the ability to get through the initial scaling and sizing with ease. We left right away, because even then the costs did not make sense. Now we see folks crying about "exit fees" that were always there. That assumes that your institution even has the gall to own years of pissing away money.
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.