Serverless Architecture: Benefits And Best Practices

Serverless most often refers to serverless applications. Serverless applications do not require provisioning or management of servers. Its focus is on core product and business logic instead of responsibilities like operating system (OS) access control, OS patching, provisioning, right-sizing, scaling, and availability. By building an application on a serverless platform, the platform manages these responsibilities. Serverless service or platform should have the following capabilities:

• No server management – No need to provision or maintain any server. There is no software or runtime to install, maintain, or administer
• Flexible scaling – Application scales automatically or by adjusting its capacity through toggling the units of consumption (for example, throughput, memory) rather than units of individual servers
• High availability – Serverless applications have built-in availability and fault tolerance. No need to architect for these capabilities because the services running the application provide them by default
• No idle capacity – No need to pay for idle capacity. There is no need to pre-provision or over-provision capacity for things like compute. There is no charge when code is not running.

Three most commonly used platforms providing Serverless computing are AWS, Azure and GCP. AWS Cloud, for example, provides many different services that can be components of a serverless application. These include capabilities such as:

• Compute - AWS Lambda
• APIs - Amazon API Gateway
• Storage - Amazon Simple Storage Service (Amazon S3)
• Databases - Amazon DynamoDB
• Inter process messaging - Amazon SNS and SQS
• Orchestration - AWS Step Functions and Amazon CloudWatch Events

This paper primarily focusses on Serverless applications based on AWS Compute Lambda service. However, same can be achieved in Azure using azure compute service i.e. Azure Functions and in GCP using GCP compute service i.e. GCP Cloud functions.

Serverless Application Best Practices

These guidelines are based on five pillars of AWS Well-Architected Framework - Security, Reliability, Performance efficiency, Cost optimization, and Operational excellence. Some of the recommendations that are serverless-specific for each of the Well-Architected pillars are:

Security

• One IAM Role per Function - every Lambda function within your AWS account should have a 1:1 relationship with an IAM role to ensure least privilege
• Temporary AWS Credentials - No long-lived AWS credentials within your Lambda function code or configuration
• API Authorization - Use API Gateway as the event source for your Lambda function for authentication and authorization
• VPC Security - If Lambda function requires access to resources deployed inside a VPC, apply n/w security using least privilege security groups, Lambda function-specific subnets, network CLs, and route tables

Reliability

• High Availability - If a function uses the default network environment, it is automatically available to execute within all of the Availability Zones in that AWS Region. If a function is deployed within a VPC, the subnets and respective Availability Zones define function’s Availability
• Multi-region application designs to handle failover. This means shifting to another AWS Region-not just Lambda functions but also event sources
• Recovery - use dead letter queues to process events placed on that queue after recovery occurs. A dead letter queue is either an SNS topic or SQS queue as destination for all failed invocation events.

Performance Efficiency

• Choosing the Optimal Memory Size - test Lambda function at each of the available resource levels to determine optimal level of price/performance. Amount of allocated RAM impacts amount of CPU time and network bandwidth a function receives.
• Language Runtime and code optimization –
  • Choose an interpreted language over a compiled language
  • Limit the re-initialization of variables/objects on every invocation (use global/static variables, singletons, etc.)
  • Keep alive and reuse connections (HTTP, database, etc.) that were established during a previous invocation
  • Always use the default network environment unless connectivity to a resource within a VPC via private IP is required, to reduce cold start time.
  • Trim your function code package to only its runtime necessities.
  • Understanding Application Performance - use AWS X-Ray to trace the full lifecycle of an application request through each of its component parts, showing the latency and other metrics separately

Operational Excellence

• Logging - use Lambda environment variables to create a LogLevel variable that so that function can determine which log statements to create during runtime
• Metric and Monitoring – Commonly used metrics are metrics number of invocations, the execution duration. It’s best practice to create alarm threshold on all of the provided metrics through CloudWatch

Cost Optimization

• Right-Sizing, Distributed and Asynchronous design, Event Source Selection are some of points help in cost reduction

Serverless Development Guidelines

With a new application delivery model that serverless architectures enable, following are a few dimensions and constructs that a development process must make decisions about

• Use AWS SAM combined with AWS CloudFormation to define and make changes to serverless application environment
• AWS SAM Local to test serverless functions and applications locally
• Keep business logic outside the handler function to enable to create a code package as decoupled from Lambda runtime environment as possible.
• Write code to take advantage of a warm function container. Scoping variables in a way that they and can be reused on subsequent invocations where possible
• Package all dependencies with deployment package and include only essentials
• Since Lambda is billed based on the duration of function execution, keep timeouts reasonably short
• Organize Lambda function source code to be very fine-grained in SCM system. This usually means having a 1:1 relationship between Lambda functions and repository projects
• Unit test your Lambda function code focusing mostly on the business logic outside handler method
• For integration tests, create lower lifecycle versions of Lambda functions where code packages are deployed and invoked through sample events that CI/CD pipeline can trigger
• It is recommend to manage serverless deployments programmatically through CI/CD pipelines

In conclusion, building serverless applications on AWS helps in relieving the responsibilities and constraints that servers introduce. Using AWS Lambda as serverless logic layer helps to build faster and focus development efforts. Alongside Lambda, AWS provides additional serverless capabilities to build robust, performant, event-driven, reliable, secure, and cost-effective applications.