Comment by blixt | Hacker News Reader

Comment by blixt | Hacker News Reader

I agree with the general message of this article but I want to rant a bit on what exactly is "boring architecture". I haven't quite managed to put this into succinct words, but in my experience building the innards of both backends and frontends for a couple of decades, I found that there's a type of "boring architecture" or "conventional wisdom" that can actually make you build a worse product, slower.

There's nothing odd about having a horizontally scaling (stateless) API server that synchronizes with a database. And then when you need longer running processes, maybe you add in a task queue. But then you want status updates so maybe you set up a pub/sub solution. And then of course your client codebase has to merge all this information into current state. I won't say this is a bad architecture. But if you're a startup with less than 1,000 active users and a handful of engineers splitting their time between working on these systems and your product, I would say to you: how about a single fat server and a transactional database? Maybe I'm old school, but it removes so many modes of failure while increasing performance (except in the rare case that a region goes down) and yet I think people don't tend to look at this option early on if they've been exposed to too much cloudification literature.

And don't get me started on microservices.

* Disclaimer: Every business sooner or later will need to create more distributed systems as they serve more regions, promise more availability, and just generally speaking more users mean more chances for things to go wrong in the infrastructure. But I've found myself several times helping startups revert prematurely distributed architectures to get their current product failing less and running faster, and I would argue it'd be nicer to start stupid simple and expand later.

I've been building systems for two decades as well and two lessons:

1) Never act like you're smarter than other developers. This is an industry with a lot of incredibly smart people and with a thousand different ways to solve every problem. There is no right way to do anything. Just the best effort given the cards you are dealt.

2) Anyone who has been involved in re-platforming knows how traumatic, destructive and error-prone it is. Statistically most are a failure. That is why so many developers don't gravitate towards your approach of building a basic architecture and then building something scalable later. They try to do it all in one go. And especially for startups where everyone goes into it assuming they will be building the next Google or Netflix.

Good points, and I agree. I think what bothers me is that a lot of the advice you might read out there is biased towards what you should build if you already had hundreds of employees and millions of users. Sprinkle in a bit of incentives from cloud providers, and you end up with a world where it only seems reasonable to start out with a Kubernetes cluster or multiple distributed communication systems from the get-go. I do think a lot of developers would intuitively start out with a much simpler system, but it almost looks wrong if you do. But it's not wrong, you can't predict the future so if you try to predict and set up your infrastructure for future success, "just in case", you'll still have to re-platform it, as you say.

I should add that some form of re-platforming is pretty much inevitable at some point in the lifetime of a business no matter which approach you take. Because infrastructure is informed by the structure of your organization as much as the needs of your product. If your number of engineers increases by a couple of orders of magnitude, it's likely any infrastructure you set up will need to reshape to account for that.

>Every business sooner or later will need to create more distributed systems

In real, most businesses won't survive till that, even that will survive can go a long way with a high latency service with a single deployment. A well-designed monolith will take to 10s of millions of DAU from across the world. Worst case you'll add 2-300ms of latency to your call, but if you look around most popular and successful of enterprise software have more than that and people are "happy" using them.

Premature optimization is the root of all evil

Reply on news.ycombinator.com