101–110 of 174 posts
Earlier quoted context omitted.
VPSs being “easy to manage” is a strong option full of assumptions.
a basic bitch static website takes three commands in the terminal and a very basic nginx config file to setup on a completely fresh ubuntu VPS. you could read a guide from 2012 and it would work perfectly fine. is this harder than dealing with cloud 'platforms' and their ever-changing UIs, APIs, SDKs?
Earlier quoted context omitted.
I won't run a VPS. I'm entirely capable of doing it. Badly. I'm a mediocre Linux admin, at best. The current environment is so dangerous, these days, that it's worth your life, to have your essential services run by a mediocre admin; even if I can convince myself that I'm the best (spoiler: I'm not). I'll generally run shared hosting, or managed servers.
I can't speak for you, but it's really not too difficult to host some static content on a VPS. At the very worst, the VPS is compromised somehow, and you refresh it from the admin panel.
Earlier quoted context omitted.
I'm not talking about static content. I need the whole enchilada: DB, Web Server, Dynamic Languages, etc. Also, for a shipping, production application, with hundreds of users; where privacy and security are of paramount importance. It's easy, sure. It's easy to create an insecure server, that can be pwned. I know of which I speak. I have done just that. "A man who holds a cat by the tail, learns a lesson he can learn…
It's easy to create a secure server. Use private keys. Use a firewall (ufw is really simple) and only expose your reverse proxy (e.g nginx or haproxy). Use docker to run your crap. Any software engineer should be well capable of setting up a secure server. It really is simple.
Earlier quoted context omitted.
true. At what point could you say they are accomplices to the attackers
Ah the Yelp biz model: "would be a shame if somebody read a bad review about your biz, pay us to remove it" to Netlify "would be a shame if somebody DDOS'd your serverless website, subscribe to our DDOS protection plan"
Earlier quoted context omitted.
You can totally build a GCP function that will tear down your site if a billing alert hits the pubsub bus, but you can also set billing caps for a bunch of the APIs.
Why not add it directly into the interface where you configure the site to begin with? It's a pretty reasonable ask.
It's probably easier to make it so they can set up alerts and have a human on their end evaluate what steps are worth taking to cut costs while maintaining important availability.
Earlier quoted context omitted.
I remember a comment from this site. Something like: we must study how Amazon and other big cloud's marketing work so great to make this generation developers think that vps or selfhosting are hard. IMO vps was easy before and even easier now to manage.
Please explain how you rotate ssh keys, store audit logs, backup (and test backup procedures), configure secure network between vpses such that your neighbor cannot eavesdrop.
- you add your ssh public key to the hosting provider, so any new VM will have it automatically
- you use the snapshot service of your hosting provider for backups. If you have a database, run a cronjob that dumps it so it's in the snapshots as well. Alternatively use any backup tool to backup files to somewhere else
- you do not need a separate network for simple use cases. Just encrypt traffic if you have multiple servers, odds are you only have one here anyway.
I agree with the consensus here that the cost issues are a cloud problem, not serverless. Ironically, something like AWS lambda has a default 1,000 simultaneously activated lambda limit, so the platform defaults to throttling. Not that serverless is perfect.
I have seen AWS Lambda generate large bills even with the 1000 concurrent executions limit, but with the help of upstream services. My memory of it is hazy, but I think over a weekend, a function with some dodgy retry logic managed to generate something like 21TB of CloudWatch logs.
Earlier quoted context omitted.
Why not add it directly into the interface where you configure the site to begin with? It's a pretty reasonable ask.
It's probably quite difficult to boil it down to something as simple as an "off" switch that'll limit costs for them, meaningfully work for all services, not be abused, not be confusing, and not result in the customers that actually make you money accidentally getting important things shut off unexpectedly under predictable circumstances. It's probably easier to make it so they can set up alerts and have a human on t…
Earlier quoted context omitted.
a basic bitch static website takes three commands in the terminal and a very basic nginx config file to setup on a completely fresh ubuntu VPS. you could read a guide from 2012 and it would work perfectly fine. is this harder than dealing with cloud 'platforms' and their ever-changing UIs, APIs, SDKs?
Yes, this is harder. I don’t want to mess with maintaining or configuring nginx.