Serverless Architecture (AWS Lambda)

This topic is based on Research Spotlight Technology Review – Serverless Architecture (AWS Lambda), CMS TRB Technical Topics, 19 December 2017.

To use or to obtain more information on leveraging the AWS Lambda Serverless compute service, contact the IUSG’s Cloud Operations Team at cmscloudoperations@cms.hhs.gov.

Introduction to Serverless Architecture

Although it is called “Serverless Architecture,” it is not really serverless. This architecture always requires a physical or virtual server built up with an OS, CPU, and memory to run software. A Serverless Architecture eliminates the b burden on the application developers to own and manage the infrastructure, allowing them to focus on implementing the code itself.

Stateless Computing Architecture Using “Function as a Service” (FaaS)

One approach to Stateless Computing Architecture is using FaaS to implement event-driven mini functions. FaaS is stateless. Examples of FaaS functions are “moving a file from one S3 bucket to another S3 bucket”, “send an email”, “send alerts/notification”, “perform a mathematical operation “, and “perform virus check”. In short, the FaaS life cycle is Load, Execute, Unload.

FaaS is a next level of microservices. FaaS helps break down a microservice further into independent functions and events (pieces of code). For example:

1. A File Upload Service can be decomposed into multiple, stateless mini functions and events such as file processing, file move, and virus checks.

2. A Measures Engine Service (used for analyzing clinical data against measures of healthcare performance) can be decomposed into such mini functions such as Measure Eligibility Check and Performance Criteria Evaluation.

Microservices and FaaS can co-exist and work well together. An application can be well-developed using the combination of microservices (for example, features where the state needs to be maintained) and FaaS. Microservices can also be developed as a logical group of isolated small functions.

AWS Lambda

AWS Lambda (LD) is an example of a Stateless Computing Architecture platform. AWS Lambda is a compute service that helps to “execute the code” without the need for the application developers to provision or manage the servers or any other computing resources. The application developers are only responsible for writing the code as functions. Each function will be configured as a “Lambda Function”. When a function is invoked, the AWS Lambda creates a container with all necessary configurations (balanced memory, CPU, network and other resources) to execute the code. AWS Lambda is responsible for creating and deleting these containers. In addition, AWS Lambda will be responsible for the entire operational and administrative activities such as provisioning capacity (scaling), monitoring code and infrastructure health, logging, applying security patches, and loading the code.

Once the code has been configured as “Lambda Functions” within AWS Lambda, the functions can be triggered by the AWS Services’ published events such as DELETE event in a S3 bucket, exposed as HTTP endpoints from an API Gateway, or invoked by using the AWS SDK.

The advantages of AWS Lambda include:

• Simplified operational and infrastructure management. A serverless platform such as AWS Lambda is responsible for auto scaling and infrastructure management. It is designed to provide high availability for FaaS functions.

• Reduced operational costs and administrative activities. Automatic operational management such as auto scaling helps to reduce the operational costs.

• Clear separation of duties. The serverless architecture helps to isolate duties for system and functional developers.

• Faster Innovation. The FaaS allows developers to update their technologies frequently to experiment with innovative ideas.

The disadvantages of AWS Lambda include:

• Multi-tenancy and vendor lock-in. The serverless architectural model does not allow a dedicated server or virtual server (or any other compute resources) as the platform. AWS Lambda is responsible for creating or decommissioning the FaaS containers. The design and code must be compatible to support the vendor platform. In addition, AWS offers simplified Lambda integrations (for example, using event source mapping, SDK) with other AWS services such as the S3 buckets, API Gateway, SNS, SQS, and features like Step Functions to orchestrate custom components like microservices. Using these services and features within the Lambda functions may greatly confine you to the AWS platform.

• Complexity. The distributed computing architecture of AWS Lambda or other serverless computing platforms can create architectural complexity.

• Limitations. Serverless computing platforms may have limitations in programing languages support, memory allocation, number of threads, or payload size in functions.

• Potential Latency. The platform is responsible for creating and bootstrapping the lambda containers that may involve potential latency.

CMS Considerations and Recommendations for Using AWS Lambda

The Serverless Architecture / AWS Lambda technologies may offer various technical and business advantages to the CMS enterprise. This architecture also poses some constraints such as multi-tenancy and vendor lock-in.

CMS recognizes the following recommendations for using AWS Lambda for CMS applications:

• Non-Cloud Based Solution. If cloud hosting is not an option for your application, using the AWS Lambda or any other Serverless platform is not a choice. At present, the Serverless architecture is only supported within the AWS environment.

• Unpredictable Load. AWS Lambda is best suited for tasks that require instantaneous scaling to support unpredictable load. AWS Lambda supports instant scaling up to a large number of parallel processes. For example, the AWS Lambda is best suited for applications when you are expecting a massive hit on your application for a very short period and need containers to scale up and down based on the traffic.

• Long-running Processes. FaaS / AWS Lambda functions are not good fit for long-running processes.

• Quantity. It is preferable to not implement significant / larger portions of an application using AWS Lambda or other serverless technologies because this may lead to vendor lock-in with that specific vendor.

CMS Measures Engine Example

In the referenced file upload measures engine example, the AWS Lambda service will be responsible for the entire operational management of the following stateless functions: File processing, File move, Measure eligibility check, and Performance evaluation. The uploaded code should not have any affinity to the underlying infrastructure (i.e., stateless). If a Lambda Function is required to maintain state, it should use one of the supported persistent stores such as S3, Dynamo DB, and NFS.

Managing Lambda Functions

The Life Cycle of a Lambda function is shown in Life Cycle of a Lambda Function. An AWS account with identities is required to set up and manage the AWS Lambda service. The identities are AWS account root user, IAM user, and IAM roles. The chosen identity must have valid permissions to work with the resources in a service.

In AWS Lambda, the primary resources are Lambda Functions and Event Source Mapping. Permission for these resources are managed by the permission policies. The permission policies can be attached to the IAM identities (users, groups, and roles) and to resources of AWS services like AWS Lambda. Each AWS Lambda function is controlled by the IAM execution role and this execution role must include the required permission policies to access other resources such as a S3 bucket. For example:

AWSLambdaBasicExecutionRole and AWSLambdaVPCAccessExecutionRole

AWS Lambda runs the Lambda functions in a VPC by default and supports connecting to resources inside a private VPC by providing the additional configuration settings (VPC Subnet and Security Groups). To support Lambda functions auto scaling behavior, the VPC resources must be configured with sufficient capacity.

Important Note: AWS Lambda does not support connecting to resources within “Dedicated Tenancy” VPCs where all EC2 instances / hosts that are launched in a VPC run on hardware that is dedicated to a single customer. Also, AWS Lambda does not support functions accessing multiple VPCs (in this case VPC peering is required).

Invoking Lambda Functions

Invoking a Lambda Function illustrates how Lambda functions may be invoked. AWS Lambda supports both synchronous and asynchronous invocation of a Lambda function. A Lambda function can be invoked / triggered from AWS Services or from HTTP Endpoints (using the AWS API Gateway or AWS SDK). The AWS provides the “invoke” API with the option for application developers to choose synchronous or asynchronous invocation types. When a lambda function must be invoked / triggered from AWS Services’ event sources (published events by the respective AWS Services), the invocation methods are predetermined by the respective AWS Services.

Monitoring Lambda Functions

The AWS Lambda uses its Amazon CloudWatch to monitor the AWS Lambda infrastructure and Lambda functions and reports the real-time metrics. The Lambda “functions” can also be monitored using other enterprise logging tools. Some logging libraries are integrated with AWS Lambda to allow lambda functions to send logging events to them through HTTP event collector features. The application developers need to write lambda functions to perform this task.

Business Rules and Recommended Practices

Business Rules

BR-LD-1: Avoid Using Lambda for CMS Sensitive Data

At present, the AWS Lambda does not support dedicated hosts or instances or even connecting to resources within the dedicated tenant VPC. The AWS Lambda platform is shared and a multi-tenant environment. Therefore, any handling / processing of CMS sensitive data such as PII or PHI within the serverless platform must be avoided. If any sensitive data handling / processing is unavoidable within AWS Lambda or any other serverless platform due to other factors, the project ISSO must work with the ISPG to implement the required security controls to protect CMS sensitive data.

BR-LD-2: Integrate with CMS Enterprise Security

CMS uses an enterprise logging and event platform for application, infrastructure and security logging, and for other services such as threat analysis. The AWS Lambda supports various enterprise logging platforms for application logging (not for infrastructure). Consider writing a common logging function and use it with other functions for logging purpose. Also, integrate your application and infrastructure log files with the CMS CCIC platform for further analysis. Please contact ISPG for more information on CCIC.

BR-LD-3: Configure Lambda to Control the Cost / Budget

When using AWS Lambda, carefully evaluate your business needs, costs, and operational requirements, and configure conditions such as the number of parallel executions, timeouts, and memory allocations to control the cost / budget.

BR-LD-4: Do Not Use the Local Volatile Storage of Lambda Containers for Persistent Data

AWS Lambda platform creates containers to execute the functions. The containers include resources such as the local volatile storage. It is always a best practice to use the container resources efficiently. For example, consider using the local volatile storage spaces temporarily for any potential performance increment opportunities, but definitely not for permanent data.

BR-LD-5: Use Lambda Only for Stateless Transactions

Maintaining state within the Lambda functions requires using other services such as databases, S3 buckets, and/or vendor specific features such as Step Functions. These other services will add complexity to the architecture and operational management and may lock you into AWS.

Recommended Practices

RP-LD-1: Avoid Complex Application Programming or Workflows in Lambda

When using FaaS functions, try to avoid writing complex application programming or workflows using vendor specific services that could lock in with a specific vendor. FaaS functions are best fit for parallel execution of mini / small tasks. They are also best suited for executing event-driven tasks in an application, such as batch processing, file transfer, virus check, email delivery, scheduled backup services, and monitoring services.

Serverless Architecture and Lambda Best Practices

The following are best practices for using Serverless Architecture and AWS Lambda:

• Orchestration / Sequencing. AWS Lambda / FaaS functions are not a good fit for orchestrating/sequencing sub-tasks. Orchestration / sequencing tasks will add complexity to the architecture and operational management.

• Hybrid Approach. Microservices and FaaS functions may be used in a hybrid approach. Microservices can be implemented using a group of FaaS functions. Microservices helps to decouple functionality by domains, and the independent/isolated sub-tasks within a microservice are eligible candidates for developing as FaaS functions.