Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Taking Serverless to the Next Level

Taking Serverless to the Next Level

Voxxed Days Milano, April 13th, 2019

What are the top best practices to build and run applications without thinking about servers? Model your serverless components as templates and deploy your infrastructure as config to leverage best practices such as code reviews. Step-through and debug your code with a local execution environment. Coordinate and manage the state of each distributed component. Continuously deliver your code in production using application lifecycle management tools. Enable gradual, safe deployments. To support our findings, we’ll review customer case studies to see what they did, why, and which benefits they got most.

Danilo Poccia

April 13, 2019
Tweet

More Decks by Danilo Poccia

Other Decks in Programming

Transcript

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

    Serverless to the Next Level Danilo Poccia Principal Evangelist, Serverless @danilop
  2. © 2019, Amazon Web Services, Inc. or its Affiliates. “I

    know how to build a serverless function, now what?”
  3. © 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
  4. © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Declarative I tell you what I need I tell you what to do Imperative
  5. © 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. © 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. © 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. © 2019, Amazon Web Services, Inc. or its Affiliates. Use

    SAM CLI to package and deploy SAM templates pip install --user aws-sam-cli 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. © 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. © 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. © 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. © 2019, Amazon Web Services, Inc. or its Affiliates. Source

    Build Test Production Continuous Integration / Continuous Deployment
  13. © 2019, Amazon Web Services, Inc. or its Affiliates. Serverless

    deployments Code Stack Package Deploy Template
  14. © 2019, Amazon Web Services, Inc. or its Affiliates. Serverless

    deployments with a test environment Code Test Stack Package Deploy Template Feedback Production Stack Deploy
  15. © 2019, Amazon Web Services, Inc. or its Affiliates. CodeDeploy

    – Lambda canary deployment API Gateway Lambda function weighted alias “live” v1 Lambda function code 100%
  16. © 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%
  17. © 2019, Amazon Web Services, Inc. or its Affiliates. CodeDeploy

    – Lambda canary deployment API Gateway Lambda function weighted alias “live” v1 code 90% Wait for 10 minutes, roll back in case of alarm v2 code 10%
  18. © 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%
  19. © 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
  20. © 2019, Amazon Web Services, Inc. or its Affiliates. API

    Gateway canary stage API Gateway Production stage v1 code v2 code 99.5% 0.5% Canary stage
  21. © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product
  22. © 2019, Amazon Web Services, Inc. or its Affiliates. v1

    v2 v3 Customer needs Project Product
  23. © 2019, Amazon Web Services, Inc. or its Affiliates. Project

    Product Reach milestone Customer value Lifecycle costs Cost to reach milestone Backward looking Forward looking
  24. © 2019, Amazon Web Services, Inc. or its Affiliates. Product

    Features Defects Risks Debts Product development Business Customers Security & Compliance Developers & Architects Avoid Overutilization
  25. © 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
  26. © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product
  27. © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices
  28. © 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
  29. © 2019, Amazon Web Services, Inc. or its Affiliates. Use

    the right integration pattern ✓ Decouple and scale distributed systems ✓ Decouple producers from subscribers ✓ Combine multiple tasks and manage distributed state Message queue Pub/sub messaging Workflows Amazon SQS Amazon SNS AWS Step Functions
  30. © 2019, Amazon Web Services, Inc. or its Affiliates. Understand

    latency Systems Performance by Brendan Gregg
  31. © 2019, Amazon Web Services, Inc. or its Affiliates. Understand

    latency and percentiles P100 | P99 | P90 | P50
  32. © 2019, Amazon Web Services, Inc. or its Affiliates. Think

    event-driven – Serverless by Design https://sbd.danilop.net – https://github.com/danilop/ServerlessByDesign
  33. © 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
  34. © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices
  35. © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices Focus on your team
  36. © 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
  37. © 2019, Amazon Web Services, Inc. or its Affiliates. Team

    size & communication paths = "(" − 1) 2 Communication paths in a team of N people
  38. © 2019, Amazon Web Services, Inc. or its Affiliates. Two

    pizza teams Photo by Kristina Bratko on Unsplash
  39. © 2019, Amazon Web Services, Inc. or its Affiliates. Separable

    Vs complex tasks Separable task Complex task
  40. © 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 – …
  41. © 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 }
  42. © 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 }
  43. © 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
  44. © 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
  45. © 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
  46. © 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: [email protected]
  47. © 2019, Amazon Web Services, Inc. or its Affiliates. Infrastructure

    as code Automate deployments Project to product Event-driven microservices Focus on your team
  48. © 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
  49. © 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
  50. © 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
  51. © 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
  52. © 2019, Amazon Web Services, Inc. or its Affiliates. “Experiments

    demonstrate a reduction of ∼50% in total running time on AWS Lambda, compared to state-of-the-art distributed optimization schemes.” https://arxiv.org/abs/1903.08857 Running on AWS Lambda
  53. © 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
  54. © 2019, Amazon Web Services, Inc. or its Affiliates. Positive

    Chat https://pchat.demo.danilop.net/?room=VoxxedMilano D em o
  55. © 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
  56. © 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
  57. © 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
  58. © 2019, Amazon Web Services, Inc. or its Affiliates. ©

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