In a billing sense, since you're not paying for a provisioned server. You only pay for the time your request is executing and your storage in S3.
In the monitoring sense, since Amazon is responsible for monitoring the servers and infrastructure that your application runs on.
In a security sense, since Amazon is responsible for installing security updates, using the appropriate SSL cipher suite and sandboxing your code so that a vulnerability turn the server into a part of a botnet.
In a scaling sense, since you're not responsible for provisioning more servers should you get the hug of death from having your site posted here.
A server is more than just a computer hooked up to the internet. It's a set of responsibilities, limitations and costs that you have to stay on top of. A "serverless" application has far fewer responsibilities and limitations and a completely different cost structure. It's not right for everyone, but it is a fundamentally different way of architecting your application.
because you don't have to provision the server yourself, and get access to one process.
so you wind up with a lot of processes across servers and virtual servers everywhere, but that is colloquially called serverless. Especially if your serverless collection of servers use javascript.
Servers running javascript are called "a dumb idea". But that's neither here nor there - The core idea of "Serverless" is that you don't have stateful physical machines that you manage, only a series of processes - which can live just about anywhere, with only clearly defined interfaces to shared state.
> a series of processes - which can live just about anywhere, with only clearly defined interfaces to shared state.
So, a server with an API. Gotcha.
Edit: downvotes? how is what he is describing any different to that and anything else other than a buzzword? Doesn't AWS Lambda just run your processes in an ec2 instance?
> Edit: downvotes? how is what he is describing any different to that and anything else other than a buzzword? Doesn't AWS Lambda just run your processes in an ec2 instance?
Yes but you don't pay for the hardware specifically, eg. Your code doesn't care when underlying lambda hardware fails because it's not contained within any specific server. You pay for the invocation costs which are usually much lower than running a server to do the job as you're gaining economies of scale with other tenants.
You need to "feel" the serverless nature of it. It's an inner feeling - a bit like faith.
If someone says it's serverless then it IS serverless!- that is the nature of all serverless systems.
Unless of course we're talking about Amazons serverless systems - those really are serverless - nothing there at all but strange quantum forces that create responses to HTTP requests.
They might call it "serverless" for that reason, just like someone might say they drove to work "carless" by carpooling with a coworker, but it's a little misleading.
Doesn't matter. Driving and carpooling both imply the use of a car. Uploading denotes a server at the receiving end, even if it's a dynamically-provisioned transient server uploading into some cloud data store.