In defense of simple architectures
danluu.com
In defense of simple architectures
1–10 of 196 posts
Re: In defense of simple architectures
#2My favorite trap in all of this, is that this thinking will fail most tech interviews. It is incredibly frustrating.
Re: In defense of simple architectures
#3My favorite trap in all of this, is that this thinking will fail most tech interviews. It is incredibly frustrating.
I guess the only thing you can do is avoid those places. Last time I checked Wave were on a hiring spree.
Re: In defense of simple architectures
#4My favorite trap in all of this, is that this thinking will fail most tech interviews. It is incredibly frustrating.
I think that probably says more about the tech companies than anything else.
Re: In defense of simple architectures
#5Just boils down to not optimising until you need to. Start with a 3 tier web app (unless your requirements lead you to another solution), then start with read replicas, load balancing, sharding, redis/RabbitMQ etc
Re: In defense of simple architectures
#6My favorite trap in all of this, is that this thinking will fail most tech interviews. It is incredibly frustrating.
Trap or integrated win-win?
We use one of these "aggressively simple" architectures too. At this point, I would quit my job instantaneously if I had to even look at k8s or whatever the cool kids are using these days.
Re: In defense of simple architectures
#7I think especially for small teams starting out, complex architecture can be a huge trap.
Our architecture is extremely simple and boring - it would probably be more-or-less recognizable to someone from 2010 - a single Rails MVC app, 95+% server-rendered HTML, really only a smattering of Javascript (some past devs did some stuff with Redshift for certain data that was a bad call - we're in the process of ripping that out and going back to good old Postgres)
Our users seem to like it though, and talk about how easy it is to get set up. Looking at the site, the interactions aren't all that different from what we would build if we were using a SPA. But we're just 2 developers at the moment, and we can move faster than much larger teams just because there's less stuff to contend with.
Re: In defense of simple architectures
#8The vast, vast, vast majority of organizations don't need micro services, don't need half of the products they bought and now have to integrate into their stack, and are simply looking to shave their yak to meet the bullet list of "best practices" for year 202X. Service oriented architectures and micro services solve a particular problem for companies that are operating on a massive scale and can invest (read waste money) on teams devoted to tooling. What most companies should do is build a monolith that makes money, but hire good software engineers that can write packages/modules whatever with high levels of cohesion and loose coupling, so that one day when you become the next Google, it will be less of a pain to break it into services. But in the end it really doesn't matter if it's painful anyway, because you'll have the money to hire an army of people to do it while the original engineers take their stock and head off to early retirement.
Re: In defense of simple architectures
#9I think the biggest problem for most developers is not understanding what one computer can actually do and how reliable they are in practice.
Additionally, understanding of how tolerant 99% of businesses are to real-world problems that could hypothetically arise can help one not frustrate over insane edge case circumstances. I suspect a non-zero number of us have spent time thinking about how we could provide deterministic guarantees of uptime that even unstoppable cosmic radiation or regional nuclear war couldnt interrupt.
I genuinely hope that the recent reliability issues with cloud & SAAS providers has really driven home the point that a little bit of downtime is almost never a fatal issue for a business.
"Failover requires manual intervention" is a feature, not a caveat.
Re: In defense of simple architectures
#10My favorite trap in all of this, is that this thinking will fail most tech interviews. It is incredibly frustrating.
Yep. Failed an interview because I used EJS (SSR) and Node to build a simple Twitter in 30mins. The interviewer saw that it was three files and did not seem impressed.
I guess they wanted me to use lots of little components in an SPA which I did in my day job, but it didn't seem nessisary for the task...