5 ms·

I'm still a bit puzzled by the hype around FaaS. It seems like a useful tool for things where you don't want major queuing under pressure, but you can tolerate

I'm still a bit puzzled by the hype around FaaS. It seems like a useful tool for things where you don't want major queuing under pressure, but you can tolerate human perceptible delays. But it also seems easy to build a big ball of mud deeply tied to the nuances of the chosen FaaS provider. It just seems like most use cases are probably going to be just fine with more conventional horizontal scaling techniques. But I think I missing something, so I'd love to hear from someone who can paint this picture for me.

stephenr 8y ago
> I think I missing something Koolaid.
- bartread 8y ago
  This made me smile because I too have been puzzled by the hype around serverless. I'm sure it does have its uses but it wouldn't provide an acceptable solution for any of the problems we currently need to solve. Not saying that won't change but I do find it vaguely irritating that serverless has at times been presented to me as an end to all woes when that clearly is not the case.
  - XorNot 8y ago
    Having just spent sometime actually learning "serverless" between lambda and GCP I am presently baffled as to how this isn't weirdly hard to use docker containers.
    - lilbobbytables 8y ago
      To your point, it seems like AWS ECS really is the best of both. You get the no-infrastructure benefits of Lambda with the flexibility/control of a docker container. You keep the ability to exercise a fair amount of control, easily, and clearly. And you don't sit inside really opaque execution environment. Sure, the scaling and provisioning of those Docker containers is opaque, but I'm much more willing to deal with it at that level.
      - falcolas 8y ago
        I'm guessing you're thinking of their Fargate option. ECS itself is not terribly opaque (at least to my eyes). Fargate's biggest downside is its own cold start times - unlike Lambda, there's no caching to give you warm starts on jobs. The flip side - so long as its a service and not a job, who cares? :D
Vinnl 8y ago
> But it also seems easy to build a big ball of mud deeply tied to the nuances of the chosen FaaS provider. I guess you can. However, when I built Lambda functions I did pay attention to restricting lock-in to the entrypoint, and when I later had to migrate elsewhere for non-technical reasons, that was very much doable. In other words, it's easy but not necessary to build a big ball of locked-in mud.
biztos 8y ago
I'm pretty new to it but so far I think the big selling points in a corporate environment are: 1. (Maybe, someday) no real Ops work. 2. 100% utilization (at a cost). 3. Measurability of cost in #2. I agree about the ball-of-locked-in-mud danger. And so far I've seen the Ops part be actually a bigger issue than it was before, because there's so much opaque, badly documented madness involved. With AWS Lambda + API Gateway anyhow, I can't speak to the others. Even so, it seems like long-term the Ops end of the puzzle can be planned/automated away for the most part. That leaves utilization and billing. It can be very very useful to say "This costs exactly $X and that cost scales linearly" when planning resource allocations. Even if everyone agrees it could probably be done for an unknowable amount less. The predictability and the isolation of the cost is sometimes worth spending more money. (Of course the predictability requires that the Ops Ninjas not be required, which again I think is possible long-term but definitely not short-term.) Anyway that's just for one realm of application, which I think is getting more popular ("do this internal thing we used to have some EC2's do").
- acjohnson55 8y ago
  The no-ops part is compelling, but we've already had that for years in the form of PaaS for small teams and K8s for large ones. I think the billing part sounds a bit like a trap to me. At least while FaaS retains so many quirks, it's like trading billing for the engineering time of contorting a business process to a given FaaS model (e.g. trying to eek out the lowest average and worst case latency; also working within language runtime limitations). I'm pretty sure ops will never be automated away; it can only be transmuted to a different form :). But, at best, you can achieve elegant separation of ops and process concerns. That's where I worry FaaS could be a bit of a hazard, if not carefully utilized.
  - biztos 8y ago
    > ops will never be automated away; it can only be transmuted to a different form Precisely, and the promise of FaaS is that it can become a black box you don't care anything about, and bundled into the markup you're paying on CPU, memory and network. So far in real life it looks more like Ops is very much involved whenever you update a function or -- gods help you -- actually have to debug something in production. As long as this is the case it's a broken model, because as soon as you pull your Ops Ninja away from some other task you're right back in the bad old world of unpredictable costs. My sense (as a relative newbie) is that the providers know this and are slowly trying to make stuff easier and more flexible -- and more predictable -- to deploy. Amazon Elastic Container Service being one example. The catch is that the more standard it is, the less lock-in there is, and so far my experience with AWS suggests that lock-in is a major part of their strategy.
zimbatm 8y ago
I have yet to experiment with it but I think the best use-case is cron-type functions. Imagine all the little robots you could build to automate your business. And you get monitoring unlike cron.
- acjohnson55 8y ago
  That sounds like spaghetti to me. And I also understand the total run time of each function call to be limited, typically. So that means no long overnight jobs, which is a big cron/Jenkins use case.
village-idiot 8y ago
From what I’ve seen, managing and deploying FaaS is also a major train wreck.
staticassertion 8y ago
I'm using AWS Lambdas for a project. Every lambda listens on an SQS Queue. This isn't latency sensitive in the sense of user interaction, but I certainly care about latency to a degree - primarily throughput though. The reason I've chosen this is because I do not want to manage an OS. Patch management is something I am not interested in tackling - it's a hard problem and AWS has it down anyways. There are other reasons as well (I find ephemeral systems very appealing), but this is the most significant.

stephenr 8y ago

> I think I missing something Koolaid.

bartread 8y ago
This made me smile because I too have been puzzled by the hype around serverless. I'm sure it does have its uses but it wouldn't provide an acceptable solution for any of the problems we currently need to solve. Not saying that won't change but I do find it vaguely irritating that serverless has at times been presented to me as an end to all woes when that clearly is not the case.
- XorNot 8y ago
  Having just spent sometime actually learning "serverless" between lambda and GCP I am presently baffled as to how this isn't weirdly hard to use docker containers.
  - lilbobbytables 8y ago
    To your point, it seems like AWS ECS really is the best of both. You get the no-infrastructure benefits of Lambda with the flexibility/control of a docker container. You keep the ability to exercise a fair amount of control, easily, and clearly. And you don't sit inside really opaque execution environment. Sure, the scaling and provisioning of those Docker containers is opaque, but I'm much more willing to deal with it at that level.
    - falcolas 8y ago
      I'm guessing you're thinking of their Fargate option. ECS itself is not terribly opaque (at least to my eyes). Fargate's biggest downside is its own cold start times - unlike Lambda, there's no caching to give you warm starts on jobs. The flip side - so long as its a service and not a job, who cares? :D

Vinnl 8y ago

> But it also seems easy to build a big ball of mud deeply tied to the nuances of the chosen FaaS provider. I guess you can. However, when I built Lambda functions I did pay attention to restricting lock-in to the entrypoint, and when I later had to migrate elsewhere for non-technical reasons, that was very much doable. In other words, it's easy but not necessary to build a big ball of locked-in mud.

biztos 8y ago

I'm pretty new to it but so far I think the big selling points in a corporate environment are: 1. (Maybe, someday) no real Ops work. 2. 100% utilization (at a cost). 3. Measurability of cost in #2. I agree about the ball-of-locked-in-mud danger. And so far I've seen the Ops part be actually a bigger issue than it was before, because there's so much opaque, badly documented madness involved. With AWS Lambda + API Gateway anyhow, I can't speak to the others. Even so, it seems like long-term the Ops end of the puzzle can be planned/automated away for the most part. That leaves utilization and billing. It can be very very useful to say "This costs exactly $X and that cost scales linearly" when planning resource allocations. Even if everyone agrees it could probably be done for an unknowable amount less. The predictability and the isolation of the cost is sometimes worth spending more money. (Of course the predictability requires that the Ops Ninjas not be required, which again I think is possible long-term but definitely not short-term.) Anyway that's just for one realm of application, which I think is getting more popular ("do this internal thing we used to have some EC2's do").

acjohnson55 8y ago
The no-ops part is compelling, but we've already had that for years in the form of PaaS for small teams and K8s for large ones. I think the billing part sounds a bit like a trap to me. At least while FaaS retains so many quirks, it's like trading billing for the engineering time of contorting a business process to a given FaaS model (e.g. trying to eek out the lowest average and worst case latency; also working within language runtime limitations). I'm pretty sure ops will never be automated away; it can only be transmuted to a different form :). But, at best, you can achieve elegant separation of ops and process concerns. That's where I worry FaaS could be a bit of a hazard, if not carefully utilized.
- biztos 8y ago
  > ops will never be automated away; it can only be transmuted to a different form Precisely, and the promise of FaaS is that it can become a black box you don't care anything about, and bundled into the markup you're paying on CPU, memory and network. So far in real life it looks more like Ops is very much involved whenever you update a function or -- gods help you -- actually have to debug something in production. As long as this is the case it's a broken model, because as soon as you pull your Ops Ninja away from some other task you're right back in the bad old world of unpredictable costs. My sense (as a relative newbie) is that the providers know this and are slowly trying to make stuff easier and more flexible -- and more predictable -- to deploy. Amazon Elastic Container Service being one example. The catch is that the more standard it is, the less lock-in there is, and so far my experience with AWS suggests that lock-in is a major part of their strategy.

zimbatm 8y ago

I have yet to experiment with it but I think the best use-case is cron-type functions. Imagine all the little robots you could build to automate your business. And you get monitoring unlike cron.

acjohnson55 8y ago
That sounds like spaghetti to me. And I also understand the total run time of each function call to be limited, typically. So that means no long overnight jobs, which is a big cron/Jenkins use case.

village-idiot 8y ago

From what I’ve seen, managing and deploying FaaS is also a major train wreck.

staticassertion 8y ago

I'm using AWS Lambdas for a project. Every lambda listens on an SQS Queue. This isn't latency sensitive in the sense of user interaction, but I certainly care about latency to a degree - primarily throughput though. The reason I've chosen this is because I do not want to manage an OS. Patch management is something I am not interested in tackling - it's a hard problem and AWS has it down anyways. There are other reasons as well (I find ephemeral systems very appealing), but this is the most significant.