Where Did the Servers Go?

Serverless computing still requires servers, but the server management and capacity planning decisions are hidden from the developer or operator. You can use serverless code with code you deploy in traditional styles, such as microservices. Alternatively, you can write applications to be purely serverless with no provisioned servers.

AWS Lambda uses containerization to run your code. When your function is triggered, it creates a container. Then your code executes and returns your application or services the result. If a container is created on the first invocation, AWS refers to this as a cold start. Once the container starts to run, it remains active for several minutes before it terminates. If an invocation runs on a container that is already available, that invocation runs on a warm container.

By default, AWS Lambda runs containers inside the AWS environment, and not within your personal AWS account. However, you can also run AWS Lambda inside your Amazon Virtual Private Cloud (Amazon VPC). Figure 12.1 shows the execution flow process.

Monolithic vs. Microservices Architecture

Microservices are an architectural and organizational approach to software development whereby software is composed of small independent services that communicate over well-defined application programming interfaces (APIs). Small, self-contained teams own these services.

Historically, applications have been developed as monolithic architectures. With monolithic architectures, all processes are tightly coupled and run as a single service. If one process of the application experiences a spike in demand, you have to scale the entire architecture. To add or improve a monolithic application’s features, it becomes more complicated as the code base grows. This complexity limits experimentation and makes it difficult to implement new ideas. Monolithic architectures increase the risk for application availability, as many dependent and tightly coupled processes increase the impact of a single process failure.

Microservices are more agile, and scaling is more flexible than with monolithic applications. You can deploy new portions of your code faster and more easily. With AWS Lambda and other services, you can begin to create microservices for your application.

Languages AWS Lambda Supports

AWS Lambda functions currently support the following languages:

• C# (.NET Core 1.0)
• C# (.NET Core 2.0)
• Go 1.x
• Java 8
• Node.js 4.3
• Node.js 6.10
• Node.js 8.10
• Python 2.7
• Python 3.6

Creating an AWS Lambda Function

You can use any of the following methods to access AWS services and create an AWS Lambda function that will call an AWS service:

• AWS Management Console—graphical user interface (GUI)
• AWS command line interface (AWS CLI)—Linux Shell and Windows PowerShell
• AWS Software Development Kit (AWS SDK)—Java, .NET, Node.js, PHP, Python, Ruby, Go, Browser, and C++
• AWS application programming interface (API)—send HTTP/HTTPS requests manually using API endpoints

Launch the AWS Management Console, and select the AWS Lambda service under the Compute section (see Figure 12.2).

When you create an AWS Lambda function, there are three options:

Author from scratch Manually create all settings and options.

Blueprints Select a preconfigured template that you can modify.

Serverless application repository Deploy a publicly shared application with the AWS Serverless Application Model (AWS SAM).

When authoring from scratch, you must provide three details to create an AWS Lambda function:

• Name—name of the AWS Lambda function
• Runtime—language in which the AWS Lambda function is written
• Role—permissions of your functions

After you name the function and select a runtime language, you define an AWS Identity and Access Management (IAM) role.

Execution Methods/Invocation Models

There are two invocation models for AWS Lambda.

• Nonstreaming Event Source (Push Model)—Amazon Echo, Amazon Simple Storage Service (Amazon S3), Amazon Simple Notification Service (Amazon SNS), and Amazon Cognito
• Streaming Event Source (Pull Model)—Amazon Kinesis or Amazon DynamoDB stream

Additionally, you can execute an AWS Lambda function synchronously or asynchronously. The InvocationType parameter determines when to invoke an AWS Lambda function. This parameter has three possible values:

• RequestReponse—Execute synchronously.
• Event—Execute asynchronously.
• DryRun—Test that the caller permits the invocation but does not execute the function.

With an event source (push model), a service such as Amazon S3 invokes the AWS Lambda function each time an event occurs with the bucket you specify.

Figure 12.3 illustrates the push model flow.

1. You create an object in a bucket.
2. Amazon S3 detects the object-created event.
3. Amazon S3 invokes your AWS Lambda function according to the event source mapping in the bucket notification configuration.
4. AWS Lambda verifies the permissions policy attached to the AWS Lambda function to ensure that Amazon S3 has the necessary permissions.
5. AWS Lambda executes the AWS Lambda function, and the AWS Lambda function receives the event as a parameter.

With a pull model invocation, AWS Lambda polls a stream and invokes the function upon detection of a new record on the stream. Amazon Kinesis uses the pull model.

Figure 12.4 illustrates the sequence for a pull model.

1. A custom application writes records to an Amazon Kinesis stream.
2. AWS Lambda continuously polls the stream and invokes the AWS Lambda function when the service detects new records on the stream. AWS Lambda knows which stream to poll and which AWS Lambda function to invoke based on the event source mapping you create in AWS Lambda.
3. Assuming that the attached permissions policy, which allows AWS Lambda to poll the stream, is verified, then AWS Lambda executes the function.

Figure 12.4 uses an Amazon Kinesis stream, but the same principle applies when you work with an Amazon DynamoDB stream.

The final way to invocate an AWS Lambda function applies to custom applications with the RequestReponse invocation type. Using this invocation method, AWS Lambda executes the function synchronously, returns the response immediately to the calling application, and alerts you to whether the invocation occurs.

Your application creates an HTTP POST request to pass the necessary parameters and invoke the function. To use this type of invocation model, you must set the RequestResponse in the X-Amz–Invocation–Type HTTP header.

Securing AWS Lambda Functions

AWS Lambda functions include two types of permissions.

Execution permissions enable the AWS Lambda function to access other AWS resources in your account. For example, if the AWS Lambda function needs access to Amazon S3 objects, you grant permissions through an AWS IAM role that AWS Lambda refers to as an execution role.

Invocation permissions are the permissions that an event source needs to communicate with your AWS Lambda function. Depending on the invocation model (push or pull), you can either update the access policy you associate with your AWS Lambda function (push) or update the execution role (pull).

AWS Lambda provides the following AWS permissions policies:

LambdaBasicExecutionRole Grants permissions only for the Amazon CloudWatch logactions to write logs. Use this policy if your AWS Lambda function does not access any other AWS resources except writing logs.

LambdaKinesisExecutionRole Grants permissions for Amazon Kinesis data stream and Amazon CloudWatch log actions. If you are writing an AWS Lambda function to process Amazon Kinesis stream events, attach this permissions policy.

LambdaDynamoDBExecutionRole Grants permissions for Amazon DynamoDB stream and Amazon CloudWatch log actions. If you are writing an AWS Lambda function to process Amazon DynamoDB stream events, attach this permissions policy.

LambdaVPCAccessExecutionRole Grants permissions for Amazon EC2 actions to manage elastic network interfaces. If you are writing an AWS Lambda function to access resources inside the Amazon VPC service, attach this permissions policy. The policy also grants permissions for Amazon CloudWatch log actions to write logs.

Function Package

Two parts of the AWS Lambda function are considered critical: the function package and the function handler. The function code package contains everything you need to be available locally when your function is executed. At minimum, it contains your code for the function itself, but it may also contain other assets or files that your code references upon execution. This includes binaries, imports, or configuration files that your code/function needs. The maximum size of a function code package is 50 MB compressed and 250 MB extracted/decompressed.

You can create the AWS Lambda function by using the AWS Management Console, SDK, API, or with the CreateFunction API.

Use the AWS CLI to create a function with the commands, as shown here:

aws lambda create-function 
--region us-east-2 
--function-name MyCLITestFunction 
--role arn:aws:iam:account-id:role/role_name 
--runtime python3.6 
--handler MyCLITestFunction.my_handler 
--zip-file fileb://path/to/function/file.zip

Function Handler

When the AWS Lambda function is invoked, the code execution begins at the handler. The handler is a method inside the AWS Lambda function that you create and include in your package. The handler syntax depends on the language you use for the AWS Lambda function.

For Python, the handler is written as follows:

def aws lambda_handler(event, context):
        return "My First AWS Lambda Function"

For Java, it is written as follows:

MyOutput output handlerName(MyEvent event, Context context) {
        return "My First AWS Lambda Function"
    }

For Node.js, it is written as follows:

exports.handlerName = function(event, context, callback) {
        return "My First AWS Lambda Function"
    }

And for C#, it is written as follows:

myOutput HandlerName(MyEvent event, ILambdaContext context) {
        return "My First AWS Lambda Function"
    }

When the handler is specified and invoked, the code inside the handler executes. Your code can call other methods and functions within other files and classes that you store in the ZIP archive. The handler function can interact with other AWS services and make third-party API requests to web services that it might need to interact with.

Event Object

You can pass event objects that you pass into the handler function. For example, the Python function is written as follows:

def aws lambda_handler(event, context):
        return "My First AWS Lambda Function"

This first object you pass is the event object. The event includes all the data and metadata that your AWS Lambda function needs to implement the logic.

Context Object

The second object that you pass to the handler is the context object. The context object contains data about the AWS Lambda function invocation itself. The context and structure of the object vary based on the AWS Lambda function language. There are three primary data points that the context object contains.

AWS Requestid Tracks specific invocations of an AWS Lambda function, and it is important for error reports or when you need to contact AWS Support.

Remaining time Amount of time in milliseconds that remain before your function timeout occurs. AWS Lambda functions can run a maximum of 300 seconds (5 minutes) as of this writing, but you can configure a shorter timeout.

Logging Each language runtime provides the ability to stream log statements to Amazon CloudWatch Logs. The context object contains information about which Amazon CloudWatch Log stream your log statements are sent to.

Descriptions and Tags

An AWS best practice is to tag and give descriptions of your resources. As you start to scale services and create more resources on the AWS Cloud, identifying resources becomes a challenge if you do not implement a tagging strategy.

Memory

After you write your AWS Lambda function code, configure the function options. The first parameter is function memory. For each AWS Lambda function, increase or decrease the function resources (amount of random access memory). You can allocate 128 MB of RAM up to 3008 MB of RAM in 64-MB increments. This dictates the amount of memory available to your function when it executes and influences the central processing unit (CPU) and network resources available to your function.

Timeout

When you write your code, you must also configure how long your function executes for before a timeout is returned. The default timeout value is 3 seconds; however, you can specify a maximum of 300 seconds (5 minutes), the longest timeout value. You should not automatically set this function for the maximum value for your AWS Lambda function, as AWS charges based on execution time in 100-ms increments. If you have a function that fails quickly, you spend less money, because you do not wait a full 5 minutes to fail. If you wait on an external dependency that fails or you have programmed code incorrectly in your function, AWS Lambda processes the error for 5 minutes, or you can set it to fail within a fraction of that time to save time, cost, and resources.

After the execution of an AWS Lambda function completes or a timeout occurs, the response returns and all execution ceases. This includes any processes, subprocesses, or asynchronous process that your AWS Lambda function may have spawned during its execution.

Network Configuration

There are two ways to integrate your AWS Lambda functions with external dependencies (other AWS services, publicly hosted web services, and such) with an outbound network connection: default network configuration and Amazon VPC.

With the default network configuration, your AWS Lambda function communicates from inside an Amazon VPC that AWS Lambda manages. The AWS Lambda function can connect to the internet, but not to any privately deployed resources that run within your own VPCs, such as Amazon EC2 servers.

Your AWS Lambda function uses an Amazon VPC network configuration to communicate through an elastic network interface (NIC). This interface is provisioned within the Amazon VPC and subnets, which you choose within your own account. You can assign NIC to security groups, and traffic routes based on the route tables of the subnets where you place the NIC with the Amazon EC2 service.

If your AWS Lambda function does not need to connect to any privately deployed resources, such as an Amazon EC2, select the default networking option, as the VPC option requires you to manage more details when implementing an AWS Lambda function. These details include the following:

• Select an appropriate number of subnets, while you keep in mind the principles of high availability and Availability Zones.
• Allocate enough IP addresses for each subnet.
• Implement an Amazon VPC network design that permits your AWS Lambda function to have the correct connectivity and security to meet your requirements.
• Increase the AWS Lambda cold start times if your invocation pattern requires a new NIC to create just in time.
• Configure a network address translation (NAT) (instance or gateway) to enable outbound internet access.

If you deploy an AWS Lambda function with access to your Amazon VPC, use the following formula to estimate the NIC capacity:

Projected peak concurrent executions * (Memory in GB / 3GB)

AWS Lambda easily integrates with AWS CloudTrail, which records and delivers log files to your Amazon S3 bucket to monitor API usage inside your account.

Concurrency

Though AWS allows you to scale infinitely, AWS recommends that you fine-tune your concurrency options. By default, the account-level concurrency within a given region is set with 1,000 functions as a maximum to provide you 1,000 concurrent functions to execute. You can request a limit increase for concurrent executions from the AWS Support Center.

To view the account-level setting, use the GetAccountSettings API and view the AccountLimit object and the ConcurrentExecutions element.

For example, run this command in the AWS CLI:

aws lambda get-account-settings

This returns the following:

{
   "AccountLimit": {
      "CodeSizeUnzipped": number,
      "CodeSizeZipped": number,
      "ConcurrentExecutions": number,
      "TotalCodeSize": number,
      "UnreservedConcurrentExecutions": number
   },
   "AccountUsage": {
      "FunctionCount": number,
      "TotalCodeSize": number
   }
}

Dead Letter Queues

All applications and services experience failure. Reasons that an AWS Lambda function can fail include (but are not limited to) the following:

• Function times out while trying to reach an endpoint
• Function fails to parse input data successfully
• Function experiences resource constraints, such as out-of-memory errors or other timeouts

If any of these failures occur, your function generates an exception, which you handle with a dead letter queue (DLQ). A DLQ is either an Amazon Simple Notification Service (Amazon SNS) topic or an Amazon Simple Queue Service (Amazon SQS) queue, which you configure as the destination for all failed invocation events. If a failure event occurs, the DLQ retains the message that failed, analyzes it further, and reprocesses it if necessary.

For asynchronous event sources (InvocationType is a declared event), after two retries with automatic back-off between the retries, the event enters the DLQ, and you configure it as either an Amazon SNS topic or Amazon SQS queue.

After you enable DLQ on an AWS Lambda function, an Amazon CloudWatch metric (DeadLetterErrors) is available. The metric increments whenever the dead letter message payload cannot be sent to the DLQ at any time.

Environment Variables

AWS recommends that you separate code and configuration settings. Use environment variables for configuration settings. Environment variables are key-value pairs that you create and modify as part of your function configuration. These key-value pairs pass variables to your AWS Lambda function at execution time.

By default, environment variables are encrypted at rest, using a default KMS key of aws/lambda. Examples of environment variables that you can store include database (DB) connection strings and the type of environment (PROD, DEV, TEST, and such).

Versioning

You can publish one or more versions and aliases for your AWS Lambda functions. Versioning is an important feature to develop serverless compute architectures, as it allows you to create multiple versions without affecting what is currently deployed in the production environment. Each AWS Lambda function version has a unique Amazon Resource Name (ARN). After you publish a version, it is immutable, and you cannot change it.

After you create an AWS Lambda function, you can publish a version of that function. Here’s an example with the AWS CLI:

aws lambda publish-version 
--region region 
--function-name myCoolFunction 
--profile devuser

This returns the version number along with other details after the command executes.

{
    "TracingConfig": {
        "Mode": "PassThrough"
    },
    "CodeSha256": "Sha265Hash",
    "FunctionName": "myCoolFunction",
    "CodeSize": 218,
    "MemorySize": 128,
    "FunctionArn": "arn:aws:lambda:region:account:function:myCoolFunction:1",
    "Version": "1",
    "Role": "arn:aws:iam::account:role/service-role/lambda-basic",
    "Timeout": 3,
    "LastModified": "2018-05-11T14:59:47.753+0000",
    "Handler":lambda_function.lambda_handler",
    "Runtime": "python3.6",
    "Description": ""
}

Creating an Alias

After you create a version of an AWS Lambda function, you could use that version number in the ARN to reference that exact version of the function. However, if you release an update to the AWS Lambda function, you must then locate all the places where you call that ARN inside the application and change the ARN to the new version number. Instead, assign an alias to a particular version and use that alias in the application.

Assign an alias of PROD to the newly created version 1, and use the alias version of the ARN in the application. This way, you change the AWS Lambda function without affecting the production environment. When you are ready to move the function to production for the next version, reassign the alias to a different version, as you can reassign the alias while the version numbers remain static. To create an alias with the AWS CLI, use this:

aws lambda create-alias 
--region region 
--function-name myCoolFunction 
--description "My Alias for Production" 
--function-version "1" 
--name PROD 
--profile devuser

Now point applications to the PROD alias for the AWS Lambda function. This allows you to modify the function and improve code without affecting production. To migrate the PROD alias to the next version, run the command where 4 is the example version.

aws lambda update-alias 
--region region 
--function-name myCoolFunction 
--function-version 4 
--name PROD 
--profile devuser

The production system points to version 4 of the AWS Lambda function. As you can see with versioning and aliases, you can continue to innovate your service without affecting the current production systems.

Using Amazon CloudWatch

Amazon CloudWatch monitors AWS Lambda functions. By default, AWS Lambda enables these metrics: invocation count, invocation duration, invocation errors, throttled invocations, iterator age, and DLQ errors.

You can leverage the reported metrics to set CloudWatch custom alarms. You can create a CloudWatch alarm that watches a single CloudWatch metric. The alarm performs one or more actions based on the value of the metric. The action can be an Amazon EC2 action, an Amazon EC2 Auto Scaling action, or a notification sent to an Amazon SNS topic.

The AWS Lambda namespace includes the metrics shown in Table 12.1.

Using AWS X-Ray

AWS X-Ray is a service that collects data about requests that your application serves, and it provides tools to view, filter, and gain insights into that data to identify issues and opportunities for optimization. For any traced request to the application, information displays about the request and response, but also about calls that the application makes to downstream AWS resources, microservices, databases, and HTTP web APIs.

There are three main parts to the X-Ray service:

• Application code runs and uses the AWS X-Ray SDK (Node.js, Java, and .NET, Ruby, Python, and Go).
• AWS X-Ray daemon is an application that listens for traffic on User Datagram Protocol (UDP) port 2000, gathers raw segment data, and relays it to the AWS X-Ray API.
• AWS X-Ray displays in the AWS Management Console.

With the AWS SDK, you integrate X-Ray into the application code. The AWS SDK records data about incoming and outgoing requests and sends it to the X-Ray daemon, which relays the data in batches to X-Ray. For example, when your application calls Amazon DynamoDB to retrieve user information from an Amazon DynamoDB table, the X-Ray SDK records data from both the client request and the downstream call to Amazon DynamoDB.

When the SDK sends data to the X-Ray daemon, the SDK sends JSON segment documents to a daemon process listening for UDP traffic. The X-Ray daemon buffers segments in a queue and uploads them to X-Ray in batches. The X-Ray daemon is available for Linux, Windows, and macOS, and it is included on both AWS Elastic Beanstalk and AWS Lambda platforms.

When the daemon sends the data to X-Ray, X-Ray uses trace data from the AWS resources that power the cloud applications to generate a detailed service graph. The service graph shows the client, your frontend service, and backend services that your frontend service calls to process requests and persist data. Use the service graph to identify bottlenecks, latency spikes, and other issues to improve the performance of your applications.

With X-Ray and the service map, as shown in Figure 12.5, you can visualize how your application is running and troubleshoot any errors.