Getting Started with Serverless Architectures
•
7 likes•4,328 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 will learn about the benefits of serverless architectures and the basics of the serverless stack AWS provides. We will also walk through how you can use serverless architectures for everything from data processing to mobile and web backends. AWS DevDay San Francisco, June 21, 2016. Presenter: Jeremy Edberg, Co-Founder, CloudNative, & AWS Community Hero
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Getting Started with Serverless Architectures
Similar to Getting Started with Serverless Architectures (20)
More from Amazon Web Services
More from Amazon Web Services (20)
Recently uploaded
Recently uploaded (20)
Getting Started with Serverless Architectures
- 1. Getting Started with Serverless Architectures Email: {anything}@jedberg.net Twitter: @jedberg Web: www.jedberg.net Facebook: facebook.com/jedberg Linkedin: www.linkedin.com/in/jedberg Jeremy Edberg CoFounder https://www.cloudnative.io
- 3. λ
- 4. 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
- 5. Prod is immutable Rapid iteration and deployment Multi-tenancy Polyglot friendly Deploy in minutes, live for weeks Virtual Machines
- 6. 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
- 7. Smallest unit of compute Super scalable Rapid iteration Extreme multi-tenancy Very polyglot friendly Easier to collaborate Deploy independently, live for seconds Serverless
- 8. A whole lot of choices Amazon’s EcosystemHodgepodge of services
- 9. A whole lot of choices
- 11. Continuous scaling No servers to manage Never pay for idle – No cold servers (only happy accountants) Benefits of AWS Lambda
- 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. Serverless computing is all about speeding up development by allowing rapid iteration and removing management overhead
- 16. A brief journey through history
- 17. 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
- 18. 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
- 19. 00‘s Agile Cycle • Cost $10K to $1MM • 3 to 6 weeks to execute • Bet a product feature • Cost of failure -- product manager reputation
- 20. Product Manager Developer QA Ops BI / Analytics
- 21. Cost and size of risk decreased Rate of change increased
- 22. ReleaseTestBuild
- 24. Multiple services Internal Microservices Platform Monolithic Success follows a standard pattern
- 25. Distributed Computing and a Distributed Workforce • The two go hand in hand when you have a good distributed systems culture • Microservices and Micro Teams
- 26. • 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
- 28. Microservices Tools Web Servers Code Libraries Frameworks Config Management API Management Deployment, CI/CDContainers etc. etc. etc.
- 30. What do all the parts of microservices have in common?
- 31. Servers Capacity planning Right-sizing Autoscaling Load and performance Patches Tuning Configuration Utilization Access control Packages and AMIs
- 32. Serverless Right-sizing Autoscaling Load and performance Patches Tuning Configuration Utilization Access control Packages and AMIs Fully managed Continuous Scaling Function is the deployment unit Capacity planning
- 33. What is Lambda? Serverless, event-driven compute service Lambda == microservice without managing servers
- 34. 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
- 35. Monitoring • Everything is in Cloudwatch or Cloudwatch logs
- 36. Pricing • Choose your RAM from 128MB to 1500MB • CPU and Network scaled based on RAM
- 37. Cost Comparison
- 38. 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
- 39. Lambda allows for a tight feedback loop • We turned around both these requests in less than a day
- 40. How does work?λ
- 41. Author your code • AWS SDK built in • Access to /tmp, processes, threads, etc λ • NodeJS, Python • Java and any JVM language • Use any library you want
- 42. Choose an event source • S3 • Kinesis • SNS • DynamoDB • CloudWatch λ • Config Rules • Amazon Echo • API Gateway • Lambda functions • More coming
- 43. 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)
- 44. Deploy your code • Use the GUI or • Upload to S3 or Lambda directly λ
- 46. 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
- 48. 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 https://cloudnative.io/oss/
- 49. Word Generator • Generate some number of English looking words using an ngram database • Allow a prefix to be specified
- 54. Demo
- 56. Call out to other Lambda functions Add their results as attachments to the message router.py
- 57. Demo
- 61. From conception to prod in 5 minutes
- 68. Lambda lets you manage your code and infrastructure in the same place (as long as you use Kappa or something like it).
- 70. Live video stream processing Cloudfront S3 Ingest Lambda Functions HQ Copy 480p Transcode 360p Transcode Audio Only Transcode Thumbnails S3 Playbac k Cloudfront Streaming
- 71. Serverless Website S3 Static Content Dynamic Content API Gateway Lambda DynamoDB
- 72. Use Cases • Application Backend • Data Processing • Command and Control • Any functional or event based system
- 73. Tips and Tricks • Limit your function size (JVM startup time especially) • Remember execution is async • Don’t assume function container reuse but take advantage of it
- 74. Tips and Tricks • Remember the 500MB in /tmp • Use function aliases • Use the included logger
- 75. Tips and Tricks • Set up alarms on all Lambda Cloudwatch metrics • Avoid throttling by using SNS between any service, such as S3 • Beware of infinite loops by having functions call each other.
- 76. Avoiding Infinte 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
- 77. Store your data properly • No local instance access • Store everything in S3, DynamoDB, or Elasticache DynamoDB S3
- 78. • zip up with dependencies • roles and permissions • dev vs prod • aliases Difficulties we’ve solved
- 79. Problems we still have • efficient dependency usage • local dev environments • making sure we have the same dependencies • knowing when someone else is deploying the same function
- 86. Next Steps
- 87. • efficient dependency usage • local dev environments • making sure we have the same dependencies • knowing when someone else is deploying the same function Problems we still have
- 88. • efficient dependency usage • local dev environments • making sure we have the same dependencies • knowing when someone else is deploying the same function Problems we still have
- 89. Testing • You can’t test the network, but a good application test should obviate the need to do so. • Not really a solved problem. Can do local testing. • Can also send json to the function and compare the results.
- 90. Questions? Email: {anything}@jedberg.net Twitter: @jedberg Web: www.jedberg.net Facebook: facebook.com/jedberg Linkedin: www.linkedin.com/in/jedberg Company: cloudnative.io
- 91. Thank You!