AWS Lambda ushered in the serverless movement when it was first rolled out by Amazon Web Services in November 2014. As interest in this space has grown, users have come to the realization that Lambda comes with its own challenges and limitations. With the introduction of Fission an open source serverless framework on Kubernetes, Platform9 was able to address most of Lambda’s shortcomings such as lock-in, limitations on deployment package size and memory allocated for functions and response times.
Read the blog: http://bit.ly/2HNUXRj
Transcript of Video:
Amrish:[00:18] The genesis of the serverless movement really started with AWS Lambda a few years ago, however, as interest in the space has grown, users have come to the realization that Lambda comes with its own disadvantages. With Fission, we attempted to address most of these as we built the product.
Amrish: [00:35] To start with, Fission is completely open source, which means that it is extensible not only to different languages and run times, but also to features that you may need. For example, you can create your own language environment and develop functions against it if it is not already contained within Fission's preexisting set. You can also modify existing environments if they don't suit your needs.
Amrish: [00:59] Another issue with Lambda is the limits that it imposes on developers that include, for example, the size of your deployment package, the amount of memory that is available to your functions, or even the number of concurrent executions of a particular function. An added benefit of the extensibility of Fission is that developers are no longer subject to these rate limits that Lambda imposes on them.
Amrish: [01:21] Further, Fission is built on top of Kubernetes. This means that it is portable to the extent that it can run anywhere Kubernetes runs, whether that's a public cloud, private data center, or even your laptop. This means that developers get the same consistent experience when developing, debugging, or testing code, as they do in production.
Amrish: [01:41] Finally, one of the main issues with Lambda is the call start time associated with function requests. Whenever a request is made to the function for the first time, Lambda will load the run time, as well as the code of the function. This results in the delayed response from the function for the first time. This happens because Lambda reclaims unused function resources when they sit idle for a period of time, resulting in latency spikes.
Amrish: [02:07] With Fission, one of our core design tenets was to optimize for call start times. Fission does this by maintaining a pre-warmed set of pods that contain the function run time. Whenever a request is made, the code for the function is injected into these pre-warmed pods, and served. As with everything else, this is customizable as well, so that developers can make their own trade offs between resource utilization and response times.
Amrish: [02:37] If you are considering, or using serverless solutions like Lambda, but need greater control and flexibility, then try Fission. It's built for developers who want to use functions as a service without the associated limitations.