Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Getting Started with Serverless Architectures


Published on

AWS' philosophy and recommended best practices for building microservices applications, how AWS services like Lambda and API gateway benefit developers building microservices apps, and how customers are using these two and other AWS services to deliver their microservices apps

Published in: Technology

Getting Started with Serverless Architectures

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Vyom Nagrani Manager Product Management, AWS Lambda 30th March, 2016 Getting Started with Serverless Architectures
  2. 2. Agenda  Background  AWS Lambda  Amazon API Gateway  Serverless Architecture Patterns  Serverless Best Practices
  3. 3. Background How serverless architecture patterns with AWS Lambda are the next evolution of application design
  4. 4. The Monolithic Application
  5. 5. The Monolithic Application • Lots of Collateral Damage • All-for-one and one-to-fail • Slipped timelines • Operational issues • Deploy Less Frequently • Less disruption • More time to plan Reduce Risk
  6. 6. Break it apart.
  7. 7. The Monolithic Architecture
  8. 8. The Service Oriented Architecture Presentation Tier Logic Tier Data Tier
  9. 9. The Microservices Architecture
  10. 10. Tools to help this pattern are VAST  Web Servers  Code Libraries  Web Service/Application Frameworks  Configuration Management Tools  API Management Platforms  Deployment Patterns  CI/CD Patterns  Containers  … and so on
  11. 11. AWS has helped too!  Amazon EC2  EC2 Auto-Scaling  AWS Elastic Load Balancer  EC2 Auto-Recovery  AWS Trusted Advisor  AWS Elastic Beanstalk  AWS OpsWorks  AWS EC2 Container Service  Etc. Etc. Etc.
  12. 12. But … many of these tools and innovations are still coupled to a shared dependency…
  13. 13. Servers How will the application handle server hardware failure? How can I control access from my servers? When should I decide to scale out my servers? When should I decide to scale up my servers? What size servers are right for my budget? How much remaining capacity do my servers have? (AAHHHHHHHHH!!)
  14. 14. Architect to be Serverless  Fully Managed  No provisioning  Zero administration  High availability  Developer Productivity  Focus on the code that matters  Innovate rapidly  Reduce time to market  Continuous Scaling  Automatically  Scale up and scale down
  15. 15. Serverless, event-driven compute service Lambda = microservice without servers Enter AWS Lambda
  16. 16. Components of Lambda  A Lambda Function (that you write)  An Event Source  The AWS Lambda Service  The Function Networking Environment
  17. 17. The Lambda Function  Your Code (Java, NodeJS, Python)  The IAM role that code assumes during execution  The amount of memory allocated to your code (affects CPU and Network as well) A valid, complete Lambda function
  18. 18. An Event Source Many AWS services can be an event source today:  S3  Kinesis  SNS  DynamoDB  CloudWatch  Config Rules  Amazon Al  … and many more  …and, of course, Amazon API Gateway (more later)
  19. 19. The AWS Lambda Service  Runs your function code without you managing or scaling servers.  Provides an API to trigger the execution of your function.  Ensures function is executed when triggered, in parallel, regardless of scale.  Provides additional capabilities for your function (logging, monitoring).
  20. 20. The Function Networking Environment  Default - a default network environment within VPC is provided for you  Access to the internet always permitted to your function  No access to VPC-deployed assets  Customer VPC - Your function executes within the context of your own VPC.  Privately communicate with other resources within your VPC.  Familiar configuration and behavior with:  Subnets  Elastic Network Interfaces (ENIs)  EC2 Security Groups  VPC Route Tables  NAT Gateway
  21. 21. “Hold on…”
  22. 22. Lots of existing ways to abstract away servers  SaaS  PaaS  MBaaS  *aaS  Application Engines/Platforms
  23. 23. What’s unique about Lambda?  Abstraction at the code/function level (arbitrary, flexible, familiar)  The security model (IAM, VPC)  The community  Integration with the AWS Service ecosystem!  Scale  Triggers  The pricing model
  24. 24. Continuous Scaling No Servers to Manage Subsecond Metering Benefits of AWS Lambda for building serverless backends 1 2 3
  25. 25. Many Serverless Options on AWS Compute Storage Database Network Gateways Internet of Things Messaging and Queues Machine LearningStreaming Analytics Content Delivery Security User Management Monitoring & Logging
  26. 26. Example Serverless Architecture
  27. 27. PlayOn! Sports – Video stream processing Laptop Encoders HLS S3 Playback VOD Stream mobile client CloudFront Streaming Live stream mobile client CloudFront S3 Ingest 480p Transcode HQ Copy 360p Transcode Audio-only Transcode Thumbnail QOS Analytics Cascading Lambda Functions
  28. 28. But… … in order to utilize Lambda, do I really need to architect event-driven applications? … is there a way I can use this construct to built multi- tier SOA applications?
  29. 29. Enter Amazon API Gateway Create Configure Publish Maintain Monitor Secure
  30. 30. Serverless Architecture Patterns
  31. 31. Microservices
  32. 32. Mobile Backend
  33. 33. Web Applications
  34. 34. Real-time Analytics Engine
  35. 35. Serverless Best Practices
  36. 36. AWS Lambda Best Practices  Limit your function size – especially for Java (starting the JVM takes time)  Node – remember execution is asynchronous.  Don’t assume function container reuse – but take advantage of it when it does occur.  Don’t forget about disk (500MB /tmp directory provided to each function)  Use the included logger (include details from service-provided context)  Create custom metrics (operations-centric, and business-centric)
  37. 37. Amazon API Gateway Best Practices  Use Mock integrations  Combine with Cognito for managed end user-based access control.  Use stage variables (inject API config values into Lambda functions for logging, behavior)  Use request/response mapping templates everywhere within reason, not passthrough.  Take ownership of HTTP response codes  Use Swagger import/export for cross-account sharing
  38. 38. Additional Best Practices  Use strategic, consumable naming conventions (Lambda function names, IAM roles, API names, API stage names, etc.)  Use naming conventions and versioning to create automation.  Externalize authorization to IAM roles whenever possible  Least privilege and separate IAM roles  Externalize configuration – DynamoDB is great for this.  Contact AWS Support before known large scaling events  Be aware of service throttling, engage AWS support if so.
  39. 39. A Call to Action
  40. 40. Let’s build something Serverless … AWS Lambda Function web browser Amazon S3 Amazon API Gateway Dynamic Content Serverless Website Amazon DynamoDB serverless-microservice-using-aws-lambda/
  41. 41. <shameless-pitch> In case you didn’t guess … We’re hiring! Email </shameless-pitch>
  42. 42. Thank you! @vyomnagrani
  43. 43. Demo
  44. 44. Walkthrough of a simple CRUD backend with a RESTful API endpoint using AWS Lambda Amazon API Gateway AWS Lambda Amazon DynamoDB API call from client app Request/Response CRUD Operations
  45. 45. CRUD operations with DynamoDB ‘echo’ and ‘pong’ for testing Error handling for incorrect inputs Execute the operation with the event payload