【Session Report】Best Practices for Enterprise-Level Serverless Applications #AWSSummit

Hello, I'm Taewoo Kim at Classmethod, Inc., a Japanese company best-known for its outstanding AWS consulting works. We've been awarded "APN Consulting Partner of the Year 2018 – Japan" as well in 2018.

This is a session report for the presentation 「サーバーレスのエンタープライズへの拡大とベストプラクティス」at AWS Summit Tokyo 2019. The Japanese title can roughly be translated like the title of this post.

Taking photos was prohibitied in the conference hall, so this report only contains text content. Here begins!

About the Speaker

  • Chris Munns
  • Principal Developer Advocate - Serverless

Serverless?

To be serverless, it has to satisfy the followings:

  • No infrastructure you have to manage
  • Automatic Scaling
  • Pay for Value
  • HA and Security

AWS Lambda

Core part of the serverless application on AWS

Serverless Application

  • Event Source (changes of data status, request from endpoint, changes on resources)
  • Function
  • Output

Typical Usecases

  • Web Apps
  • Backends (business service, Mobile, IoT)
  • Data processing (batch, MapReduce, real-time)
  • Chatbots (chatbot logic)
  • Amazon Alexa
  • IT automation (infra management, policy engine)

 

AWS SAM

  • Serverless Application Model
  • Built on CloudFormation effectively for serverless applications
  • Open-source (Apache 2.0)
  • Take advantages of all the CloudFormation features and functions
  • Support for Import Value
  • YAML or JSON

Local developement for serverless application

  • SAM CLI can help on tasks like build, test, and deployment.
  • Step Functions Local
  • Localstack

CI/CD for serverless

  • AWS SAM or 3rd party (Apex, Zappa, etc)
  • can exploit existing CI/CD tools

Security

  • Function policy - who can invoke this function (API Gateway? S3 Bucket? etc)
  • Execution - what can Lambda can do (call another API on AWS, DynamoDB? etc)

AWS SAM Policy Template

  • More than 50 of predefined policy (https://bit.ly/2xWycnj)

Serverless Governance

By utilizing the following 2 services, the service gets visibility for the changes on AWS like who made this change? who did this?

  • AWS CloudTrail (Data event from Lambda, Kinesis, etc)
  • AWS Config

Code Governance

  • Traditional ways of delivery pipeline
  • or Lambda Layer

Lambda Layer

  • can manage dependencies and custom codes can be used
  • basically it's immutable layers, and must be updated to change
  • can remove and replace deplicated codes when using Lambda Layer

AWS SAM Globals

  • Can define Runtime, CodeUri, MemorySize, Timeout, and Layers

Monitoring and trouble shooting

  • Amazon CloudWatch
  • AWS X-ray

AWS CloudWatch

  • CloudWatch Metrics (7 built-in metrics for Lambda)
  • "putMetricData" can be used
  • CloudWatch Logs (below)
  • API Gateway Log : ERROR, INFO
  • Lambda Log: console.log() will get captured by CloudWatch including basic request info.
  • ElastiCache

AWS X-Ray

  • Deeply integrated with AWS APIGateway and AWS Lambda
var AWSXRay = require('aws-xray-sdk-core');
var AWS = AWSXRay.captureAWS(require('aws-sdk'));
s3client = AWS.S3();
  • just adding this code is enough to work with X-Ray
  • provides analytics feature - for debugging purposes

Resource Allocation

  • AWS resources that Lambda takes, specifically CPU power, will be proportional with memory size.
  • Should calculate cost carefully and make decision

To find out what's wrong?

  • Activate X-Ray
  • Lambda Logs
  • Meaningful metrics are highly related to business logic logs

Summary

  • Use effectivce tools in the development cycle.
  • CI/CD and Devops best practices are useful
  • governace made possible very easy with AWS CloudTrail and AWS Config
  • Lambda Layer can be useful
  • CloudWatch Logs are built-in
  • AWS X-Ray can make your life easy