Serverless - into the future of cloud?
AWS lambda is Amazon's implementation of function-as-a-service, allowing to run code in the cloud without explicitly dealing with the servers themselves. While everything usually works just fine at first and the promise land is just in sight, developers new to lambdas can ofter run into its hard limitations and hit a hard wall trying to pull off things that the AWS Lambda team decided no one should do using lambdas.
There is a long list of limitations, that can be found in AWS documentation, but for the everyday developer, there are only a few that are a commonly reoccurring and are worth exploring in the beginning.
The two most important limitations of serverless:
- Runtime limit
- Deployment package size, both zipped and unzipped
Limitation 1 - The runtime limit
(or why no one should need more than 15 minutes and stop asking us why)
As of the time of the article, AWS limits the lambda runtime to 15 minutes. For a lot of lambda use cases this is not going to be an issue, but if the whole codebase is serverless and a need arrises for a script that could easily exceed this time limit, what are the options?
As Ben Kehoe argued in his article - we don’t need a longer running lambda, we need new services to deal with those workloads, but for now (and until AWS changes their mind) - we will have to work with the tools that they provide us.
The boring solution to runtime limit
The most obvious one is to not run it as a lambda. While it is not glamorous or interesting, and sounds like a solution from 2010s, this is usually the most straightforward way to the problem of 15 minutes. If your function always needs more than 15 minutes to run, you could create a container and run it on AWS Fargate (a quick guide on Fargate vs EC2)
- 15 minute (or any other lambda limit) no longer applies
- solves the problem
- you are back to managing your own servers and losing the serverless benefits.
- solves the problem while creating other ones
The serverless solution to runtime limit
But for those diehard lambda fans who refuse to move back to managing containers - there is another approach that might be more palatable. AWS Step Function allow you to orchestrate the flow of execution of serverless modules (a good article on it)
- allows your code base to remain serverless
- forces you to split up your fat lambda into smaller tasks that can be orchestrated to fit within the 15min limit.
The serverless solution to runtime limit v2 (avoiding Step Functions)
The last approach is a mixture that might be more palatable to newcomers, because it is easier to understand, but does not work in all situations.You would still need to split up your fat lambda into smaller functions and instead of orchestrating through step functions, the lambdas could be called by a CloudWatch event trigger(5) or timed event(6)
- potentially easier to understand than step functions
- similar to cron jobs
- not tying your solution even more to a proprietary AWS service
- fat lambdas needs to be split up.
- Managing CloudWatch triggers is not necessarily easier than using Step Functions - especially when in effect you are trying to replicate what the Step Functions already provide.
Limitation 2 - Deployment package sizes are too big
(your lambdas are too fat).
Another sore topic among the serverless community is the sizes of lambdas. At the time of writing, Amazon allows any zipped up lambda to take up to 50mb and any unzipped lambda needs to fit within the 250mb limit. So what are our options?
Solution to Package size limitation - layers. Lots of layers! (5 max actually)
The AWS suggested way of squeezing out a bit more out of your lambda storage is to split off some dependencies into a layer that can be attached to the function.
- Allows to add those large (looking at you aws-iam-authenticator) executables to the lambda without hitting the upload limit.
- If done right, can make redeployments of lambdas faster - as long as the shared dependencies are excluded from lambda bundling.
- Extra complexity - need to exclude layer dependencies from bundling.
- Combined lambdas and layers still cannot exceed 250mb unzipped limit.
Solution to Package size limitation - Container lambdas (back to basics)
If the current lambdas do not fully work for you, AWS left another option for naysayers - container lambdas. While it retains most of the other lambda limitation, its size limit is greatly increased - currently standing at 10gb.
- Fat lambdas can remain fat (10gb limit).
- Potentially an easier solution that rewriting your lambdas to fit within 250mb limit.
- More involved way of working with lambdas, requires maintaining container images.
- Doesn't feel like the future if we are back to managing our containers.
This concludes the quick look into the options available to struggling lambda converts squeezing their existing monoliths into the lambda runtime. Every point here could easily warrant an in-depth look into pros, cons, how-to's, but for not - this offers a good few points to start googling on.