O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Twelve-factor serverless applications - MAD302 - Santa Clara AWS Summit

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio

Confira estes a seguir

1 de 54 Anúncio

Twelve-factor serverless applications - MAD302 - Santa Clara AWS Summit

Baixar para ler offline

The twelve-factor application model represents 12 best practices for building modern, cloud-native applications. With guidance on factors like configuration, deployment, runtime, and multiple-service communication, the twelve-factor model prescribes best practices that apply to everything from web applications to APIs to data processing applications. Although serverless computing and AWS Lambda have changed application development, the twelve-factor best practices remain relevant and applicable in a serverless world. In this talk, we apply the twelve-factor model to serverless application development with AWS Lambda and Amazon API Gateway, and we show you how these services enable you to build scalable, well-built, low-administration applications.

The twelve-factor application model represents 12 best practices for building modern, cloud-native applications. With guidance on factors like configuration, deployment, runtime, and multiple-service communication, the twelve-factor model prescribes best practices that apply to everything from web applications to APIs to data processing applications. Although serverless computing and AWS Lambda have changed application development, the twelve-factor best practices remain relevant and applicable in a serverless world. In this talk, we apply the twelve-factor model to serverless application development with AWS Lambda and Amazon API Gateway, and we show you how these services enable you to build scalable, well-built, low-administration applications.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Twelve-factor serverless applications - MAD302 - Santa Clara AWS Summit (20)

Anúncio

Mais de Amazon Web Services (20)

Twelve-factor serverless applications - MAD302 - Santa Clara AWS Summit

  1. 1. S U M M I T SANTA CLARA
  2. 2. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Twelve-factor serverless applications Chris Munns Principal Developer Advocate - Serverless AWS M A D 3 0 2
  3. 3. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T About me Chris Munns - munns@amazon.com, @chrismunns • Principal Developer Advocate – Serverless • New Yorker Previously: • AWS Business Development Manager, DevOps, July 2015–Feb. 2017 • AWS Solutions Architect, Nov. 2011–Dec. 2014 • Formerly on operations teams @Etsy and @Meetup • Little time at a hedge fund, Xerox, and a few other startups • Rochester Institute of Technology: Applied Networking and Systems Administration ’05 • Internet infrastructure geek
  4. 4. S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
  5. 5. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T The “twelve-factor” model & serverless applications • Twelve-factor applications were popularized by developers building large scale applications on platforms such as Heroku • In recent years the twelve-factor guidelines have been considered best practices for both developers and operations engineers regardless of the application’s use- case and at nearly any scale • Many of the twelve-factor guidelines align directly with best practices for serverless applications and are improved upon given the nature of AWS Lambda, Amazon API Gateway, and other AWS services • However, some of the twelve-factor guidelines don’t directly align with serverless applications or are interpreted very differently
  6. 6. From 12factor.net
  7. 7. From 12factor.net
  8. 8. From 12factor.net
  9. 9. From 12factor.net
  10. 10. From 12factor.net
  11. 11. From 12factor.net
  12. 12. From 12factor.net
  13. 13. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Serverless applications Event source Function Services Changes in data state Requests to endpoints Changes in resource state Node.js Python Java C# Go Ruby Runtime API
  14. 14. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Common AWS Lambda use cases Web apps Backends Data processing Chatbots Amazon Alexa IT automation • Static websites • Complex web apps • Packages for Flask and Express • Apps & services • Mobile • IoT • Real time • MapReduce • Batch • Powering chatbot logic • Powering voice- enabled apps • Alexa Skills Kit • Policy engines • Extending AWS services • Infrastructure management
  15. 15. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T The 12 factors Let’s explore how the 12 Factors apply to a serverless application: 1. Code base 2. Dependencies 3. Config 4. Backing services 5. Build, release, run 6. Process 7. Port binding 8. Concurrency 9. Disposability 10. Dev/prod parity 11. Logs 12. Admin processes
  16. 16. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 1. Code base 12Factor.net: “One code base tracked in revision control, many deploys” Serverless apps: All code should be stored in revision control (a development best practice). The same repository should be used for all environments deployed to. The bounds of an “application” differ in serverless terms: • If events are shared (i.e., a common Amazon API Gateway), Lambda function code for those events should be put in the same repository • Otherwise, break “services” along event source into their own repositories
  17. 17. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 2. Dependencies 12Factor.net: “Explicitly declare and isolate dependencies” Serverless apps: Code that needs to be used by multiple functions should be packaged into its own library. Include those packages inside of your deployment package or into an AWS Lambda layer. Node.js, Python, Ruby • .zip file consisting of your code and any dependencies • Use npm/pip to install libraries • All dependencies must be at root level Java • Either .zip file with all code/dependencies, or standalone .jar • Use Maven / Eclipse IDE plugins • Compiled class & resource files at root level, required jars in /lib directory C# (.NET Core) • Either .zip file with all code / dependencies, or a standalone .dll • Use NuGet / Visual Studio plugins • All assemblies (.dll) at root level Go • .zip file consisting of your Go binary and any dependencies • Use “go get” to install dependencies
  18. 18. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Lambda layers Lets functions easily share code: Upload layer once, reference within any function Layer can be anything: dependencies, training data, configuration files, etc. Promote separation of responsibilities; lets developers iterate faster on writing business logic Built in support for secure sharing by ecosystem
  19. 19. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Using Lambda layers • Put common components in a ZIP file and upload it as a Lambda layer • Layers are immutable and can be versioned to manage updates • When a version is deleted or permissions to use it are revoked, functions that used it previously continue to work, but you won’t be able to create new ones • You can reference up to five layers, one of which can optionally be a custom runtime Lambda layers arn:aws:lambda:region:accountId:layer:shared-lib :1 Lambda layers arn:aws:lambda:region:accountId:layer:shared-lib:2 Lambda layers arn:aws:lambda:region:accountId:layer:shared-lib:3
  20. 20. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 3. Config 12Factor.net: “Store config in the environment” Serverless apps: Many ways to do this in serverless applications: • Lambda environment variables: • Key-value pairs available via standard environment variable APIs such as process.env for Node.js or os.environ for Python • Support AWS KMS encryption • API Gateway stages: • Key-value pairs available for configuring API Gateway functionality or to pass on to HTTP endpoints as URI parameters or configuration parameters to a Lambda invocation • AWS Systems Manager Parameter Store:
  21. 21. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T AWS Systems Manager – Parameter Store Centralized store to manage your configuration data • Supports hierarchies • Plaintext or encrypted with AWS KMS • Can send notifications of changes to Amazon SNS/ AWS Lambda • Can be secured with IAM • Calls recorded in CloudTrail • Can be tagged • Integrated with AWS Secrets Manager • Available via API/SDK Useful for: centralized environment variables, secrets control, feature flags from __future__ import print_function import json, boto3 ssm = boto3.client('ssm', 'us-east-1') def get_parameters(): response = ssm.get_parameters( Names=['LambdaSecureString'],WithDe cryption=True ) for parameter in response['Parameters']: return parameter['Value'] def lambda_handler(event, context): value = get_parameters() print("value1 = " + value) return value # Echo back the first key value
  22. 22. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 4. Backing services 12Factor.net: “Treat backing services as attached resources” Serverless apps: No differences. Resources that Lambda functions connect to, such as databases, should have their endpoints and access credentials made available via config resources or IAM policies. 👍
  23. 23. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 5. Build, release, run 12Factor.net: “Strictly separate build and run stages” Serverless apps: No differences. Development best practices, such as continuous integration and continuous delivery, should be followed. • Use AWS CodeBuild and AWS CodePipeline to support this: AWS CodePipelineAWS CodeBuild
  24. 24. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T buildspec.yml example version: 0.1 environment_variables: plaintext: "INPUT_FILE": "saml.yaml” "S3_BUCKET": "" phases: install: commands: - npm install pre_build: commands: - eslint *.js build: commands: - npm test post_build: commands: - aws cloudformation package --template $INPUT_FILE -- s3-bucket $S3_BUCKET --output-template post-saml.yaml artifacts: type: zip files: - post-saml.yaml - beta.json
  25. 25. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T buildspec.yml example • Variables to be used by phases of build • Examples for what you can do in the phases of a build: • You can install packages or run commands to prepare your environment in ”install” • Run syntax checking, commands in “pre_build” • Execute your build tool/command in “build” • Test your app further or ship a container image to a repository in post_build • Create and store an artifact in Amazon S3 version: 0.1 environment_variables: plaintext: "INPUT_FILE": "saml.yaml” "S3_BUCKET": "" phases: install: commands: - npm install pre_build: commands: - eslint *.js build: commands: - npm test post_build: commands: - aws cloudformation package --template $INPUT_FILE -- s3-bucket $S3_BUCKET --output-template post-saml.yaml artifacts: type: zip files: - post-saml.yaml - beta.json
  26. 26. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T An example minimal developer’s pipeline: MyBranch-Source Source CodeCommit Build test-build-source CodeBuild This pipeline: • Three stages • Builds code artifact • One development environment • Uses AWS SAM/AWS CloudFormation to deploy artifact and other AWS resources • Has Lambda custom actions for running my own testing functions MyDev-Deploy create-changeset AWS CloudFormation execute-changeset AWS CloudFormation Run-stubs AWS Lambda MyApplication
  27. 27. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T An example minimal production pipeline: This pipeline: • Five stages • Builds code artifact • Three deployed to “environments” • Uses AWS SAM/AWS CloudFormation to deploy artifact and other AWS resources • Has Lambda custom actions for running my own testing functions • Integrates with a third-party service • Has a manual approval before deploying to production Source Source CodeCommit MyApplication Build test-build-source CodeBuild Deploy testing create-changeset AWS CloudFormation execute-changeset AWS CloudFormation Run-stubs AWS Lambda Deploy staging create-changeset AWS CloudFormation execute-changeset AWS CloudFormation Run-API-test Runscope QA-Sign-off Manual Approval Review Deploy prod create-changeset AWS CloudFormation execute-changeset AWS CloudFormation Post-Deploy-Slack AWS Lambda
  28. 28. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 6. Process 12Factor.net: “Execute the app as one or more stateless processes” Serverless Apps: This is inherent in how Lambda is designed already: • Lambda functions should be treated as stateless, despite the potential to store some state in-between execution environment re-use • There is no promise of execution environment re-use between function invocations • Data that needs to be kept should be stored off Lambda in a stateful service such as a database or cache
  29. 29. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 7. Port binding 12Factor.net: “Export services via port binding” Serverless apps: In Lambda/serverless applications, this factor doesn’t apply the same due to a difference in how Lambda functions are accessed: • Instead of a “port,” Lambda functions are invoked via one or more triggering services or AWS APIs for Lambda • When it comes to Lambda functions, there are three models for how they can be invoked: synchronously, asynchronously, and poll-based • Instead of having one function support multiple invocation sources, create independent functions
  30. 30. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Lambda API 1. Lambda directly invoked via invoke API SDK clients Lambda function API provided by the Lambda service Used by all other services that invoke Lambda across all models Supports sync and async Can pass any event payload structure you want Client included in every SDK
  31. 31. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Lambda execution model Synchronous (push) Amazon API Gateway Lambda function /order Asynchronous (event) Amazon SNS Lambda function Amazon S3 reqs Poll-based Amazon DynamoDB Amazon Kinesis changes Lambda service Lambda function
  32. 32. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 8. Concurrency 12Factor.net: “Scale out via the process model” Serverless Apps: Doesn’t apply as Lambda functions will automatically scale based on load. You can fork threads inside of your function execution, but there are practical limits due to the memory and CPU/network constraints of your functions based on how you configure them. 👍
  33. 33. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Tweak your function’s computer power Lambda exposes only a memory control, with the % of CPU core and network capacity allocated to a function proportionally. Is your code CPU, network, or memory-bound? If so, it could be cheaper to choose more memory.
  34. 34. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Smart resource allocation Match resource allocation (up to 3 GB!) to logic Stats for Lambda function that calculates 1,000 times all prime numbers <= 1,000,000 128 MB 11.722965sec $0.024628 256 MB 6.678945sec $0.028035 512 MB 3.194954sec $0.026830 1024 MB 1.465984sec $0.024638 Green==Best Red==Worst
  35. 35. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T Smart resource allocation Match resource allocation (up to 3 GB!) to logic Stats for Lambda function that calculates 1,000 times all prime numbers <= 1,000,000 128 MB 11.722965sec $0.024628 256 MB 6.678945sec $0.028035 512 MB 3.194954sec $0.026830 1024 MB 1.465984sec $0.024638 Green==Best Red==Worst -10.25698sec +$0.00001
  36. 36. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 9. Disposability 12Factor.net: “Maximize robustness with fast startup and graceful shutdown” Serverless apps: Shutdown doesn’t apply as Lambda functions and their invocation are tied directly to incoming events. Speed at startup does matter though and is a factor of deployment package size + language used + VPC (or not) + pre-handler code calls. 👍
  37. 37. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T AWS X-Ray Profile and troubleshoot serverless applications: • Lambda instruments incoming requests for all supported languages and can capture calls made in code • API Gateway inserts a tracing header into HTTP calls as well as reports data back to X-Ray itself var AWSXRay = require(‘aws-xray-sdk-core‘); var AWS = AWSXRay.captureAWS(require(‘aws- sdk’)); S3Client = AWS.S3();
  38. 38. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T X-Ray trace example
  39. 39. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 10. Dev/prod parity 12Factor.net: “Keep development, staging, and production as similar as possible” Serverless apps: This can be made incredibly easy with serverless applications by: • Making use of environment/stage variables or Parameter Store for configuration information, backend resources, etc. • Using AWS SAM to deploy your application • Can pass environment/stage variables via parameters, mappings, and imports • Having a CI/CD process and tooling that supports multiple environments or accounts
  40. 40. Meet AWS SAM!
  41. 41. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T AWS Serverless Application Model (AWS SAM) AWS CloudFormation extension optimized for serverless Special serverless resource types: functions, APIs, tables, layers, and applications Supports anything AWS CloudFormation supports Open specification (Apache 2.0) https://aws.amazon.com/serverless/sam
  42. 42. AWS SAM template AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://sam-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs6.10 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable
  43. 43. AWS SAM template Tells AWS CloudFormation this is an AWS SAM template that it needs to “transform.” Creates a Lambda function with the referenced managed AWS IAM policy, runtime, code at the referenced zip location, and handler as defined. Also creates an Amazon API Gateway and takes care of all mapping/permissions necessary. Creates an Amazon DynamoDB table with five read & write units. AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetHtmlFunction: Type: AWS::Serverless::Function Properties: CodeUri: s3://sam-demo-bucket/todo_list.zip Handler: index.gethtml Runtime: nodejs6.10 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable
  44. 44. https://github.com/awslabs/aws-serverless-samfarm/blob/master/api/saml.yaml This becomes this AWS SAM template
  45. 45. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T AWS SAM Command Line Interface (AWS SAM CLI) CLI tool for local development, debugging, testing, deploying, and monitoring of serverless applications Supports API Gateway “proxy-style” and Lambda service API testing Response object and function logs available on your local machine Uses open source docker-lambda images to mimic Lambda’s execution environment such as timeout, memory limits, and runtimes Can tail production logs from CloudWatch Logs Can help you build in native dependencies https://aws.amazon.com/serverless/sam
  46. 46. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 11. Logs 12Factor.net: “Treat logs as event streams” Serverless apps: Logging (as well as metric collection) are considered a “universal right” in Lambda: • Console output automatically collected and sent to Amazon CloudWatch Logs • Logs can be turned into metrics • Logs can be sent to Amazon S3 or Amazon Elasticsearch Service easily for further inspection and trending • Metrics for Lambda and API Gateway for several key stats are automatically collected and sent to Amazon CloudWatch • You can easily send more using the CloudWatch SDK
  47. 47. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T 12. Admin processes 12Factor.net: “Run admin/management tasks as one-off processes” Serverless apps: Doesn’t apply to Lambda because you already limit your functions based on use case. True administrative tasks would occur via their own Lambda functions or via tools such as Amazon EC2 Run Command. 👍
  48. 48. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T The 12 factors & serverless applications: As we’ve seen, 12 factor application design can still be applied to serverless applications taking into account some small differences! = Works similarly = Not relevant 1. Code base 5. Build, release, run 9. Disposability 2. Dependencies 6. Process 10. Dev/prod parity 3. Config 7. Port binding 11. Logs 4. Backing services 8. Concurrency 12. Admin processes
  49. 49. © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T FIN, ACK (in closing) As we’ve reviewed the 12 factor methodology for applications, we’ve seen which factors do and do not apply the same for serverless applications: • Thinking about code reusability and how to scope your functions to the smallest size necessary provides many benefits • Factors related to underlying process management, network ports, concurrency, and admin processes are largely not an issue in serverless applications due to Lambda’s product design and features • Best practices for serverless align closely with 12 factor guidance already, so you might be really close to meeting the “12 factor” bar already!
  50. 50. aws.amazon.com/serverless/sam
  51. 51. aws.amazon.com/serverless
  52. 52. S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
  53. 53. S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
  54. 54. Thank you! S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Chris Munns munns@amazon.com @chrismunns

×