4 ms·

> if there's a sudden influx of thousands of users A $10 VPS will manage thousands of users fine for most CRUD apps. You don't need tons of VM. You can always

> if there's a sudden influx of thousands of users A $10 VPS will manage thousands of users fine for most CRUD apps. You don't need tons of VM. You can always make it a... $20 VPS to have some margin if you fear HN hug of death. You won't get a CDN close to the user or automatic backup, but that's really fine for the immense majority of projects. It takes one hour to setup a VPS with nginx, python/node/ruby and postgres. Then it mostly runs on its own for years: no coldstart problem, no kubs to manage. I get the benefit of the cloud at scale, but for thousands of users, it seems really overkill.

jeroenhd 5y ago
It depends on what the code is actually doing, but you're not wrong in most cases, especially the HN hug of death. I host all of my stuff on cheap VPS servers for example. Some tasks, though, are just terribly slow. For example, crawling a webpage and taking a screenshot of it sounds incredibly easy but turns out to involve a lot of resource-intensive moving parts. The most common solution I see involves running Chrome in a container and taking a screenshot. That kind of code can easily overwhelm even a moderately expensive VPS with just a few clients. On the other hand, most CRUD stuff and frontend-heavy applications would run fine even off a modern Raspberry Pi. You can't just let something run, though, because you need to manage system updates. It's something you can easily forget if you have tons of other stuff to do, so the laziness factor also helps defend the *aaS setup. I don't like serverless, I think it's the next step in more wasteful programming by people who can't or don't want to understand the systems underlying their code. We're at the point where shipping an entire operating system along with an application has somehow become the norm, and I don't like the fact that eventually I too will need to learn this serverless crap.
- BiteCode_dev 5y ago
  > It depends on what the code is actually doing Indeed, things like video encoding, machine learning, graph traversal, etc, can be pretty expensive. But then again, our tooling are so powerful these days you can get away with a lot. Timeseries ? Clickhouse is your friends. Need geo calculations ? PostGis is here. Need to extract frames from a video ? ffmpeg will do that in a few cpu cycles. Data analysis ? Say hello to pandas. Validation, caching, expiration, encryption, workflow, pub/sub, logging, reporting... We have amazing solutions for everything that will let you scale up to the millions of users for few hundred dollars. In your example with the screenshots, one can imagine putting them in a queue (5 minutes setup with python-rq + redis) or even more low tech, a cron, and suddenly your VPS can take one screenshot every 2 seconds, which is 43200 in a day. That's a lot of screenshots. Your client need the screenshot immediately ? The browser can take a screenshot from JS with html2canvas. Sometimes it feels we are using $TECH because there is a whole class of devs that can't find solutions to problems: - don't want to think about your data structure ? Put everything in no sql. - don't want to think about your deployment ? Put everything in a container. - don't want to think about your algo ? Put everything in the cloud. Of course, in the end, you still have to think about all that no matter the tool you use. You just moved the cost somewhere else, usually paying much, much more later. In fact, even most of the stuff I get paid to do using Django could be done cheaper with wordpress. I'm already overkilling it.
- numpad0 5y ago
  I think the problem is in a general overcomplexity, ambiguity, configuration overflexibility and lack of reliability with LAMP or Node or Python or GNU/Linux installations. Today I just can’t make a guarantee for a fresh Ubuntu LTS instance that it will run a 15-line pure C or sh code as I would intend to outside of my attendance, regardless of how easy the requirements or the SLA might be. As much as I hate serverless or easy scripting language trends, they do the job and do it well.
  - deleted 5y ago
    [deleted]
jbergens 5y ago
It probably depends a lot on what the code is doing . I've seen systems with multiple services inside and a couple of them had to do db calls and could not be cached. You can easily end up with 10-30 servers. Also, the cheap versions may not have enough cpu or memory for all systems. In this case the serverless versions may be better, easier or cheaper. We did not use Python or Ruby by the way. I still think Python is a bad choice for most systems.

jeroenhd 5y ago

It depends on what the code is actually doing, but you're not wrong in most cases, especially the HN hug of death. I host all of my stuff on cheap VPS servers for example. Some tasks, though, are just terribly slow. For example, crawling a webpage and taking a screenshot of it sounds incredibly easy but turns out to involve a lot of resource-intensive moving parts. The most common solution I see involves running Chrome in a container and taking a screenshot. That kind of code can easily overwhelm even a moderately expensive VPS with just a few clients. On the other hand, most CRUD stuff and frontend-heavy applications would run fine even off a modern Raspberry Pi. You can't just let something run, though, because you need to manage system updates. It's something you can easily forget if you have tons of other stuff to do, so the laziness factor also helps defend the *aaS setup. I don't like serverless, I think it's the next step in more wasteful programming by people who can't or don't want to understand the systems underlying their code. We're at the point where shipping an entire operating system along with an application has somehow become the norm, and I don't like the fact that eventually I too will need to learn this serverless crap.

BiteCode_dev 5y ago
> It depends on what the code is actually doing Indeed, things like video encoding, machine learning, graph traversal, etc, can be pretty expensive. But then again, our tooling are so powerful these days you can get away with a lot. Timeseries ? Clickhouse is your friends. Need geo calculations ? PostGis is here. Need to extract frames from a video ? ffmpeg will do that in a few cpu cycles. Data analysis ? Say hello to pandas. Validation, caching, expiration, encryption, workflow, pub/sub, logging, reporting... We have amazing solutions for everything that will let you scale up to the millions of users for few hundred dollars. In your example with the screenshots, one can imagine putting them in a queue (5 minutes setup with python-rq + redis) or even more low tech, a cron, and suddenly your VPS can take one screenshot every 2 seconds, which is 43200 in a day. That's a lot of screenshots. Your client need the screenshot immediately ? The browser can take a screenshot from JS with html2canvas. Sometimes it feels we are using $TECH because there is a whole class of devs that can't find solutions to problems: - don't want to think about your data structure ? Put everything in no sql. - don't want to think about your deployment ? Put everything in a container. - don't want to think about your algo ? Put everything in the cloud. Of course, in the end, you still have to think about all that no matter the tool you use. You just moved the cost somewhere else, usually paying much, much more later. In fact, even most of the stuff I get paid to do using Django could be done cheaper with wordpress. I'm already overkilling it.
numpad0 5y ago
I think the problem is in a general overcomplexity, ambiguity, configuration overflexibility and lack of reliability with LAMP or Node or Python or GNU/Linux installations. Today I just can’t make a guarantee for a fresh Ubuntu LTS instance that it will run a 15-line pure C or sh code as I would intend to outside of my attendance, regardless of how easy the requirements or the SLA might be. As much as I hate serverless or easy scripting language trends, they do the job and do it well.
- deleted 5y ago
  [deleted]

jbergens 5y ago

It probably depends a lot on what the code is doing . I've seen systems with multiple services inside and a couple of them had to do db calls and could not be cached. You can easily end up with 10-30 servers. Also, the cheap versions may not have enough cpu or memory for all systems. In this case the serverless versions may be better, easier or cheaper. We did not use Python or Ruby by the way. I still think Python is a bad choice for most systems.