> The only downside thing is that it's truly tough to figure out how to point your domain to s3.

It should be fairly straightforward. In fact I just did it this morning. What issues did you run into? One tricky part that a lot of people miss is that you have to choose Alias: res in the record set properties.

I've created the route53 zone and pointed the nameservers using the route53 provided ones, made sure s3 bucket serves pages and the folder name is same as the domain, but when I run diagnosis everything comes back fine. Yet my domain just throws ERR_CONNECTION...I don't know it was frustrating because I think I followed the instruction a few times now and was far too difficult. Equally horrid is gandi.net's user interface for mangaing DNS records....

What's the domain name?

Infinite scalability is all party until you get DDoSed and have to sell your house to pay the bills. How do you prevent that? Cloudfront maybe?

not too worried because amazon seems pretty generous but no need for cloudfront, the API gateway itself handles DDOS. A lot of times I find this to be a needless worry because the only time you are going to get DDOSed is if you piss some script kiddies or you are big enough on a competitors radar.

Didn't know about API gateway, so it's all good then. Also I meant to say "Cloudflare".

API Gateway has DDoS protection.

A nitpick: Calling AWS Lambda serverless is like when Salesforce called their software "no software" (back when SaaS was new). It's a nice marketing message but don't you think we're a bit above it here at HN? Of course there's a server, just not a Linux VM that you need to sysadmin by hand.

I mean, really how much is Lambda more serverless than Heroku has been for years?

I disagree.

With Lambda, you're not getting a server. No OS setup, no ip-tables, no weird compile errors, and no 5am pagers. You're paying for code to run.

With Salesforce, you're not getting software. No installation, no packaging, no purchasing updates. You're paying for your team to centralize information.

While I despise Salesforce for many reasons, it was a game-changer in the way enterprises thought about cloud software. GP's point was a similar mental shift in how we write that software.

I don't think "not getting a server" is enough justification. With Gmail I don't get a server, but nobody calls it "serverless email". A server is still involved.

It seems like an ill-fitting adjective even in a vacuum, but what's worse is that "serverless" is commonly used to describe something that runs entirely client-side (e.g. p2p).

Just because AWS Lambda is a "mental shift" doesn't mean that "serverless" is a good way to describe it.

Server-less is probably nomenclature that needs to be phased out like "Application Service Provider" or "CORBA." It focuses too much upon the implementation rather than the value. The value of not having a "server" in most cases is that you don't have to operationally manage a new host and incur all the cost of ownership of managing more infrastructure that does not directly add value to your business. Perhaps if you're pretty efficient it is better to take this on yourself, but for most companies the trend is accelerating against infrastructure management since most companies are decidedly not experts in managing compute, storage, and networks - I've seen a lot of places in the Fortune 500 and they are inefficient and ineffective at managing their IT as a rule because IT is a cost center normally.

As for a better term, perhaps operationally-opaque or "pure service" are starting points? Service is correlated with stronger federation while p2p is decentralized as a rule. I'd rather avoid SOA which does not say anything about whether you have to manage the operations or dependencies - nobody is calling microservices as "server-less" after all. When people in companies talk about a "services" company they mean that the labor and overhead of management are all outsourced and as a customer you don't really care about how they operate as long as they don't violate certain OLAs and SLAs. AWS can run Lambda on marmot-based computing on Mars for all I care as long as it meets certain specs. Services compete on cost, SLAs (features are part of SLAs), and OLAs, period.

Others have pointed out that it is serverless from the service-owner's point of view. I think that is a important point.

But there's another interesting thing that is relevant here. Because it is stateless, it it really is "serverless" in the sense of there being a single server associated with your code.

They really could run it in disposable VMs ZeroVM[1] style.

[1] http://www.zerovm.org/

Isn't Lambda more serverless than Heroku because there is no concept of Dynos?

Fortunately, I don't have to worry and I leave that up to competent Amazon engineers. But yes, I didn't have to spin up any droplets or ec2 or worry about any of the layers involved with traditional server client development so the experience has been serverless for me. I'm well aware lambda runs on Amazon's servers :)

Not having to worry about anything else except the code opens other doors.

> It's nice to know there's not a server anywhere.

To be clear AWS is running thousands of servers that make up Lambda, DynamoDB, S3 and friends. It's still fair to call Lambda "serverless" because you don't have to deal with any servers... but saying there are no servers anywhere is false.