AWS re:Invent 2016: Getting Started with Serverless Architectures (CMP211)
•
12 likes•2,117 views
Serverless architectures let you build and deploy applications and services with infrastructure resources that require zero administration. In the past, you had to provision and scale servers to run your application code, install and operate distributed databases, and build and run custom software to handle API requests. Now, AWS provides a stack of scalable, fully-managed services that eliminates these operational complexities. In this session, you learn about the concepts and benefits of serverless architectures and the basics of the serverless stack AWS provides (e.g., AWS Lambda and Amazon API Gateway). We discuss use cases such as data processing, website backends, serverless applications and "operational glue". After that, you get practical tips and tricks, best practices, and architecture patterns that you can take back and implement immediately.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to AWS re:Invent 2016: Getting Started with Serverless Architectures (CMP211)
Similar to AWS re:Invent 2016: Getting Started with Serverless Architectures (CMP211) (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
AWS re:Invent 2016: Getting Started with Serverless Architectures (CMP211)
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Jeremy Edberg, Founder and CEO, MinOps December 2016 CMP211 Getting Started with Serverless Architectures
- 3. Test and prod are different Prod is in need of constant updates Slow iteration and deployment Polyglot unfriendly Deploy in weeks, live for years Physical Servers
- 4. Prod is immutable Rapid iteration and deployment Multi-tenancy Polyglot friendly Deploy in minutes, live for weeks Virtual Machines
- 5. Test and prod are the same Prod is immutable Rapid(er) iteration and deployment High multi-tenancy Polyglot friendly Deploy in seconds, live for hours Containers
- 6. Smallest unit of compute Super scalable Rapid iteration Extreme multi-tenancy Very polyglot friendly Easier to collaborate Deploy independently, live for seconds Serverless
- 7. A whole lot of choices Amazon ecosystemHodgepodge of services
- 8. A whole lot of choices
- 10. Continuous scaling No servers to manage Never pay for idle – No cold servers (only happy accountants) Benefits of AWS Lambda
- 11. Lambda is a core component of modern software
- 12. What is serverless anyway? • There are still servers, you just don’t manage them anymore • It also means you don’t access them anymore • So you don’t need to (or get to) optimize them.
- 13. What is Serverless Computing? • VMs • Machine as the unit of scale • Abstracts the hardware • Containers • Application as the unit of scale • Abstracts the OS • Serverless • Functions as the unit of scale • Abstracts the language runtime EC2 ECS Lambda
- 14. How do I choose? • VMs • “I want to configure machines, storage, networking, and my OS” • Containers • “I want to run servers, configure applications, and control scaling” • Serverless • “Run my code when it’s needed” EC2 ECS Lambda
- 15. What if I buy my own software? Lambda is so flexible you can add it in or around existing software
- 16. Serverless computing is all about speeding up development by allowing rapid iteration and removing management overhead
- 17. A brief journey through history
- 18. 80’s Mainframe Cycle • Cost $1MM to $100MM • 1 to 5 years to execute • Usually had to bet the whole company • Cost of failure -- Bankruptcy
- 19. 90‘s Client/Server Cycle • Cost $100K to $10MM • 3 to 6 months to execute • Usually had to bet a product or division • Cost of failure -- Revenue hit, CXX job
- 20. 00‘s Agile Cycle • Cost $10K to $1MM • 3 to 6 weeks to execute • Bet a product feature • Cost of failure -- product manager reputation
- 21. Product Manager Developer QA Ops BI / Analytics
- 22. Cost and size of risk decreased Rate of change increased
- 26. Multiple services Internal Microservices Platform Monolithic Success follows a standard pattern
- 28. Distributed Computing and a Distributed Workforce • The two go hand in hand when you have a good distributed systems culture • Microservices and micro teams
- 29. Cloud Native 10s of thousands of instances, thousands created and removed daily Thousands of storage nodes, petabytes of data, nodes can be removed without harm (Some folks call this microservices)
- 30. Movie Ratings Personalization Engine User Info Movie Metadata Similar Movies Reviews A/B Test Engine Discovery API Streaming API
- 31. Movie Ratings Personalization Engine User Info Movie Metadata Similar Movies Reviews A/B Test Engine Discovery API Streaming API Content Encoding CDN Management QOS Logging DRM OpenConnect Edge Locations Browse Play Watch
- 32. • Services are built by different teams who work together to figure out what each service will provide. • The service owner publishes an API that anyone can use and returns proper response codes Highly aligned, loosely coupled
- 33. Developers own their product from beginning to end If the customer isn’t happy, the developer shouldn’t be happy Freedom and Responsibility
- 35. Mature companies spend 25% of their engineering resources on their internal platform
- 36. And they’re all building the same thing… Wasting time and effort they could be spending on product innovation
- 38. And when you’re done, it is only “good enough” Building an internal microservices platform is hard
- 39. So why go Serverless?
- 42. Security • Shorter TTL == less chance for an attack to take hold
- 44. Microservices Management Tools Web servers Code Libraries Frameworks Config Management API Management Deployment, CI/CDContainers etc. etc. etc.
- 45. What do all the parts of microservices have in common?
- 46. Servers Capacity planning Right-sizing Automatic scaling Load and performance Patches Tuning Configuration Utilization Access control Packages and AMIs
- 47. Serverless Right-sizing Automatic scaling Load and performance Patches Tuning Configuration Utilization Access control Packages and AMIs Fully managed Continuous Scaling Function is the deployment unit Capacity planning
- 49. Microservice problems we still have Queue length Persistent storage Fallbacks and graceful degradation Monitoring and alerting Integration and deployment Testing
- 50. What does Lambda do for you? • Scales server capacity automatically • API to trigger execution • Ensures function is executed in parallel and at scale • Logging, monitoring, etc. • Easy pricing
- 51. Monitoring • Everything is in CloudWatch or CloudWatch logs
- 52. Pricing • Choose your RAM from 128 MB to 1500 MB • CPU and network scaled based on RAM
- 53. Cost Comparison
- 54. Cost Comparison There’s about 2.5M seconds in a month, so 3M requests is about 1.2 per second The T2.Small is $18.98 a month, more than Lambda already
- 55. Pay per Request • Buy compute in 100ms increments • Low request charge • No minimums • No per-device fees Never pay for idle time! Free Tier 1,000,000 requests and 400,000 GB every month, every customer
- 56. How does one use ?
- 57. Author your code • AWS SDK built-in • Access to /tmp, processes, threads, etc. • Node.js, Python • Java and any JVM language • Use any library you want
- 58. Choose an event source • S3 • Amazon Kinesis • SNS • DynamoDB • CloudWatch • Config Rules • Amazon Echo • API Gateway • Lambda functions • SES • Cognito • CloudFormation • CodeCommit • Echo • Scheduled events
- 59. Choose your resources • Select from 128 MB to 1.5 GB • CPU and network are chosen automatically • Pay only for what you actually use
- 60. Choose your authorization model • Securely grant access to resources and VPC • Fine-grained control over who calls your functions with IAM
- 61. Choose a Network • Default • All functions have internet access • No access to your other VPCs • Still in a VPC • Customer VPC • Private communication within your VPC • Same configuration as your other VPCs (ENI, route table, security groups, NAT)
- 62. Deploy your code • Use the GUI or • Upload to S3 or Lambda directly • Use a third party tool
- 63. Write the function Create the IAM role Add extra permissions for a push model Zip the function and dependencies Test the function with mock data Add an event source to the function View the output of the live function
- 64. Write the function Create the IAM role Add extra permissions for a push model Zip the function and dependencies Test the function with mock data Add an event source to the function View the output of the live function minops.com/oss Use a tool
- 65. Polish Deep Integration Language Support API Gateway Support Notes Kappa Meh Best Meh No Best for Python, same author as boto Apex Great Ok Best No Ties into Terraform Serverless (Jaws) Great Good Good Yes Uses Cloudformation Chalice Great Ok Only Python Yes Great for REST APIs Serverless Ex press Great Only w/ API Gateway Only NodeJS Yes Built by AWS
- 66. Create a unified API frontend for multiple microservices DDoS protection and throttling for backend systems Authenticate and authorize requests Benefits of Amazon API Gateway
- 67. Lambda Use Cases • Application Backend • Data Processing • Command and Control • Any functional or event based system
- 68. Data Processing Upload to S3 S3 Bucket Lambda S3 Notification Compressed Image Compress Image Upload back to S3
- 69. Serverless Website Static Content Dynamic Content API Gateway Lambda DynamoDB
- 70. Internet Mobile Apps Websites Services AWS Lambda functions API Gateway Cache Endpoints on Amazon EC2 Any other publicly accessible endpoint Amazon CloudWatch Amazon CloudFront Amazon API Gateway Serverless API w/ API Gateway
- 71. API Gateway Lambda SNS Mobile Backend
- 72. Kinesis Lambda DynamoDB Real-Time Analytics Engine
- 73. Live video stream processing CloudFront S3 Ingest Lambda functions HQ Copy 480p Transcode 360p Transcode Audio Only Transcode S3 Playback CloudFront streaming Thumbnails
- 74. Word Generator • Generate some number of English looking words using an ngram database • Allow a prefix to be specified https://github.com/jedberg/wordgen
- 82. Alexa and Lambda Demo
- 83. From conception to prod in 5 minutes
- 88. Lambda lets you manage your code and infrastructure in the same place
- 89. Tips and Tricks
- 90. Immutable Data • If you can, write your software such that everything in the cache is immutable.
- 91. Moving data is the single biggest cost your distributed system will incur
- 92. But you need to move data for reliability, so it’s a tradeoff Use queues as often as possible
- 93. 0 10 20 30 40 50 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Cumulative Flow Diagram Items Seconds Arrivals Departures
- 94. Avoiding Infinite Loops • With a distributed team, this is an easy mistake to make • To avoid it, pass a call stack and check for self in the stack
- 95. Store your data properly • No local instance access • Store everything in S3, DynamoDB, or ElastiCache DynamoDB S3
- 96. Function Schedules • Schedule a function to keep it warm if traffic is low • Schedule a function to poll your SQS queues or use a DynamoDB table as a queue and trigger on put • Schedule a function with a more granular timer if one minute isn’t granular enough • Have one function call another to get more timers
- 97. Function Versions • Use the environment variable service for mutable configuration • To rollback, switch to an old alias or an old API Gateway collection • Use a traffic shaping function for Blue / Green deployments • Point directly at an ARN to lock to a particular version
- 98. Lambda VPC Basics • VPC is always on, but with sane defaults • Lambda functions can access your private resources if added to your VPC • But they will lose internet access unless you have a managed NAT, regardless of your internet gateway or permissive security group rules
- 99. Lambda VPC Basics • Make sure you have enough ENIs for max concurrency • And enough IPs in your pool • And enough per AZ
- 100. Amazon API Gateway Best Practices • Use request/response mapping templates everywhere within reason, not passthrough. • Take ownership of HTTP response codes • Use Swagger import/export for cross- account sharing • 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)
- 101. 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.
- 102. Thank you!
- 103. Remember to complete your evaluations!
- 104. Questions? Email: {anything}@jedberg.net Twitter: @jedberg Web: www.jedberg.net Facebook: facebook.com/jedberg Linkedin: www.linkedin.com/in/jedberg Company: minops.com