Lambda from Amazon Web Services is rapidly changing the way organizations think about IaaS deployment in the cloud. The official definition of Lambda provided by Amazon is as follows:
“AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically, from a few requests per day to thousands per second. You pay only for the compute time you consume – there is no charge when your code is not running. With AWS Lambda, you can run code for virtually any type of application or backend service – all with zero administration.”
Lambda’s flexibility and dynamic pricing can make it an attractive option for smaller teams with more fluid workloads. However, before you even register an account, there are seven questions you need to ask.
1. What is my use case?
The first thing you’ll need to determine when looking at Lambda is what your use case is.
Are you a mass market website that is anticipating huge, spiky traffic demands? Are you developing a micro-service that will be sparsely called and feel guilty about running machines 24/7? Or, are you running constant work with consistent traffic? Answering that question can help you determine if Lambda is right for you or if you should go with something more traditional like EC2.
The technology stack is also relevant here. Do you wish to host an existing, monolithic web app that you don’t wish to break it into too many functions? Are you using a non-natively supported language (like Ruby or PHP) ? Or, are you already using other AWS services like Kinesis or SNS that have decent integrations with Lambda?
You can get more info on each of these and read more about Lambda limits to understand additional constraints like max code size, memory size, disk space, etc.
2. How does the cost of Lambda compare to more traditional solutions like EC2?
When it comes to hard costs it may seem like Lambda is by far the more attractive option. Paying pennies per execution is an appealing idea, but it’s important to be aware all the numbers before getting involved with Lambda, especially when it comes to how they stack up against EC2 costs.
EC2 has been the bedrock of the AWS product list for years now. So the question is Whether or not the up-and-comers unique pricing model can dethrone the current champion. Well, let’s take a look.
The basic pricing breakdown for Lambda services is as follows:
- $0.20 per 1 million requests
- $0.00001667 for every GB-second of compute, with every execution rounded up to the nearest 100ms
But how do these numbers stack up against EC2 pricing in practical use? Well, according to Trek10’s Andy Warzen:
“If a typical transaction in your application takes 100 milliseconds to run and uses 128 MB of RAM, your m4.large instance (with 2 vCPU and 8 GB RAM) it would need to be running 82 requests per second, every second of every day, before it is more cost effective than running the same workload on Lambda. Could a single m4.large even handle 82 requests per second? Well of course that depends greatly on the workload, but typically that would be quite a lot.
On the other end of the spectrum, if your typical transaction is long-running (1 second execution time) and needs a full 1 GB of RAM for each transaction, then it would take 2 requests per second, every second of every day, on an m4.large with two vCPUs and 8 GB of RAM total, before EC2 is more cost effective. Again, whether or not that is reasonable depends greatly on your individual workload, but it gives you a sense of how heavily loaded your EC2 instance would need to be before it is more cost effective than Lambda.”
This calculation makes sense although even rounding to the next 100ms on Lambda might reduce the overall estimate a bit.
However, In addition to the raw workload, one also has to consider the supplementary costs of EC2 computing as well. There’s server maintenance costs, security costs, monitoring costs, not to mention the effort costs of setting auto scaling, HA, load balancing and more.
The bottom line is that it takes a HUGE amount of computing volume and density to make an EC2 system more cost-effective than Lambda. And even in the rare cases where your processing needs reach these levels, the extra maintenance costs still end up making Lambda the clear winner when it comes to pure economics.
3. What is the relation between Docker containers and lambda? Do I need to know containers to use Lambda?
Lambda may seem like an alternative to creating containers in your environment, but in reality containers are the underlying technology AWS uses to implement Lambda. However, from the perspective of the user, there is absolutely no relation. Unlike Azure ACI, AWS Lambda does not allow you to upload a container as the Lambda code.
Ultimately what this means is that you should consider Lambda an alternative to creating a container-heavy cloud environment. You do not need to know containers to use Lambda effectively.
4. Is Lambda really stateless? What does that mean?
In short: yes. AWS Lambda is essentially stateless. What that means, according to Amazon, is that:
“The code you run on AWS Lambda is uploaded as a “Lambda function”. Each function has associated configuration information, such as its name, description, entry point, and resource requirements. The code must be written in a ‘stateless’ style i.e. it should assume there is no affinity to the underlying compute infrastructure. Local file system access, child processes, and similar artifacts may not extend beyond the lifetime of the request, and any persistent state should be stored in Amazon S3, Amazon DynamoDB, or another Internet-available storage service. Lambda functions can include libraries, even native ones.”
Note: While AWS Lambda functions are essentially stateless, AWS does reuse the underlying container. This means each Lambda module will (mostly) be able preserve your function’s global memory state between runs. The ‘tmp’ folder is also writable for Lambda modules and can be used for caching data between runs. This post nicely covers this point.
5. How far can it scale?
Will Lambda be able to grow as fast and as large as you want it to?
While the story of unlimited scalability sparks our imagination, Amazon does apply limits and throttles on Lambda concurrent executions and these are important to understand.
Currently, the limit is 1000 concurrent Lambda executions per region. This is a soft limit which can be lifted upon a support request. However, this number applies to all Lambda functions running in that region.
This means that one poorly implemented Lambda function could affect the execution of completely different functions in the same account – undermining the fault isolation principle.
Another thing to consider is that it is not always easy to know exactly how close to these limits your system is getting. Lambda is still relatively young and as such it is still not clearly visible how many Lambda functions are running concurrently at any given moment.
This is not an insurmountable problem, but you will need to be aware that Lambda is not a “set it and forget it” solution and closely monitor the CloudWatch ‘Throttles’ metric that Lambda publishes.
6. Is Lambda really a NO-OPS solution?
No. But it does significantly reduce the amount of needed operations.
However, your DevOps team still needs to write all the deployment automation and someone will need to monitor the KPIs and metrics.
7. When using Lambda, do I need to care about security at all? if so – what should I focus on?
It is true that Lambda functions operate without the security concerns of owning and maintaining an EC2 server, but there are still best practices to be aware of:
Network Security
Lambda functions can operate inside your VPC and connect to your internal systems, DBs, etc.
This means that your existing network security practices and micro-segmentation strategy applies here too.
Clear reporting, locking, analysis and visualization of security groups (i.e. AWS ‘firewalls’) and their relationships is where third party tools such as Dome9’s ARC can be vitally important.
IAM Security
As with most of AWS services, managing your IAM Security policies should be a high priority when it comes to Lambda.
Lambda functions can be tied to a role just like EC2 instances. Try to avoid the temptation to use a few generic over-permissive roles. Instead follow the “least-privilege principle,” and define granular roles that are distributed based on functionality.
Finding the right balance between simplicity and security is something each organization will need to define for itself.
Application Security
Finally, the overall security posture of the code you are running inside AWS Lambda is still bound to traditional application security practices such as application logic flaws, vulnerable SW libraries, bugs etc.
Good software development practices, code reviews and source code scanning are still desired in this brave new world.
AWS Lambda can be a fantastically cost-effective and time-efficient solution especially for smaller services and startup organizations that lack a large OPS teams. Understanding these seven questions and their answers will go a long way to getting you prepared to launch and maintain your first batch of serverless applications or micro-services.
If you have additional questions or insights feel free to contact us anytime. The Dome9 team is always happy to help.
Read More:
The Top 12 Threats to Cloud Security
A Repeatable Model for Cloud First Deployment