5 ms·

I think the argument is different. Let's say you use a basic HTML Golang app backed by SQLite and replicated to a secondary with Litestream, all running on che

by strken 4y ago

I think the argument is different. Let's say you use a basic HTML Golang app backed by SQLite and replicated to a secondary with Litestream, all running on cheap bare metal ARM servers, and therefore your website is simple, usable, never goes down, and costs $20/month to run. I have no idea if this is actually good, but let's agree that there's some idealised system out there that would be a lot better than what we have now, even if it doesn't look like this one. Let's also say I use React and Redux backed by a CQRS Express app running on MongoDB and Kafka, all hosted on AWS, and (for the sake of the argument) let's say this causes my website to be broken in bizarre ways, down all the time, and costs $2000/month to run. This is definitely an exaggeration and some of these technologies are great, but let's agree that there are some hellishly over-engineered systems out there, even if they don't look like this one. I think the argument is that what matters here is having an example of a $20/month uncomplicated beautiful system to point to. Discussing the technologies or patterns involved without building anything and especially without building a complete working product with your favourite elegant tool means everyone will use the broken $2000/month system as an exemplar in your field, because they have nothing better to point to.

hdjjhhvvhga 4y ago
> because they have nothing better to point to. Well - they do. For example, HN is running on a simple bare metal machine, with another one waiting for emergency.
- strken 4y ago
  Yep! Good example.
- dist1ll 4y ago
  Do you have a source for that?
  - hdjjhhvvhga 4y ago
    https://news.ycombinator.com/item?id=31821904 https://news.ycombinator.com/item?id=31821904
- ratww 4y ago
  And the fun part is that traffic coming from HN routinely causes websites to crumble under load.
simonh 4y ago
>Discussing the technologies or patterns involved without building anything and especially without building a complete working product with your favourite elegant tool.... But surely, if anywhere, this is the place to talk to people who have built complete working system, are building them, and intend to build more of them. This isn't a forum for a bunch of undergrads chatting about stuff they just learned in college. I'm sure there are some of those here, but if you're going to find seasoned web engineers anywhere, this is a good place to start. > Let's say you use a basic HTML Golang app backed by SQLite... therefore your website is simple, usable, never goes down. That's a complete non-sequitur. If the app becomes hugely popular, needs to serve massive volumes of data and sync across thousands of instances, well, it won't. You can't say that because it uses simple tech therefore it will be wonderful, that's not how that works. There are use cases where the MongoDB + Kafka thing will work much better. That's what these discussions are about.
- ratww 4y ago
  > If the app becomes hugely popular, needs to serve massive volumes of data and sync across thousands of instances, well, it won't This argument is so overused for justifying any kind of complexity that it would border on comical if it weren't causing so many issues in our industry. There is absolutely no guarantee that the MongoDB + Kafka will also work with the hypothetical "massive volumes of data" you're talking about. Those two tools aren't set-and-forget: they require fine tuning and a good architecture to begin with. Ironically, I've seen plenty of cases where MongoDB couldn't handle the production load and had to be put behind some Varnish or Nginx disk cache (ironically bringing it closer to the SQLite app example). But we don't even have to go that far: depending on the situation, there is a huge chance that the hypothetical app won't see "massive amounts of data" anyway. And if it does, there's an also massive chance that it won't happen overnight, so there will be time to build more. And if we get there, the SQLite app can just be bumped up to PostgreSQL or something similar, which scales vertically beautifully, or some other relational DB that scales horizontally.
  - simonh 4y ago
    Right, but if you're scaling it up to meet changing requirements, well, that's now a different use case. How do you do that scaling up effectively? That's where discussion here comes in. I'm not at all arguing that you need MongoDB and Kafka, those are not my examples, but pretending that SQLite and plain HTML are the be-all, end-all is bizarre. OK, you're a big fan of PostgreSQL. Cool. Now we're talking. In what situations and why is a useful discussion to have. That's grounds for fertile and relevant architectural debate, and here is a good place to do that. Arguing that isn't the case is, well, ok... problem solved then. I suppose there's not much more to talk about.

by strken 4y ago

hdjjhhvvhga 4y ago

> because they have nothing better to point to. Well - they do. For example, HN is running on a simple bare metal machine, with another one waiting for emergency.

strken 4y ago
Yep! Good example.
dist1ll 4y ago
Do you have a source for that?
- hdjjhhvvhga 4y ago
  https://news.ycombinator.com/item?id=31821904 https://news.ycombinator.com/item?id=31821904
ratww 4y ago
And the fun part is that traffic coming from HN routinely causes websites to crumble under load.

simonh 4y ago

>Discussing the technologies or patterns involved without building anything and especially without building a complete working product with your favourite elegant tool.... But surely, if anywhere, this is the place to talk to people who have built complete working system, are building them, and intend to build more of them. This isn't a forum for a bunch of undergrads chatting about stuff they just learned in college. I'm sure there are some of those here, but if you're going to find seasoned web engineers anywhere, this is a good place to start. > Let's say you use a basic HTML Golang app backed by SQLite... therefore your website is simple, usable, never goes down. That's a complete non-sequitur. If the app becomes hugely popular, needs to serve massive volumes of data and sync across thousands of instances, well, it won't. You can't say that because it uses simple tech therefore it will be wonderful, that's not how that works. There are use cases where the MongoDB + Kafka thing will work much better. That's what these discussions are about.

ratww 4y ago
> If the app becomes hugely popular, needs to serve massive volumes of data and sync across thousands of instances, well, it won't This argument is so overused for justifying any kind of complexity that it would border on comical if it weren't causing so many issues in our industry. There is absolutely no guarantee that the MongoDB + Kafka will also work with the hypothetical "massive volumes of data" you're talking about. Those two tools aren't set-and-forget: they require fine tuning and a good architecture to begin with. Ironically, I've seen plenty of cases where MongoDB couldn't handle the production load and had to be put behind some Varnish or Nginx disk cache (ironically bringing it closer to the SQLite app example). But we don't even have to go that far: depending on the situation, there is a huge chance that the hypothetical app won't see "massive amounts of data" anyway. And if it does, there's an also massive chance that it won't happen overnight, so there will be time to build more. And if we get there, the SQLite app can just be bumped up to PostgreSQL or something similar, which scales vertically beautifully, or some other relational DB that scales horizontally.
- simonh 4y ago
  Right, but if you're scaling it up to meet changing requirements, well, that's now a different use case. How do you do that scaling up effectively? That's where discussion here comes in. I'm not at all arguing that you need MongoDB and Kafka, those are not my examples, but pretending that SQLite and plain HTML are the be-all, end-all is bizarre. OK, you're a big fan of PostgreSQL. Cool. Now we're talking. In what situations and why is a useful discussion to have. That's grounds for fertile and relevant architectural debate, and here is a good place to do that. Arguing that isn't the case is, well, ok... problem solved then. I suppose there's not much more to talk about.