Taking Serverless to the Next Level

Taking Serverless to the Next Level

Devoxx Poland, Krakow, June 26th, 2019

Moving to serverless brings more benefits if you can optimize the way you work. In this session, I share best practices on different areas, from infrastructure management to deployments, distributed architectures and the role of teams, focusing on people and processes that are at the core of software development. To support our findings, we’ll review customer case studies to see what they did, why, and which benefits they got most.

7c9b8b368924556d8642bdaed3ded1f5?s=128

Danilo Poccia

June 26, 2019
Tweet

Transcript

  1. 1.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Taking

    Serverless to the Next Level Danilo Poccia Principal Evangelist, Serverless @danilop
  2. 2.

    © 2019, Amazon Web Services, Inc. or its Affiliates. What

    is serverless? No infrastructure to manage Automatic scaling Pay for value Highly available and secure
  3. 3.

    © 2019, Amazon Web Services, Inc. or its Affiliates. “I

    know how to build a serverless function, now what?”
  4. 6.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code ✓ Make infrastructure changes repeatable and predictable ✓ Release infrastructure changes using the same tools as code changes ✓ Replicate production in a staging environment to enable continuous testing
  5. 7.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code best practices ✓ Infrastructure and application in the same source repository For example: AWS CloudFormation HashiCorp Terraform ✓ Deployments include infrastructure updates
  6. 8.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code for serverless apps For example: AWS Serverless Application Model (SAM) Serverless Framework AWS Lambda Amazon DynamoDB Amazon S3 ?
  7. 9.

    © 2019, Amazon Web Services, Inc. or its Affiliates. AWS

    Serverless Application Model (SAM) template AWSTemplateFormatVersion: '2010-09-09’ Transform: AWS::Serverless-2016-10-31 Resources: GetFunction: Type: AWS::Serverless::Function Properties: Handler: index.get Runtime: nodejs8.10 CodeUri: src/ Policies: - DynamoDBReadPolicy: TableName: !Ref MyTable Events: GetResource: Type: Api Properties: Path: /resource/{resourceId} Method: get MyTable: Type: AWS::Serverless::SimpleTable Just 20 lines to create: • Lambda function • IAM role • API Gateway • DynamoDB table O pen Source
  8. 10.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Use

    SAM CLI to package and deploy SAM templates pip install --user aws-sam-cli # Or even better use native installers sam init --name my-app --runtime python cd my-app/ sam local ... # generate-event/invoke/start-api/start-lambda sam validate # The SAM template sam build # Depending on the runtime sam package --s3-bucket my-packages-bucket \ --output-template-file packaged.yaml sam deploy --template-file packaged.yaml \ --stack-name my-stack-prod sam logs -n MyFunction --stack-name my-stack-prod -t # Tail sam publish # To the Serverless Application Repository O pen Source CodePipeline Use CloudFormation deployment actions with any SAM application Jenkins Use SAM CLI plugin
  9. 11.

    © 2019, Amazon Web Services, Inc. or its Affiliates. TweetSource:

    Type: AWS::Serverless::Application Properties: Location: ApplicationId: arn:aws:serverlessrepo:... SemanticVersion: 2.0.0 Parameters: TweetProcessorFunctionName: !Ref MyFunction SearchText: '#serverless -filter:nativeretweets' Nested apps to simplify solving recurring problems Standard Component Custom Business Logic aws-serverless-twitter-event-source app Polling schedule (CloudWatch Events rule) trigger TwitterProcessor SearchCheckpoint TwitterSearchPoller Twitter Search API
  10. 12.

    © 2019, Amazon Web Services, Inc. or its Affiliates. AWS

    Cloud Development Kit (CDK) npm install -g aws-cdk cdk init app --language typescript cdk synth cdk deploy cdk diff cdk destroy CodePipeline Use CloudFormation deployment actions with any synthesized CDK application Jenkins Use CDK CLI D eveloper Preview TypeScript C# F# Java Python
  11. 13.

    © 2019, Amazon Web Services, Inc. or its Affiliates. CDK

    Lambda cron example export class LambdaCronStack extends cdk.Stack { constructor(app: cdk.App, id: string) { super(app, id); const lambdaFn = new lambda.Function(this, 'Singleton', { code: new lambda.InlineCode( fs.readFileSync('lambda-handler.py', { encoding: 'utf-8' })), handler: 'index.main’, timeout: 300, runtime: lambda.Runtime.Python37, }); const rule = new events.EventRule(this, 'Rule', { scheduleExpression: 'cron(0 18 ? * MON-FRI *)’, }); rule.addTarget(lambdaFn); } } Lambda function CloudWatch Events rule TypeScript CloudFormation Stack Set the target
  12. 16.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Source

    Build Test Production Continuous Integration / Continuous Deployment
  13. 17.

    © 2019, Amazon Web Services, Inc. or its Affiliates. CodeDeploy

    – Lambda canary deployment API Gateway Lambda function weighted alias “live” v1 Lambda function code 100%
  14. 18.

    © 2019, Amazon Web Services, Inc. or its Affiliates. CodeDeploy

    – Lambda canary deployment API Gateway Lambda function weighted alias “live” v1 code 100% Run PreTraffic hook against v2 code before it receives traffic v2 code 0%
  15. 19.

    © 2019, Amazon Web Services, Inc. or its Affiliates. CodeDeploy

    – Lambda canary deployment API Gateway Lambda function weighted alias “live” v1 code 90% Wait for 15 minutes, roll back in case of alarm v2 code 10%
  16. 20.

    © 2019, Amazon Web Services, Inc. or its Affiliates. CodeDeploy

    – Lambda canary deployment API Gateway Lambda function weighted alias “live” v1 code 0% Run PostTraffic hook and complete deployment v2 code 100%
  17. 21.

    © 2019, Amazon Web Services, Inc. or its Affiliates. CodeDeploy

    – Lambda deployments in SAM templates Resources: GetFunction: Type: AWS::Serverless::Function Properties: AutoPublishAlias: live DeploymentPreference: Type: Canary10Percent10Minutes Alarms: - !Ref ErrorsAlarm - !Ref LatencyAlarm Hooks: PreTraffic: !Ref PreTrafficHookFunction PostTraffic: !Ref PostTrafficHookFunction Canary10Percent30Minutes Canary10Percent5Minutes Canary10Percent10Minutes Canary10Percent15Minutes Linear10PercentEvery10Minutes Linear10PercentEvery1Minute Linear10PercentEvery2Minutes Linear10PercentEvery3Minutes AllAtOnce
  18. 23.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product
  19. 24.

    © 2019, Amazon Web Services, Inc. or its Affiliates. v1

    v2 v3 Customer needs Project Product
  20. 25.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Project

    Product Reach milestone Customer value Lifecycle costs Cost to reach milestone Backward looking Forward looking
  21. 26.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Product

    Features Defects Risks Debts Product development Business Customers Security & Compliance Developers & Architects Avoid Overutilization
  22. 27.

    © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. “One area where I think we are especially distinctive is failure. I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins.” To our shareowners: This year, Amazon became the fastest company ever to reach $100 billion in annual sales. Also this year, Amazon Web Services is reaching $10 billion in annual sales … doing so at a pace even faster than Amazon achieved that milestone. What’s going on here? Both were planted as tiny seeds and both have grown organically without significant acquisitions into meaningful and large businesses, quickly. Superficially, the two could hardly be more different. One serves consumers and the other serves enterprises. One is famous for brown boxes and the other for APIs. Is it only a coincidence that two such dissimilar offerings grew so quickly under one roof? Luck plays an outsized role in every endeavor, and I can assure you we’ve had a bountiful supply. But beyond that, there is a connection between these two businesses. Under the surface, the two are not so different after all. They share a distinctive organizational culture that cares deeply about and acts with conviction on a small number of principles. I’m talking about customer obsession rather than competitor obsession, eagerness to invent and pioneer, willingness to fail, the patience to think long-term, and the taking of professional pride in operational excellence. Through that lens, AWS and Amazon retail are very similar indeed. A word about corporate cultures: for better or for worse, they are enduring, stable, hard to change. They can be a source of advantage or disadvantage. You can write down your corporate culture, but when you do so, you’re discovering it, uncovering it – not creating it. It is created slowly over time by the people and by events – by the stories of past success and failure that become a deep part of the company lore. If it’s a distinctive culture, it will fit certain people like a custom-made glove. The reason cultures are so stable in time is because people self-select. Someone energized by competitive zeal may select and be happy in one culture, while someone who loves to pioneer and invent may choose another. The world, thankfully, is full of many high-performing, highly distinctive corporate cultures. We never claim that our approach is the right one – just that it’s ours – and over the last two decades, we’ve collected a large group of like-minded people. Folks who find our approach energizing and meaningful. One area where I think we are especially distinctive is failure. I believe we are the best place in the world to fail (we have plenty of practice!), and failure and invention are inseparable twins. To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment. Most large organizations embrace the idea of invention, but are not willing to suffer the string of failed experiments necessary to get there. Outsized returns often come from betting against conventional wisdom, and conventional wisdom is usually right. Given a ten percent chance of a 100 times payoff, you should take that bet every time. But you’re still going to be wrong nine times out of ten. We all know that if you swing for the fences, you’re going to strike out a lot, but you’re also going to hit some home runs. The difference between baseball and business, however, is that baseball has a truncated outcome distribution. When you swing, no matter how well you connect with the ball, the most runs you can get is four. In business, every once in a while, when you step up to the plate, you can score 1,000 runs. This long-tailed distribution of returns is why it’s important to be bold. Big winners pay for so many experiments. AWS, Marketplace and Prime are all examples of bold bets at Amazon that worked, and we’re fortunate to have those three big pillars. They have helped us grow into a large company, and there are certain things that only large companies can do. With a tip of the hat to our Seattle neighbors, no matter how good an entrepreneur you are, you’re not going to build an all-composite 787 in your garage startup – not one you’d want to fly in anyway. Used well, our scale enables us to build services for customers that we could otherwise never even contemplate. But also, if we’re not vigilant and thoughtful, size could slow us down and diminish our inventiveness. 2015 Letter to Shareholders
  23. 29.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Serverless

    for Product Development Less code, more speed Focus on what you want to build Estimate the cost per user or per feature Link business models and tiers to features and costs Faster to turn an idea into a prototype Prototypes are easier to bring in production Service updates enable new features
  24. 30.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product
  25. 31.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices
  26. 32.

    © 2019, Amazon Web Services, Inc. or its Affiliates. “Complexity

    arises when the dependencies among the elements become important.” Scott E. Page, John H. Miller Complex Adaptive Systems
  27. 34.

    © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. “A complex system that works is invariably found to have evolved from a simple system that worked.” Gall’s Law
  28. 35.

    © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. “A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
  29. 36.

    © 2019, Amazon Web Services, Inc. or its Affiliates. “Amazon

    S3 is intentionally built with a minimal feature set. The focus is on simplicity and robustness.” – Amazon S3 Press Release, March 14, 2006
  30. 37.

    © 2019, Amazon Web Services, Inc. or its Affiliates. How

    does Serverless work? Storage Databases Analytics Machine Learning . . . Your unique business logic User uploads a picture Customer data updated Anomaly detected API call . . . Fully-managed services Events Functions
  31. 38.

    © 2019, Amazon Web Services, Inc. or its Affiliates. What

    is an “event” ? “something that happens” Events tell us a fact Immutable time series Time What 2019 06 21 08 07 06 CustomerCreated 2019 06 21 08 07 09 OrderCreated 2019 06 21 08 07 13 PaymentSuccessful 2019 06 21 08 07 17 CustomerUpdated . . . . . .
  32. 39.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Should

    you focus on the current status, or what is happening? Current status Domain model Commands Control ”CreateUser” “AddProduct” What happens Domain events Event-driven Autonomy ”UserCreated” “ProductAdded”
  33. 40.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Commands

    Vs Events Command Has an intent Directed to a target Personal communication ”CreateUser” “AddProduct” Event It’s a fact For others to observe Broadcast one to many ”UserCreated” “ProductAdded”
  34. 41.

    © 2019, Amazon Web Services, Inc. or its Affiliates. “Antifragility

    is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.” Nassim Nicholas Taleb Antifragile Chaos Engineering
  35. 42.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Understand

    latency Systems Performance by Brendan Gregg
  36. 43.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Understand

    latency and percentiles P100 | P99 | P90 | P50
  37. 46.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Think

    event-driven – Serverless by Design https://sbd.danilop.net – https://github.com/danilop/ServerlessByDesign
  38. 47.

    © 2019, Amazon Web Services, Inc. or its Affiliates. AWS

    Event Fork Pipelines https://github.com/aws-samples/aws-serverless-event-fork-pipelines Amazon SNS topic Event storage & backup pipeline Event search & analytics pipeline Event replay pipeline Your event processing pipeline filtered events events to replay all events Standard Components Custom Business Logic
  39. 48.

    © 2019, Amazon Web Services, Inc. or its Affiliates. AWS

    Event Fork Pipelines – E-Commerce Example
  40. 49.

    © 2019, Amazon Web Services, Inc. or its Affiliates. AWS

    Event Fork Pipelines in the Serverless Application Repository
  41. 50.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices
  42. 51.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices Focus on your team
  43. 52.

    © 2019, Amazon Web Services, Inc. or its Affiliates. You

    Build It, You Run It “This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to- day contact with the customer.” – Werner Vogels CTO, Amazon.com
  44. 53.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Team

    size & communication paths = "(" − 1) 2 Communication paths in a team of N people
  45. 54.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Two

    pizza teams Photo by Kristina Bratko on Unsplash
  46. 55.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Separable

    Vs complex tasks Separable task Complex task
  47. 56.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Ability

    as a collection of cognitive tools Adam Ability = 5 { A, B, C, D, E } For example: A – mobile development on iOS B – back end development in Java C – data analytics in Python D – complex SQL queries E – …
  48. 57.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Ability

    as a collection of cognitive tools Adam Carl Betsy { C, D, G } Ability = 5 Ability = 4 Ability = 3 { A, B, E, F } { A, B, C, D, E }
  49. 58.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Diversity

    bonus model – Team with best abilities Adam Carl Betsy { C, D, G } Ability = 5 Ability = 4 Ability = 3 Team Ability = 6 { A, B, E, F } { A, B, C, D, E }
  50. 59.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Diversity

    bonus model – Team with more cognitive tools Adam Carl Betsy { A, B, E, F } { A, B, C, D, E } { C, D, G } Ability = 5 Ability = 4 Ability = 3 Team Ability = 7
  51. 60.

    © 2019, Amazon Web Services, Inc. or its Affiliates. No

    diversity, no bonus – Beware hiring managers Adam Carl Betsy { A, B, C, D } { A, B, C, D, E } { B, C, D } Ability = 5 Ability = 4 Ability = 3
  52. 61.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Some

    cognitive tools must be learned in order Adam Carl Betsy { A, B, C, D } { A, B, C, D, E } { A, B, C } Ability = 5 Ability = 4 Ability = 3
  53. 62.

    © 2019, Amazon Web Services, Inc. or its Affiliates. 2,092

    people who worked on 474 musicals from 1945 to 1989 Small world networks & creativity AJS Volume 111 Number 2 (September 2005): 000–000 PROOF 1 ᭧ 2005 by The University of Chicago. All rights reserved. 0002-9602/2005/11102-0003$10.00 Thursday Oct 13 2005 11:31 AM AJS v111n2 090090 VSJ Collaboration and Creativity: The Small World Problem1 Brian Uzzi Northwestern University Jarrett Spiro Stanford University Small world networks have received disproportionate notice in di- verse fields because of their suspected effect on system dynamics. The authors analyzed the small world network of the creative artists who made Broadway musicals from 1945 to 1989. Based on original arguments, new statistical methods, and tests of construct validity, they found that the varying “small world” properties of the systemic- level network of these artists affected their creativity in terms of the financial and artistic performance of the musicals they produced. The small world network effect was parabolic; performance in- creased up to a threshold after which point the positive effects reversed. Creativity aids problem solving, innovation, and aesthetics, yet our un- derstanding of it is still forming. We know that creativity is spurred when diverse ideas are united or when creative material in one domain inspires or forces fresh thinking in another. These structural preconditions suggest 1 Our thanks go out to Duncan Watts; Huggy Rao; Peter Murmann; Ron Burt; Matt Bothner; Frank Dobbin; Bruce Kogut; Lee Fleming; David Stark; John Padgett; Dan Diermeier; Stuart Oken; Jerry Davis; Woody Powell; workshop participants at the University of Chicago, University of California at Los Angeles, Harvard, Cornell, New York University, the Northwestern University Institute for Complex Organizations (NICO); and the excellent AJS reviewers, especially the reviewer who provided a remarkable 15, single-spaced pages of superb commentary. We particularly wish to thank Mark Newman for his advice and help in developing and interpreting the bipartite-affiliation network statistics. We also wish to give very special thanks to the Santa Fe Institute for creating a rich collaborative environment wherein these ideas first emerged, and to John Padgett, the organizer of the States and Markets group at the Santa Fe Institute. Direct correspondence to Brian Uzzi, Kellog School of Man- agement, Northwestern University, Evanston, Illinois 60208. E-mail: Uzzi@northwestern.edu
  54. 63.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices Focus on your team
  55. 64.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices Focus on your team Don’t reinvent the wheel
  56. 65.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Capital

    One – Credit Offers API serverless architecture Affiliates www.capitalone.com/ credit-cards/prequalify AWS Cloud Capital One API Gateway VPC Lambda Function Traces Logs Production Support Command Center COAT Credit Offers API Team Lambda Function S3 Bucket TTL Third-Party API Case Study
  57. 66.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Capital

    One – Credit Offers API CI/CD pipeline Continuous Improvement, Continuous Delivery! GitHub LGTM Bot Jenkins AWS SAM S3 Bucket (Versioning) Lambda Function DeploymentType: dev: AllAtOnce qa: AllAtOnce qaw: AllAtOnce prod: Canary10Percent10Minutes prodw: Canary10Percent10Minutes canary5xxGetProductsAlarm: Type: AWS::CloudFormation::Alarm Properties: AlarmActions: - !FindInMap: - params - AdminSNSTopic - !Ref Environment AlarmDescription: 500 error from product listing Lambda. ComparisonOperator: GreatherThanOrEqualTothreshold Period: 300 Statistic: Sum Threshold: 1 EvaluationPeriod: 1 Case Study
  58. 67.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Capital

    One – Benefits from taking the API serverless Performance gains From the time the request is received by lambda to the time to send the response back 70% Cost savings By removing EC2, ELB and RDS from our solution 90% Increase in team velocity Reduce investment in team’s time on DevOps and dedicate back to feature development! 30% Case Study
  59. 69.

    OLD VS NEW March 2019 cost* $5,393 March 2015 cost*

    $83,908 *All hosting costs are paid for through corporate partnerships. 100% of public donations go to the projects we fund. Case Study
  60. 71.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Positive

    Chat – Serverless architecture Amazon DynamoDB Amazon Cognito Amazon API Gateway WebSocket connection PositiveChat Lambda function Connections table Conversations table Topics table Web browser AWS Cloud S3 bucket for static assets (HTML, CSS, JS) Authentication Authorization To be implemented Amazon Comprehend Amazon Translate Amazon Rekognition To be implemented https://github.com/danilop/serverless-positive-chat D em o
  61. 72.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Positive

    Chat https://pchat.demo.danilop.net/?room=DevoxxPoland D em o
  62. 73.

    © 2019, Amazon Web Services, Inc. or its Affiliates. $

    wc -l positive-chat/app.js 326 positive-chat/app.js $ wc -l www/index.js 204 www/index.js backend + frontend ≃ 460 lines of code removing empty lines and comments
  63. 75.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices Focus on your team Don’t reinvent the wheel
  64. 76.

    © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices Focus on your team Don’t reinvent the wheel
  65. 79.

    © 2019, Amazon Web Services, Inc. or its Affiliates. ©

    2019, Amazon Web Services, Inc. or its Affiliates. Thank you! @danilop