I don't get the faux-naivety over the term "serverless". Most modern cars have "keyless" unlocking and ignition, yet.. you still need a key present. You just don't have to think about or manipulate the key. Serverless is much the same.
Probably this means that there is no server you can SSH to nor need to maintain.
It could probably be called a serverhostage/server-lock-in computing, where someone else keeps the _shared_ server(s) away from you and runs other people's, potentially harmful, instructions as well :-)
Ok, so "serverless" is just a buzzword that doesn't really have a good meaning. That's doesn't really matter. To me it's just easier and actually meaningful and objective to refer to services like AWS lambda as "Function as a Service".
It is in the cloud. It's different in that you don't have access to the cloud server, just a service on it.
To me it's like having one hand tied behind your back while someone else uses their hand to do what you'd have done with the one tied behind your back. It's cheaper, sometimes it works the way you want it to, but you always feel a bit restricted.
> It's cheaper, sometimes it works the way you want it to, but you always feel a bit restricted.
The "cheapness" argument is open to debate. So far the main argument I've seen for Function-as-a-Service offerings is that it's cheaper than just paying for a VM instance to run a dedicated service. To start off, a dedicated VM can cost about 5€ a month, which represents the absolute total saving that is supposed to be driving this discussion. Even if we ignore this fact, if you already have VM instances running somewhere then you certainly have enough computing capacity to spare to run these compute tasks without having to incur in extra charges per function call.
a VM can cost far less then $5 a month to run, depending if your bussiness is large enough and can run (or have it run for you) its infra properly.
I once did some simple estimation of a cost of a VM inside our own infrastructure, and the costs was something around a euro or less.
A single, modern server can hosts a crapton of VM's, especially if you have a competent operations team inside your bussiness who builds tooling for it.
The less pessimistic interpretation is that it's like having someone else be your devops department. Unlike what people like to think, most people running traditional VMs and containers end up doing just as much devops as on a dedicated server (while doing consulting, I'd typically get more hours at higher rates out of people insisting on AWS, because getting an AWS setup right is a lot of work), so serveless is appealing as a way of making more of the devops stuff someone elses problem.
I get your feeling - I like to be able to ssh in as well, but then I see people I've worked for, and realise that to most of them having ssh access does no good, because they don't know how to troubleshoot over an ssh connection, and they don't want to have to know.
To them, losing that flexibility doesn't really matter, because they weren't doing it anyway.
It's more than SSH access that you give up though. You have to bend to the paradigm completely or you're really fighting against it.
For one example, I keep running up against wanting to delay an execution of one lambda from another. There are some truly horrible hacks out there to try and achieve that.
Absolutely. Frankly I think in a few years time we'll look at Lambda the way we look at people dumping php scripts on a shared server today. It needs a lot of thinking before serverless fulfills its long term potential in those respects.
The irony is that a whole lot of the solutions are well understood; just not in the same environments. E.g. "enterprise" computing went through a whole cycle of building application services for small self-contained components with discovery and messaging in the late 90's that people seem to have largely forgotten as somewhere to look to at least for a laundry list of what kind of services are needed.
When you are “running it in the cloud” with a traditional VM you still have a server that you can log into, that’s always running, requires patching and if you get a spike, you have to set up your own scaling policies and it will usually scale more slowly.
>...so, there is a server? What's with the name, then?
The name is just a marketing gimmick. Absent any other context, "serverless" seems like it must be a paradigm shifting technology so sufficiently advanced that it renders servers obsolete, as if by magic.
It's the same sort of trick that people sometimes pull when they show off an application to "do x in 10 lines" (or some absurd low number), when the app is just making API calls to a remote server running several million LOC.
It's an annoying marketing term, sure enough, but the ideas it names aren't terrible. It's not always a mistake to pay someone else to take care of maintenance, scaling and security.
It’s more than just a managed service. RDS is Amazon’s managed database cloud service, but you still provision and pay for a specific virtual server with a certain number of CPUs and amount of RAM. “Serverless” generally implies that you do not provision any server hardware (even virtual) and instead only provide application code.
I’m no expert, but I think you run RDS on an EC2 instance, so it’s basically just a normal virtual server running Amazon’s managed version of the RDBMS. I’m not sure what happens if an instance “fails” but I assume you can have downtime if Amazon needs to move your VM, just like EC2, but I assume Amazon handles moving the instance and restarting it.
> I think you run RDS on an EC2 instance, so it’s basically just a normal virtual server running Amazon’s managed version of the RDBMS
Yes I think that's right. That is to say, it doesn't give you replication.
> I’m not sure what happens if an instance “fails” but I assume you can have downtime if Amazon needs to move your VM, just like EC2, but I assume Amazon handles moving the instance and restarting it.
No need for the quotation marks, that's the correct terminology. Your suspicions seem to be right on - it looks like RDS handles instance-failure for you, with non-trivial downtime, but no data-loss. [0]
> Serverless computing is a cloud-computing execution model in which the cloud provider runs the server
...so, there is a server? What's with the name, then?