21–30 of 153 posts
Very interesting concept, however it's a bit soured by the fact that Container-based FaaS is never mentioned, and it removes a decent chunk of the negatives around FaaS. Yeah you still need to deal with the communication layer (probably with managed services such as SQS or Pub/Sub), but there's no proprietary runtime needed, no rewrites needed between local/remote runtime environments.
Very interesting concept, however it's a bit soured by the fact that Container-based FaaS is never mentioned, and it removes a decent chunk of the negatives around FaaS. Yeah you still need to deal with the communication layer (probably with managed services such as SQS or Pub/Sub), but there's no proprietary runtime needed, no rewrites needed between local/remote runtime environments.
what are some examples of container-based faas? like you put your docker image onto lambda?
* OpenFaaS - https://www.openfaas.com/blog/porting-existing-containers-to...
* AWS Lambda - https://docs.aws.amazon.com/prescriptive-guidance/latest/pat...
* Scaleway Serverless Containers - https://www.scaleway.com/en/serverless-containers/
* Azure Container Instances - https://learn.microsoft.com/en-us/azure/container-instances/...
Probably others too, those are just the ones I know off the top of my head. I see very little reason to use traditional Function-based FaaS, which forces you into a special, locked-in framework, instead of using containers that work everywhere.
One potential gotcha I'm curious if there is a good story for is if it can guard against code that depends on other processes in the local supervision tree. I'm assuming since it's talking about Ecto inserts it brings over and starts the whole apps supervision tree on the function executor but that may or may not be desired for various reasons.
Author here. I’m excited to get this out and happy to answer any questions. Hopefully I sufficiently nerd sniped some folks to implement the FLAME pattern in js , go, and other langs :)
(Aside: I wish someone would rethink Serverless, heh.)
Very interesting concept, however it's a bit soured by the fact that Container-based FaaS is never mentioned, and it removes a decent chunk of the negatives around FaaS. Yeah you still need to deal with the communication layer (probably with managed services such as SQS or Pub/Sub), but there's no proprietary runtime needed, no rewrites needed between local/remote runtime environments.
what are some examples of container-based faas? like you put your docker image onto lambda?
- Trigger the lambda via HTTP endpoint, S3, or API gateway ($)
* Pretending that starting a fly machine doesn't cost the same as triggering via s3 seems disingenuous.
* In go this would be about as difficult as flame -- you'd have to build a different entrypoint that would be 1 line of code but it could be the same codebase. Node it would depend on bundling but in theory you could do the same -- it's just a promise that takes an S3 event, that doesn't seem much different.
* I wouldn't do this at all. There's no reason the results need to be queued. Put them in a deterministically named s3 bucket where they'll live and be served from. Period.
* Again -- this is totally unnecessary. Your application *should forget* it dispatched work. That's the point of dispatching it. If you need subscribers to notice it or do some additional work I'd do it differently rather than chaining lambdas.
* Your lambda really should be doing the DB work not your main application. If you've got subscribers waiting to be informed the lambda can fire an SNS notification and all subscribed applications will see "job 1234 complete"
* s3 is our image database
* our app needs to deploy an s3 hook for lambda
* our codebase needs to deploy that lambda
* we might need to listen to SNS
which is still some complexity, but it's not the same and it's not using the wrong technology like some chain of SQS nonsense.
Looks like a great integrated take on carving out serverless work. Curious to see how it handles the server parts of serverless like environment variables, db connection counts, etc. One potential gotcha I'm curious if there is a good story for is if it can guard against code that depends on other processes in the local supervision tree. I'm assuming since it's talking about Ecto inserts it brings over and starts the…
Earlier quoted context omitted.
what are some examples of container-based faas? like you put your docker image onto lambda?
* Google Cloud Run - https://cloud.google.com/run/docs/deploying#command-line * OpenFaaS - https://www.openfaas.com/blog/porting-existing-containers-to... * AWS Lambda - https://docs.aws.amazon.com/prescriptive-guidance/latest/pat... * Scaleway Serverless Containers - https://www.scaleway.com/en/serverless-containers/ * Azure Container Instances - https://learn.microsoft.com/en-us/azure/container-instances/... Probab…
Pretty cool idea, and that api is awesome. > CPU bound work like video transcoding can quickly bring our entire service to a halt in production Couldn't you just autoscale your app based on cpu though?
Yes and no: Maybe the rest of your workloads don't require much CPU- you only need this kind of power for one or two workloads, and you don't want them getting crowded out by other work potentially. Or they require a GPU. Or your core service only needs 1-2 servers, but you need to scale up to dozens/hundreds/thousands on demand, for work that only happens maybe once a day.
i think it's cool tech, but none of those things are "hair on fire" problems for me. i'm sure they are for some people.