3 ms·

It's just semantics, point is, you don't have to worry about spinning up servers, provisioning them, or maintaining them; just write code.

by HammadB 10y ago

partycoder 10y ago
Write code to run on? a server.
- blowski 10y ago
  Call it whatever you want, but I like to use the language of those who hold the purse-strings. If they call it "serverless", then I call it "serverless". If delivering a lecture about why it's not really serverless improves your product, then go ahead and deliver that lecture, but I doubt it will.
  - partycoder 10y ago
    Involves a server listening on a port, running on infrastructure that you indirectly pay. Not in the air, on a server. It is a very misleading term. Especially for non-tech savvy. Sounds like a scam. It's like calling being passenger on a car "wheel-less transport", because I as passenger don't have wheels.
    - blowski 10y ago
      A driverless car has a driver, it's just not a human driver. A serverless architecture has servers, but you never see or need to think about them. Don't get hung up on the name. Bananas are not a fruit, but it's fine to put them in a fruit salad.
    - inopinatus 10y ago
      It's more like driverless cars. Something clearly is driving the car, but it isn't you. Moreover the fact it's even a car is now an implementation detail. It could just as well be a motorised shipping container that slots into a hyperloop when it reaches the station. The assumption that the AWS Lambda infrastructure is server hardware is just that - it may not be true now, and you could build a function-as-a-service platform out of a massive array of Raspberry Pis and it'd still have solid at-least-once invocation semantics. And I'm repeating this, but you're flat wrong about the listening server-on-a-port. AWS Lambda functions are bound to queues and receive events. The closest you'll get to having a socket-on-a-port is that the provisioning API has a REST endpoint. So if it isn't necessarily server hardware, and there's no server endpoint to connect to, that "hate" you started this thread with looks rather misplaced.

It's just semantics, point is, you don't have to worry about spinning up servers, provisioning them, or maintaining them; just write code.

by HammadB 10y ago

It's just semantics, point is, you don't have to worry about spinning up servers, provisioning them, or maintaining them; just write code.

partycoder 10y ago

Write code to run on? a server.

blowski 10y ago
Call it whatever you want, but I like to use the language of those who hold the purse-strings. If they call it "serverless", then I call it "serverless". If delivering a lecture about why it's not really serverless improves your product, then go ahead and deliver that lecture, but I doubt it will.
- partycoder 10y ago
  Involves a server listening on a port, running on infrastructure that you indirectly pay. Not in the air, on a server. It is a very misleading term. Especially for non-tech savvy. Sounds like a scam. It's like calling being passenger on a car "wheel-less transport", because I as passenger don't have wheels.
  - blowski 10y ago
    A driverless car has a driver, it's just not a human driver. A serverless architecture has servers, but you never see or need to think about them. Don't get hung up on the name. Bananas are not a fruit, but it's fine to put them in a fruit salad.
  - inopinatus 10y ago
    It's more like driverless cars. Something clearly is driving the car, but it isn't you. Moreover the fact it's even a car is now an implementation detail. It could just as well be a motorised shipping container that slots into a hyperloop when it reaches the station. The assumption that the AWS Lambda infrastructure is server hardware is just that - it may not be true now, and you could build a function-as-a-service platform out of a massive array of Raspberry Pis and it'd still have solid at-least-once invocation semantics. And I'm repeating this, but you're flat wrong about the listening server-on-a-port. AWS Lambda functions are bound to queues and receive events. The closest you'll get to having a socket-on-a-port is that the provisioning API has a REST endpoint. So if it isn't necessarily server hardware, and there's no server endpoint to connect to, that "hate" you started this thread with looks rather misplaced.