is there a patreon tier that adds css margins? if you’re gonna beg for handouts you could at least make the site readable
In Defense of Simple Architectures (2022)
171–180 of 447 posts
Re: In Defense of Simple Architectures (2022)
#172"Simple" is an interesting term. I've always found it to be very relative to what someone's actual experiences and knowledge bases are.
For example, virtual machines are something I and probably most other people consider "simple". They're pretty much just little computers. For the most part, I can just work with VMs the same way I would work with computers. No sweat.
My DevOps pedigree, however, also means I consider Docker containers and even some light k8s stuff as pretty "simple" - when these two things feel to other people like massive overcomplications.
On the other hand, I'm pretty new to GraphQL, and it feels to me vastly more confusing than good old fashioned REST API endpoints, where I can crack open the code and actually see exactly how that particular endpoint works. I am mostly alone in my org when it comes to this feeling, because I haven't digested the abstractions that make GraphQL work as well.
I don't really have a good answer then for what simple is beyond "I know it (kinda) when I see it".
Re: In Defense of Simple Architectures (2022)
#173Earlier quoted context omitted.
To be fair, a million requests per month is 20 requests per minute...
> To be fair, a million requests per month is 20 requests per minute... Which, in B2B, is insanely profitable. At 20 rqsts/min, for a paying customer paying you $200/m/user, those numbers are fantastic! I can only dream of having those numbers!
Sure, but in terms of load, dealing with the requests, a single raspberry pi 2 will barely register that even if you deploy it with a CGI stack.
Re: In Defense of Simple Architectures (2022)
#174Earlier 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...
Well, did it look good on the resume?
Re: In Defense of Simple Architectures (2022)
#175Hmm I dunno, this architecture feels simple in some ways but genuinely pretty complex in others. Like they defined their own protocol? That's pretty not-simple.
It's like the StackOverflow example. Sure, the architecture is conceptually simple, but you still bought servers and are maintaining them yourself. That's pretty complicated unto itself. Probably the right decision, but not the "simplest".
Re: In Defense of Simple Architectures (2022)
#176Monolith 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…
A few comments point out that replacing a monolith with micro services doesn't reduce complexity. I agree 100%. That's why I mentioned Event Sourcing pattern, not "microservices". Think of a single event log as a source of truth where all the data goes, and many consumer processes working in parallel alongside, picking only those events (and the embedded data) that concern them, reacting to them, then passing it on n…
"passing it on not knowing what happens later" often is fundamentally not acceptable - you may need proper transactions spanning multiple things, so that you can't finalize your action until/unless you're sure that the "later" part was also completed and finalized.
Re: In Defense of Simple Architectures (2022)
#177As a young gun coming from working in games before touching "internet"/"enterprise" software back around 2006 I had an eye on performance matters and all the early Google papers caught my eye (esp as I was on a project with an overpositive sales CEO that had in his mind that we'd run to Google valuations within a year). A sobering account was our second CTO who told us that their previous 65000 user application ran o…
I work at a company with several 100k MAU. Single db + 1 standby replica. No problems.
I believe even Stackoverflow used to run on something similar, not sure.
Re: In Defense of Simple Architectures (2022)
#178Earlier quoted context omitted.
> IT is the only sector where companies like Cisco or SAP can exist despite the horrible reliability of their products Come on, other industries have garbage companies putting out garbage products, too.
> Come on, other industries have garbage companies putting out garbage products, too. That's correct, but we have to admit that the software industry excels at this.
Software is full of monopolies. But monopolies' products are garbage in every industry.
Re: In Defense of Simple Architectures (2022)
#179Good article! I like that it suggests a pragmatic approach, and introduces complexity only when it's necessary and makes sense to do so. Often engineers advocating for KISS end up (poorly) reimplementing the complex version, when just adopting the "complex" alternative would've avoided them all the development and maintenance headaches. That said, "simple" and "complex" are subjective terms, and they're not easily de…
I don't like this grugbrain approach because complexity is subjective, as you mentioned, and the grugbrain mentions simply saying "no" instead of telling a dev to articulate why something shouldn't be in the codebase properly.
I mention this because I've been a lot of times in a place where instead of adopting "well maintened library that everyone is using since more than a decade" I had to write and maintain my own solution just to appease someone else because they thought it would be less work (it wasn't, maybe for them, definitely not for me).
We need less posts in software development that people try to argue in absolutes.
Re: In Defense of Simple Architectures (2022)
#180I think these kinds of articles are a bit glib. Developers implement architecture to solve problems confronting them. Sometimes a new problem then arises which must be dealt with, and so on, until the architecture in hindsight is quite complex. But you can only know this in hindsight. A few companies didn't run into the "piling on" of issues to be fixed, and so look back in hindsight, see their simple architecture, a…
Architecture isn't done to solve problems confronting you now, it is about solving problems you will face in the future if you don't solve them now.