The OpenFaaS project blog, written largely by its creator, covers serverless functions, Kubernetes, and self-hosted deployment.
HN commenters point to OpenFaaS as an easy-to-start, well-documented option for self-hosted serverless, alongside Knative.
Not about the article, but: OpenFaaS' Pricing Page[1] has no pricing on it whatsoever.
You could guess that since the Community edition is MIT licensed that it's free, but then again the language right above it says "non-production or experimental use", where Standard says "production and business use". Now, MIT I know basically means "It's on you, so if you wanna go prod go prod", but that wording just isn't friendly.
Looking over the Community Edition further, I'd honestly be stunned who would ever use this, and thus, what, if anything, about this is "Open":
- Only 5 replicas per function, ie, hope any given function doesn't have more than 5 invocations at once.
- No "scale to zero", (which is the usual cost benefit of serverless)
- There is an in-mem queue, except it's being End-of-Life'd in June, which is... a week from now.
- It does separately support cron triggers! This is great.
- It does not support any other triggers except direct call.
- Can't integrate it with any other K8s deployment tool
I honestly cannot fathom why someone would use this.
1. https://www.openfaas.com/pricing/
This is why I can see why Kubeless [1], Fission [2] and OpenFAAS [3] are gaining traction.
But my take is always that it depends on the size of your company, your cloud strategy and how much serverless you are using.
* If you are small company dabbling in small serverless scripts, just use Lambda.
* If you are a medium+ company but have gone all in on AWS or GCP, and serverless is still a limited small part of your stack, then also just use Lamda or Google Cloud Functions. But consider the options.
* If you are a multi-cloud company or more invested in serverless. Then they are the ones that should definitely consider OpenFAAS etc and not use Lamda etc for anything but minute parts of your stack.
* If you use Kubernetes and are fairly Cloud agnostic, then use Kubeless etc so that you have full serverless support in local and staging clusters and any cloud provided clusters you expand and migrate to as well.
[1] https://kubeless.io
[2] https://fission.io
[3] https://www.openfaas.com
> Ready-to-use, serverless, full-stack application built with AWS Lambda, Express.js, React, AWS DynamoDB and AWS HTTP API.
I was curious whether it supported anything other than AWS, on self-hosted "serverless" setups. The components (Lambda, DynamoDB, HTTP API) seem like there would be compatible open-source implementations.
As a complete novice to the "serverless" concept, I found this:
https://www.serverless.com/framework/docs/providers/
> Serverless Framework is deploying your code to a cloud provider like AWS, Microsoft Azure, Google Cloud Platform, Apache OpenWhisk, Cloudflare Workers, or a Kubernetes-based solution like Kubeless.
Filtering for self-hosted, looks like these are what I should start studying:
Kubeless - https://kubeless.io/
Fn - https://fnproject.io/
OpenFaaS - https://www.openfaas.com/
This last one is very interesting for me, but apparently not yet supported by the Serverless Framework. https://forum.serverless.com/t/support-for-openfaas/3023
Author here. Thanks for the question. I'll answer assuming this is a question you have for me.
As explained in the post - the 3090s were what were the test bed that proved the investment was worth it. Customer support, architecture reviews, telemetry to check license compliance. None of that could be done with online models. The amount of time we can spend going backwards and forth with enterprise customers over email can really amplify costs to our team. A few actual issues we found and fixed were listed on the linked blog post: https://www.openfaas.com/blog/painless-support-with-diag/
Having recovered revenue using it in an airgap, to preserve data agreements was more of a cherry on the cake. No need to worry about the investment, it's covered itself.
Hope that helps.
* Google Cloud Run - https://cloud.google.com/run/docs/deploying#command-line
* OpenFaaS - https://www.openfaas.com/blog/porting-existing-containers-to-openfaas/
* AWS Lambda - https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-lambda-functions-with-container-images.html
* Scaleway Serverless Containers - https://www.scaleway.com/en/serverless-containers/
* Azure Container Instances - https://learn.microsoft.com/en-us/azure/container-instances/container-instances-overview
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.
I'm currently using k8s in a staging/uat environment (running on a tiny 2 node cluster). So far, I've found it to be super useful in CI, as you can use container orchestration to emulate the larger production IaaS stack with much lower cost and time overhead than, say, a real terraform deployment. And if your team is already drinking the "cloud-native" kool-aid and wanting to use AWS lambda or a similar service, I'd argue it would be a much better investment to deploy those types of workloads as kubernetes jobs or with a framework like OpenFaaS[1] on kubernetes, giving the team much greater flexibility and avoiding vendor lock in.
https://www.openfaas.com/