Alternative to AWS Lambda
AWS Lambda ushered in the serverless movement when it was first rolled out by Amazon Web Services in November 2014. Serverless computing, also referred to as event-driven programming, is a model of cloud computing that doesn’t require long lived servers to run applications, while shielding many of the complexities of server management and capacity planning from the developer.
As interest in this space has grown, users have come to the realization that Lambda comes with its own challenges and limitations. With the evolution of Fission, the open source alternative to AWS Lambda, Platform9 was able to address most of Lambda’s shortcomings, while making use of Kubernetes to enable serverless capabilities.
Open Source Fission avoids AWS Cloud lock-in
Fission, an alternative to AWS Lambda, is completely open source, which means that it is extensible, not only in terms of adding support for new languages and runtimes, but also in terms of features. For example, you can add your own language environment to Fission and start developing functions against it, if it’s not already present within Fission’s pre-existing language set. You can also modify existing environments if they don’t suit your needs.
Another issue with Lambda is that there are limits imposed on developers, such as:
- size of your deployment package
- amount of memory your function is allocated per invocation
- number of concurrent executions of functions.
An added benefit of Fission’s extensibility is that developers are not subject to any of the limitations that Lambda imposes on them. While Lambda keeps developers locked in to the AWS Cloud ecosystem, Fission is focused on the open source Kubernetes universe. Furthermore, Fission is portable and works anywhere Kubernetes runs – on a public cloud, private data center, or even a developer’s laptop. Because of this flexibility, developers can expect to get a consistent experience while developing and testing code as well as in production.
Optimizing for cold start times
One of the main issues with Lambda is the cold start times associated with function requests. When the first request is made to a function, Lambda loads up the environment, as well as the code for the function in response, which slows down the response time for the function. This occurs because Lambda periodically reclaims function resources whenever they are unused for a period of time, resulting in latency spikes.
With Fission, one of our early core design tenets was to optimize for cold starts, eliminating the latency spikes and improving overall run time. Fission does this by maintaining a pre-warmed pool of pods, which contain the function environments. These pods can be injected with the actual function code whenever a function is triggered. As with everything else in Fission, this is highly customizable too. Developers can choose their own tradeoffs, balancing response times and resource usage.
Focused on developer productivity and performance
If you are considering or using Lambda but need greater control and flexibility, then try Fission. It’s built for developers who want to use FaaS without the associated limitations. As we’ve pointed out in “Fission: What’s New with Platform9 v3.2,” Fission goes a long way in simplifying Kubernetes. The complex steps involved in packaging, deploying and managing applications are automated by Fission while being entirely native to Kubernetes.
The Fission project is being incubated at Platform9 with a public code repository on GitHub. For Fission webinars, news and blog posts, visit Fission Resources. You can join the Fission community on Slack.
Watch Amrish Kappor, VP of Engineering, on “Fission: The Open Source Alternative to AWS Lambda.”
- [Video] KubeVirt – Beyond Containers: Coming full circle back to VMs! - September 12, 2019
- The unforgiving cycle of cloud infrastructure costs (and the CAP theorem that drives them) - April 23, 2019
- Transitioning from managing VMs to orchestrating containers - November 28, 2018