| > but the selling point of serverless functions isn't the "functions" part, it's the "serverless" part. Yup. That's right. The removal of the server from your application is the selling point. As you subtly hint at, exposing the application as a "function" is a clever API design to facilitate that, but I'm sure you could imagine other ways to achieve the same. It is the "serverless" part that is significant. HTTP servers, while simple to implement in terms of basic function, aren't easy to design well. There are a lot of more complex considerations, like around security and scaling, which are easy to screw up if you don't have a good handle on what you are doing. All alleviated by just letting someone else, who specializes in it, write the server code for you. If you take the server out of your application, making it "serverless", it becomes much more difficult (I really want to say impossible, but abstractions always leak eventually) to screw that end up. Which is a very compelling business case, allowing businesses to hire people who aren't experts (read: cheaper) in the intricacies of low level technical details that are outside of their core business logic. That's the selling feature, just like you (and Amazon) say. Glad we got away from that bizarre definition thinking that "serverless" somehow takes physical hardware out of the picture. Maybe it has also taken on that meaning (as nonsensical as that idea is) through the twisting in the popularity wind – definitions are most definitely influenced by time — but it certainly didn't originate in that vein. |