News for hackers. Stuff that matters.
Re:Serverless Databases: The Future of Event-Driven Architec... by amarkov on Wednesday February 14, 2018 @04:00PM (#16379323)
It seems like a pretty good name to me. The point of the term "serverless" is that you aren't presented with any abstraction of a server; operations like "spin up more servers to handle the load" or "SSH to the server to figure out what's going on" or "reboot the server because it's acting weird" don't exist for you.

The term does get abused to refer to any server cluster with a bit of autoscaling logic, and in that sense it is a misnomer. But I don't think that's what it originally meant.

Re:Serverless Databases: The Future of Event-Driven Architec... by styfle on Wednesday February 14, 2018 @06:13PM (#16380455)
But didn’t we already have this concept with Platform-as-a-Service (PaaS)?

What you described sounds like Heroku, Azure Apps, etc.

Re:Serverless Databases: The Future of Event-Driven Architec... by amarkov on Wednesday February 14, 2018 @07:19PM (#16380874)
In many simple cases, Heroku is effectively serverless. But there are situations (in particular monitoring and billing) where you're forced to think about the individual dynos your app is running on.
Re:Serverless Databases: The Future of Event-Driven Architec... by hueving on Thursday February 15, 2018 @02:33AM (#16382443)
No, it's a terrible name because your definition implies that VMware or EC2 instances would be servers since you can SSH into both. A significant portion of ops people would never refer to a VM as a server so you've already run into big problems.

Then there is the problem of who it is 'serverless' for. If the developers use a lambda like service hosted by their own org in their datacenter (operated by separate ops people), is it still serverless? If so, then it has nothing to do with actual servers and it's all about making operating system runtime specifics transparent. If not, then it's just a marketing term for letting Amazon or Google run your company's hardware.