12 Factor Serverless Applications - Mike Morain, AWS - Cloud Native Day Tel Aviv 2018
•
1 gefällt mir•450 views
The “Twelve-Factor” application model has come to represent twelve best practices for building modern, cloud-native applications. With guidance on things 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 how application development is done, the “Twelve-Factor” best practices remain relevant and applicable in a Serverless world. In this talk, we’ll apply the “Twelve-Factor” model to Serverless application development with AWS Lambda and Amazon API Gateway and show you how these services enable you to build scalable, low cost, and low administration applications.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 12 Factor Serverless Applications - Mike Morain, AWS - Cloud Native Day Tel Aviv 2018
Ähnlich wie 12 Factor Serverless Applications - Mike Morain, AWS - Cloud Native Day Tel Aviv 2018 (20)
Mehr von Cloud Native Day Tel Aviv
Mehr von Cloud Native Day Tel Aviv (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
12 Factor Serverless Applications - Mike Morain, AWS - Cloud Native Day Tel Aviv 2018
- 1. ©2017, Amazon Web Services, Inc. or its affiliates. All rights reserved 12 Factor Serverless Applications #CloudNativeDayTLV Mike Morain – Specialist Solutions Architect Developer Technologies
- 2. About me: Mike Morain - mamorain@amazon.co.uk, @mikemorain • Specialist Solutions Architect - DevTech • Coloradan living in London, UK • Previously: • AWS Specialist SA – AWS Marketplace - Software Partners • Software Development Consultant – Slalom Consulting • Developed software for many industries, including in retail, hospitality, health care, telecom, enterprise software, security, among others. • Say ‘cloud native’ and ‘DevOps’ on stage a lot
- 5. The “12 Factor” model & serverless applications • 12 Factor applications were popularized by developers building large scale applications on platforms such as Heroku • In recent years the 12 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 12 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 12 Factor guidelines don’t directly align with serverless applications or are interpreted very differently
- 13. No servers to provision or manage Scales with usage Never pay for idle Availability and fault tolerance built in Serverless means…
- 14. Serverless application SERVICES (ANYTHING) Changes in data state Requests to endpoints Changes in resource state EVENT SOURCE FUNCTION Node.js Python Java C# Go
- 15. Common Lambda use cases Web Applications • Static websites • Complex web apps • Packages for Flask and Express Data Processing • Real time • MapReduce • Batch Chatbots • Powering chatbot logic Backends • Apps & services • Mobile • IoT </></> Amazon Alexa • Powering voice-enabled apps • Alexa Skills Kit IT Automation • Policy engines • Extending AWS services • Infrastructure management
- 16. The 12 Factors: 1. Codebase 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 Let’s explore how the 12 Factors apply to a serverless application:
- 17. 1. Codebase 12Factor.net: “One codebase 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 (ie. a common Amazon API Gateway) then Lambda function code for those events should be put in the same repository • Otherwise break “services” along event source into their own repositories
- 18. 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. Every language Lambda supports has a model for this: 2. Dependencies Node.js & Python • .zip file consisting of your code and any dependencies • Can use npm/pip. • All dependencies must be at root level Java • Either .zip file with all code/dependencies, or standalone .jar with compiled class & resource files at root level, required jars in /lib directory • Can use Maven C# (.NET Core) • Either .zip file with all code/dependencies, or a standalone .dll • Can use Nuget • All assemblies (.dll) at root level
- 19. 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 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:
- 20. AWS Systems Manager – Parameter Store Centralized store to manage your configuration data • supports hierarchies • plain-text or encrypted with KMS • Can send notifications of changes to Amazon SNS/ AWS Lambda • Can be secured with IAM • Calls recorded in CloudTrail • Can be tagged • Available via API/SDK Useful for: centralized environment variables, secrets control, feature flags from __future__ import print_function import json import 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
- 21. 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 !
- 22. 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 CodeBuild AWS CodePipeline
- 23. 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 Serverless App buildspec.yml Example
- 24. 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 • 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/test tools or commands in “build” • Execute the CloudFormation “package” command to package your serverless application with SAM in “post_build” • Create and store an artifact in S3 Serverless App buildspec.yml Example
- 25. Delivery via CodePipeline Pipeline flow: 1. Commit your code to a source code repository 2. Package/Test in CodeBuild 3. Use CloudFormation actions in CodePipeline to create or update stacks via SAM templates Optional: Make use of ChangeSets 4. Make use of specific stage/environment parameter files to pass in Lambda variables 5. Test our application between stages/environments Optional: Make use of Manual Approvals
- 26. An example minimal Developer’s pipeline: MyBranch-Source Source AWS CodeCommit MyApplication Build test-build-source AWS CodeBuild MyDev-Deploy create-changeset AWS CloudFormation execute-changeset AWS CloudFormation Run-stubs AWS Lambda This pipeline: • Three Stages • Builds code artifact • One Development environment • Uses SAM/CloudFormation to deploy artifact and other AWS resources • Has Lambda custom actions for running my own testing functions
- 27. Source Source AWS CodeCommit MyApplication An example minimal production pipeline: Build test-build-source AWS 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 This pipeline: • Five Stages • Builds code artifact • Three deployed to “Environments” • Uses SAM/CloudFormation to deploy artifact and other AWS resources • Has Lambda custom actions for running my own testing functions • Integrates with a 3rd party tool/service • Has a manual approval before deploying to production
- 28. 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 container re-use. • There is no promise of container 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. 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’s APIs for Lambda • When it comes to Lambda functions there are 3 models for how they can be invoked; synchronously, asynchronously, and via stream • Instead of having one function support multiple invocation sources, create independent functions and make use of shared code via dependencies (shared packages) to support shared capabilities
- 30. Lambda execution model Synchronous (push) Asynchronous (event) Stream-based Amazon API Gateway AWS Lambda function Amazon DynamoDBAmazon SNS /order AWS Lambda function Amazon S3 reqs Amazon Kinesis changes AWS Lambda service function
- 31. Amazon S3 Amazon DynamoDB Amazon Kinesis AWS CloudFormation AWS CloudTrail Amazon CloudWatch Amazon Cognito Amazon SNSAmazon SES Cron events DATA STORES ENDPOINTS DEVELOPMENT AND MANAGEMENT TOOLS EVENT/MESSAGE SERVICES Event sources that trigger AWS Lambda and more! AWS CodeCommit Amazon API Gateway Amazon Alexa AWS IoT AWS Step Functions
- 32. 8. Concurrency 12Factor.net: “Scale out via the process model” Serverless Apps: Doesn’t apply as Lambda functions will scale automatically 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. 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. !
- 34. 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 Serverless Application Models (SAM) to deploy your application • Can pass environment/stage variables via Parameters, Mappings, Imports • Having a CI/CD process and tooling that supports multiple environments or accounts
- 35. Meet SAM!
- 36. AWS Serverless Application Model (SAM) CloudFormation extension optimized for serverless New serverless resource types: functions, APIs, and tables Supports anything CloudFormation supports Open specification (Apache 2.0) https://github.com/awslabs/serverless-application-model
- 37. 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: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable
- 38. 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: nodejs4.3 Policies: AmazonDynamoDBReadOnlyAccess Events: GetHtml: Type: Api Properties: Path: /{proxy+} Method: ANY ListTable: Type: AWS::Serverless::SimpleTable Tells CloudFormation this is a SAM template it needs to “transform” Creates a Lambda function with the referenced managed IAM policy, runtime, code at the referenced zip location, and handler as defined. Also creates an API Gateway and takes care of all mapping/permissions necessary Creates a DynamoDB table with 5 Read & Write units
- 39. Lambda and API Gateway Variables + SAM Parameters: MyEnvironment: Type: String Default: testing AllowedValues: - testing - staging - prod Description: Environment of this stack of resources SpecialFeature1: Type: String Default: false AllowedValues: - true - false Description: Enable new SpecialFeature1 … #Lambda MyFunction: Type: 'AWS::Serverless::Function' Properties: … Environment: Variables: ENVIRONMENT: !Ref: MyEnvironment Spec_Feature1: !Ref: SpecialFeature1 … #API Gateway MyApiGatewayApi: Type: AWS::Serverless::Api Properties: … Variables: ENVIRONMENT: !Ref: MyEnvironment SPEC_Feature1: !Ref: SpecialFeature1 …
- 40. SAM Local CLI tool for local testing of serverless apps Works with Lambda functions and “proxy- style” APIs Response object and function logs available on your local machine Uses open source docker-lambda images to mimic Lambda’s execution environment: • Emulates timeout, memory limits, runtimes https://github.com/awslabs/aws-sam-local
- 41. 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 CloudWatch • You can easily send more using the CloudWatch SDK
- 42. 12. Admin processes 12Factor.net: “Run admin/management tasks as one-off processes” Serverless Apps: Doesn’t apply to Lambda since 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. !
- 43. 1. Codebase 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 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
- 44. 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 pretty closely with 12 Factor guidance already, so you might be really close to meeting the “12 Factor bar” already!