Hacker News new | past | comments | ask | show | jobs | submit login

As if boring architectures don't have their own problems.



Such as? Besides of course not being able to find people that want to work on it.


IDK, I'm assuming "boring" here means stateful monolith?

So you have:

a) No enforceable isolation, reliance entirely on good behaviors and module systems

b) No independent scaling

c) No isolation of security components so instead of a minting service and an edge service you have one service that does both

d) Single language lock-in

I could go on and on an don


Boring architectures generally don’t scale well


I usually find that "interesting" architectures scale even worse, at least for the 99% of projects and organizations that'd never actually outgrow the "boring" solution. All the pain of the big fancy solution, but without the actual need that makes it truly better than the alternative.

... of course, the best-paying jobs are at the places that really do need that scale, so of course we all want an excuse to play with those tools, even when it's not the right business choice. And it's not as if software folks are the only ones with a principal-agent problem, in business. Oh well.


I'm with you. I understand the critique, but experience has shown me "boring" is more maintainable, and at some point even "clever" tools stop being worth the effort. Besides, eventually scale pushes tech to roll their own, or rewrite/augment tools.

I dislike using boring as a measure of sufficiency. It makes me wonder if those drawn to the clever solutions carry a "I know better than you" perspective, the kind of dogmatic optimism that tanked SVB.


Define "boring" and "scale", because in my experience you can vertically scale hardware to an almost unbelievable number of concurrently logged-in users.

With most services, until you go over a few million users concurrent users, you really don't need to horizontally scale.


Being boring has nothing to do with scale. Some of the biggest applications run on incredibly simple architectures, and often are able to scale so well because of that (boring) simplicity.


Cassandra is probably in the realm 'boring and scalable'


Definitely not. I'd much rather scale Postgres manually through layers of sharding and proxies than handle Cassandra.

There is ScyllaDB for a much better reimplementation of Cassandra/Dynamo, but wide-column databases are still best for niche scenarios, especially as RDBMS are rapidly evolving into natively distributed architectures.


What are the biggest apps on the simplest architectures and what are the architectures?


Monolithic apps running on big servers talking to databases running on big servers. Very little orchestration overhead or complexity with serverless and the rest.

Everything from StackOverflow to ad serving systems to high-frequency trading exchanges are run this way.


Stack overflow is unique in that it’s most read only. Link to high frequency trading “boring” architecture?


What is your definition of non-boring architecture? I'm curious as to what you consider the exciting architectures necessary for scaling to make sure we're talking about the same thing.

Quora, Pinterest, Twitter, etc are all just big app instances talking to DB instances, with separate systems for background processing, queues, and caching. Are you suggesting that they would scale better with serverless functions instead?

Here's a list of architectures: http://highscalability.com/all-time-favorites/


I do not consider any of your examples really that simple or boring.

Boring to me is a load balancer, app server and cache. Once you start talking about background jobs and queues I don’t see how that’s any simpler than the alternative.

You could say Google, running Borg, is basically a database with a bunch of load balancers and background job processors. Obviously the complexity is in the scale and implementation.


Ironic that this page is down? (also not https? heh)


Stack Overflow is probably one of the more public examples. That is mostly a C# monolith with a relational database behind it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: