AWS Lambda Best Practices for Getting Started
Cloud computing has opened up many new and exciting ways for independent software vendors or ISVs to write and deliver applications. In the realm of application development, new cloud-based technologies have effectively allowed the abstraction of code away from the underlying infrastructure required for it to run. One of the exciting cloud architectures gaining momentum is Serverless computing which allows for code to be executed without the provisioning or managing servers.
A Serverless architecture is often described as Functions-as-a-Service or FaaS since code is written to be called and executed as a cloud-hosted function or native cloud hosted service that is triggered based on an action. Arguably, the premiere serverless offering on the market today is Amazon Web Services (AWS) which combines the more than 140 native AWS cloud services with Amazon’s Lambda service. Launched in 2014, Lambda allows ISVs to run code only when needed and allows automatic scaling based on demand. All of this is accomplished with no provisioning or administration of the underlying infrastructure. Let’s take a look at a few best practices for getting started with AWS Lambda. Additionally, we will take a closer look at features and functionality and other configuration considerations of Lambda.
AWS Lambda Benefits and Use Cases
Amazon Lambda is the premier Serverless architecture solution for ISVs today who want to develop streamlined and efficient code that can be run in a scalable, on-demand way, regardless of the platform. Amazon has made the process to utilize Lambda extremely simple from the customer perspective. After uploading just a few lines of code, the newly incarnated function can start handling requests. As mentioned earlier, customers no longer need to worry about the underlying infrastructure required to make executing code possible.
This is a tremendous advantage of utilizing Amazon AWS Lambda and Serverless architecture. Aside from the underlying physical infrastructure, there are additional benefits. Customers including ISVs no longer need to perform any of the operational and administrative activities, including capacity provisioning, patching, deploying, provisioning a web frontend, etc. Instead, control of application management is passed to Amazon so that Function-as-a-Service infrastructure is managed and maintained automatically. This includes the management of memory, CPU, network, and other resources that are required for the execution of code. Lambda is a “pay as you go” service that is based on used memory, number of requests, and execution duration. Since Lambda is a totally event driven service, code is only executed when invoked. This makes the service extremely efficient and lean from a billing standpoint.
High-level workflow model of Amazon Lambda (Image courtesy of Amazon.com)
To take advantage of Lambda, there are coding requirements, including making sure applications are written in a supported programming language (Node.js, Java, Go, C#, and Python). Additionally, the application must be written to run within the AWS Lambda standard runtime environment.
Focusing on the advantages and benefits to independent software vendors or ISVs in particular, how do ISVs benefit from the capabilities and advantages of the Serverless code development and execution model? ISVs develop software and solutions for a wide range of use cases, niches, industries, and business model types. Provisioning the infrastructure and platform requirements for developing applications for customers of such a wide range and variety can be complex, cumbersome, time consuming, and challenging.
By making effective use of the Serverless architecture provided by the likes of Amazon AWS Lambda, ISVs can create powerful solutions for multiple customers and use cases, quickly, efficiently, and cost-effectively. Being able to provision code functions without the constraints of provisioning the underlying hardware, platforms, etc, allows ISVs to place their focus on what they do best – develop and supply applications and code-based solutions to their customers. This saves time, financial resources for themselves and customers, and provides tremendous agility to their development capabilities.
AWS Lambda Best Practices
Getting started with anything new from an architectural or coding perspective can be a challenge. However, the beauty of Amazon AWS Lambda and Serverless architectures in general is the granularity in which it can be implemented. Code modules and triggers can efficiently be transitioned to using the Functions-as-a-Service approach. Without the intricacies of having to manage the underlying infrastructure, a significant amount of complexity is eliminated from the process of provisioning Serverless architecture when compared to traditional application infrastructure. What if ISVs are new to Serverless architecture? Let’s take a look at best practices for getting started with AWS Lambda for considerations that need to be given attention when deploying Functions-as-a-Service code in the Lambda Serverless architecture. These include:
- Following Lambda Function Code best practices
- Keeping Security in mind
- Running Performance and Load Tests on Lambda functions
- Monitoring
- Analyzing VPC needs for Lambda
Following Lambda Function Code Best Practices
As with any vendor specified framework or technology, there are best practices that need to be followed to ensure the solution works as expected. Amazon Lambda is no exception to that rule. There are Function Code best practices that can ensure code hosted in the Lambda infrastructure performs and functions as expected. These include such items as:
- Avoid using recursive code where functions call themselves
- Minimize the complexity of your dependencies by using simpler frameworks
- Put your dependency .jar files in separate /lib directory so Lambda takes less time to unpack deployment packages
- Control dependencies in the function deployment package
- Separate the Lambda entry point from your core logic
These and other Lambda Function Code best practices ensure the solution is coded and engineered efficiently.
Keeping Cloud Security in Mind
Security mistakes can easily be made when testing or initially deploying new solutions. However, ISVs must keep in mind that security should always stay closely in focus with any solution or development process. Related to Lambda, there are several configuration items related to security that must be taken into consideration. These include:
- Make sure to understand the resources and operations your Lambda function needs, and limit the execution role to those specific permissions.
- Make sure the most restrictive IAM permissions are used with the IAM policies. With each AWS Lambda resource, the service defines a set of API operations. Lambda defines actions that can be specified in a policy.
- When you grant permissions for specific actions, you can identify the resources on which actions can be allowed or denied. Basic policy elements include Resource, Action, Effect, and Principal. Amazon has a good IAM Policy Reference Guide here.
Run Performance and Load Tests on Lambda Functions
An extremely important part of provisioning a Lambda function before going live is making sure to run both performance and load tests on the functions. Performance testing ensures picking the optimal memory configuration for the function. You don’t want to use too much memory as this increases the amount of CPU available and if not needed, can lead to being charged for unneeded resources each time the function is triggered. Load testing helps to determine how long the function runs. This allows determining an optimal timeout value for the function. If you have network calls being made outside of the function, it is important to understand how the function behaves.
Monitoring
With any piece of critical infrastructure or development code running as Function Code, monitoring is key to proactively analyzing the health and performance of applications. A powerful feature of Lambda is that it automatically monitors its functions on your behalf. The metrics gathered through this monitoring process are aggregated and reported through Amazon CloudWatch. The number of requests, execution duration, and error requests are posted to the associated CloudWatch instance.
You can setup custom alarms to trigger from these CloudWatch metrics that are gathered. Be sure to fully understand the permissions needed for your Lambda function code as log data requires permissions to write log data to CloudWatch logs. This is explained in the Manage Permissions: Using an IAM Role (Execution Role) AWS guide.
Analyzing VPC Needs for Lambda
Analyzing VPC needs for Lambda is important as there is no benefit in placing Lambda functions inside VPCs unless there is a need to do so. What needs necessitate using a VPC for Lambda functions? If you need to access resources you cannot expose publicly such as Amazon Relational Databases, you may need to house your Lambda functions in a VPC. To access these internal resources, Lambda creates elastic network interfaces or ENIs. If you do need to house Lambda functions inside of VPCs, create dedicated subnets for Lambda functions. This will make it much easier to apply custom route tables and also allows dedicating an address space to Lambda.
Concluding Thoughts
AWS Serverless computing is changing the paradigm of server infrastructure required for production application development and deployment. Amazon’s Lambda lets you run code without provisioning or managing server infrastructure and greatly reduces the complexities and capital expenditures needed for traditional application environments. Additionally, the functions live inside Amazon’s world class infrastructure that is automatically managed and maintained. Lambda code is triggered to run based on a number of specific events as needed for your business applications. Lambda functions are based on a “pay as you go” model where you are only charged when the code is executed. By making wise use of Serverless technologies and Amazon Lambda best practices, ISVs can develop applications quickly, efficiently, and with greater agility and scalability than ever before.