3 ms·

Serverless is a latest heavily marketed fad. There are some edge cases where it’s useful - education, low use throw away bots - other than that it’s all market

Serverless is a latest heavily marketed fad. There are some edge cases where it’s useful - education, low use throw away bots - other than that it’s all marketing bs.

eitally 8y ago
Please defend this position.
pavolt 8y ago
> Serverless is a latest heavily marketed fad. Serverless is the future of the Industry. Lambda is not Serverless , it's just a FaaS which is a component of an entire Serverless Architecture. Most specifically the majority of services provided by AWS and in the Cloud already are Serverless : - Pay per usage ( GB , Execution , API Call ) - No Scaling or Provisioning ( SQS , CloudFront , Firebase ) - High Avaibility by default ( SQS , CloudFront , Firebase ) - Auto Scaling by default ( Azure CosmosDB , Firebase ) - Little to no technical limits for the service ( GCloud DataStore , S3 etc... ) If you have very little knowledge about something you shouldn't criticize it , that make you sounds even more ignorant. Most of the stuff that people actually use on AWS (S3 , CloudFront , SQS , SNS ) are delivered with a serverless architecture in mind. Again , if you are thinking "Lambda === Serverless" you really need to read more about this topic.
- zdragnar 8y ago
  Wait, we're calling S3, Firebase and any sort of metered charge scheme (aka pay per usage) "serverless" now? That's news to me, I've apparently been using serverless since I started programming as a full-time career 10 years ago! Here I thought most of those were just "cloud" services or "third party APIs".
  - pavolt 8y ago
    > I've apparently been using serverless since I started programming as a full-time career 10 years ago! You have indeed. As I mentioned above , S3 is a serverless service. Last time I checked , you don't provisioned , partition or scale S3 this is done by AWS behind the scene. Same for Firebase , same for many services. Now the move is into the "compute" aspect of thing and the architecture. Lambda basically replace, in a limited way , the compute aspect of your architecture (EC2) but obviously it has it's limits. There is a confusion between "Serverless Framework" which is an automation of Lambda + API Gateway + CloudFormation , and "Serverless Computing" which is basically an "event driven" , "pay per execution" , "auto scaling / self healing" architecture.
    - zdragnar 8y ago
      I probably should have added a `/s` somewhere in my post; my internal sense of "this doesn't sound right" is coming from a desire to enforce a distinction between "cloud", "API" and "serverless". To my mind, serverless is exclusively limited to FaaS or similar means of deploying code without visibility of the underlying server it runs on. S3 isn't about code deployment, it's a third-party API that stores data. EC2, docker et. al. at least have instances of servers you see, even if you automate away the management portion- that makes them cloudy, but not serverless. Maybe my understanding of serverless is completely at odds with what the industry is, and if so I have learned something new and am chuffed.
      - yebyen 8y ago
        > deploying code without visibility of the underlying server it runs on Well I take issue with this, I think Kubeless and Riff are definitely serverless, even though I need a Kubernetes cluster provisioned (and it obviously has servers in it). I can get visibility into those servers, or I can run them in a managed way where there will be no visibility. Both ways are serverless, I think this because they are FaaS solutions and because of the way the runtime environment is dynamically provisioned. I don't have to know or care what server it's on. I'm not sure that's what makes it "serverless" but there is definitely room for questions between "serverless" and "Serverless" with a capital S. And in at least one of those (Riff) it's actually cold/pods all go offline at rest, so not warm processes running on any server until it is called (scale to zero.) You just have an API gateway that is always online, and it starts the workers in response to events. It's hopefully lightweight compared to your app / suite of microservices / the kubeless version of what I'm describing, where each function has a memory footprint that doesn't evaporate when it's not in use. Regardless of whether you're using FaaS or not, the pricing model for servers as scale grows seems to be quite favorable compared to same size "all-lambda" solutions, and based on the feedback in this thread and prior ones, I think there's a compelling benefit to price predictability if you take the time to estimate how big your computers need to be and, say, order enough reserved instances to cover something like the capacity you will need for the year. You can always scale past that to grow when needed, but reserved instances are cheaper than ordinary instances, and ordinary instances are cheaper than an equivalent amount of CPU time on Lambda. I get how this kind of negates the benefits, but not really. It depends entirely on the pricing model and how much you use. If you can fit in the free tier, it's much less compelling. But you can start with a really small cluster if you can scale your worker deployments' pods all the way to zero without causing a downtime event. (But if you're now groaning because I've got you managing a cluster of nodes again, then your priorities might be different than mine too...)
- aglikson 8y ago
  I guess some people called it 'platform as a service', few years back :-)
scarface74 8y ago
Serverless is not just for APIs. I use it to respond to really spiky events - file puts, queue processing, etc. that really doesn’t have to be real time but you don’t want it to have high latency.

Serverless is a latest heavily marketed fad. There are some edge cases where it’s useful - education, low use throw away bots - other than that it’s all marketing bs.

eitally 8y ago

Please defend this position.

pavolt 8y ago

> Serverless is a latest heavily marketed fad. Serverless is the future of the Industry. Lambda is not Serverless , it's just a FaaS which is a component of an entire Serverless Architecture. Most specifically the majority of services provided by AWS and in the Cloud already are Serverless : - Pay per usage ( GB , Execution , API Call ) - No Scaling or Provisioning ( SQS , CloudFront , Firebase ) - High Avaibility by default ( SQS , CloudFront , Firebase ) - Auto Scaling by default ( Azure CosmosDB , Firebase ) - Little to no technical limits for the service ( GCloud DataStore , S3 etc... ) If you have very little knowledge about something you shouldn't criticize it , that make you sounds even more ignorant. Most of the stuff that people actually use on AWS (S3 , CloudFront , SQS , SNS ) are delivered with a serverless architecture in mind. Again , if you are thinking "Lambda === Serverless" you really need to read more about this topic.

zdragnar 8y ago
Wait, we're calling S3, Firebase and any sort of metered charge scheme (aka pay per usage) "serverless" now? That's news to me, I've apparently been using serverless since I started programming as a full-time career 10 years ago! Here I thought most of those were just "cloud" services or "third party APIs".
- pavolt 8y ago
  > I've apparently been using serverless since I started programming as a full-time career 10 years ago! You have indeed. As I mentioned above , S3 is a serverless service. Last time I checked , you don't provisioned , partition or scale S3 this is done by AWS behind the scene. Same for Firebase , same for many services. Now the move is into the "compute" aspect of thing and the architecture. Lambda basically replace, in a limited way , the compute aspect of your architecture (EC2) but obviously it has it's limits. There is a confusion between "Serverless Framework" which is an automation of Lambda + API Gateway + CloudFormation , and "Serverless Computing" which is basically an "event driven" , "pay per execution" , "auto scaling / self healing" architecture.
  - zdragnar 8y ago
    I probably should have added a `/s` somewhere in my post; my internal sense of "this doesn't sound right" is coming from a desire to enforce a distinction between "cloud", "API" and "serverless". To my mind, serverless is exclusively limited to FaaS or similar means of deploying code without visibility of the underlying server it runs on. S3 isn't about code deployment, it's a third-party API that stores data. EC2, docker et. al. at least have instances of servers you see, even if you automate away the management portion- that makes them cloudy, but not serverless. Maybe my understanding of serverless is completely at odds with what the industry is, and if so I have learned something new and am chuffed.
    - yebyen 8y ago
      > deploying code without visibility of the underlying server it runs on Well I take issue with this, I think Kubeless and Riff are definitely serverless, even though I need a Kubernetes cluster provisioned (and it obviously has servers in it). I can get visibility into those servers, or I can run them in a managed way where there will be no visibility. Both ways are serverless, I think this because they are FaaS solutions and because of the way the runtime environment is dynamically provisioned. I don't have to know or care what server it's on. I'm not sure that's what makes it "serverless" but there is definitely room for questions between "serverless" and "Serverless" with a capital S. And in at least one of those (Riff) it's actually cold/pods all go offline at rest, so not warm processes running on any server until it is called (scale to zero.) You just have an API gateway that is always online, and it starts the workers in response to events. It's hopefully lightweight compared to your app / suite of microservices / the kubeless version of what I'm describing, where each function has a memory footprint that doesn't evaporate when it's not in use. Regardless of whether you're using FaaS or not, the pricing model for servers as scale grows seems to be quite favorable compared to same size "all-lambda" solutions, and based on the feedback in this thread and prior ones, I think there's a compelling benefit to price predictability if you take the time to estimate how big your computers need to be and, say, order enough reserved instances to cover something like the capacity you will need for the year. You can always scale past that to grow when needed, but reserved instances are cheaper than ordinary instances, and ordinary instances are cheaper than an equivalent amount of CPU time on Lambda. I get how this kind of negates the benefits, but not really. It depends entirely on the pricing model and how much you use. If you can fit in the free tier, it's much less compelling. But you can start with a really small cluster if you can scale your worker deployments' pods all the way to zero without causing a downtime event. (But if you're now groaning because I've got you managing a cluster of nodes again, then your priorities might be different than mine too...)
aglikson 8y ago
I guess some people called it 'platform as a service', few years back :-)

scarface74 8y ago

Serverless is not just for APIs. I use it to respond to really spiky events - file puts, queue processing, etc. that really doesn’t have to be real time but you don’t want it to have high latency.