Introducing to serverless computing and AWS lambda - Israel Clouds Meetup
4 likes310 views
The document presents an introduction to serverless computing and AWS Lambda, highlighting the transition from monolithic applications to microservices architecture. It outlines the challenges associated with monolithic software and explains the benefits of adopting microservices, including agility, ease of maintenance, and rapid innovation. Additionally, it covers the advantages of serverless computing, including reduced management complexity and cost-effectiveness, while emphasizing the importance of security and automation in microservices development.
Introducing to serverless computing and AWS lambda - Israel Clouds Meetup
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Boaz Ziniman - Technical Evangelist, AWS @ziniman Introducing to Serverless computing & AWS Lambda Israel Cloud meetup – September 2017
- 2. About me • Technical Evangelist at AWS • Events & Meetsup • Webinars • Blogs • Community • Social Media • A long history of Web Development, IT and Operations • AWS Customer since 2009
- 3. Agenda • Breaking the Monolith • An Introduction to Microservices • Who needs servers? • Lambda and Serverless on AWS • 5 Principals for running Microservices at scale
- 4. Migrating from Monolith to Microservice
- 6. Challenges with monolithic software Long Build/Test/Release Cycles (who broke the build?) Operations is a nightmare (module X is failing, who’s the owner?) Difficult to scale New releases take months Long time to add new features Architecture is hard to maintain and evolve Lack of innovation Frustrated customers Lack of agility
- 7. Monolith development lifecycle releasetestbuild delivery pipeline app (aka the “monolith”) developers
- 8. Too much software coupling Shared libraries Shared data
- 9. Evolving towards microservices “IMG_1760” by Robert Couse-Baker. No alterations other than cropping. https://www.flickr.com/photos/29233640@N07/14859431605/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 13. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
- 14. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Services communicate with each other over the network Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
- 15. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” You can update the services independently; updating one service doesn’t require changing any other services. Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
- 16. “service-oriented architecture composed of loosely coupled elements that have bounded contexts” Self-contained; you can update the code without knowing anything about the internals of other microservices Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
- 17. “Do one thing, and do it well” “Swiss Army” by by Jim Pennucci. No alterations other than cropping. https://www.flickr.com/photos/pennuja/5363518281/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 18. “Tools” by Tony Walmsley: No alterations other than cropping. https://www.flickr.com/photos/twalmsley/6825340663/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/) “Do one thing, and do it well”
- 19. Anatomy of a Microservice
- 20. Public API POST /restaurants GET /restaurants Application/Logic (code, libraries, etc) Anatomy of a Microservice Data Store (eg, RDS, DynamoDB ElastiCache, ElasticSearch)
- 22. Drivers microservices Payments microservice Location microservices Ordering microservices Restaurant microservice Ecosystem of Microservices
- 25. = 50 million deployments a year Thousands of teams × Microservice architecture × Continuous delivery × Multiple environments (5708 per hour, or every 0.63 second)
- 26. 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!!)
- 27. What is serverless? Build and run applications without thinking about servers
- 28. Let’s take a look at the evolution of computing Physical Servers Datacenters Virtual Servers Datacenters Virtual Servers in the cloud
- 29. Each progressive step was better Physical Servers Datacenters Virtual Servers Datacenters Virtual Servers in the cloud • Higher utilization • Faster provisioning speed • Improved uptime • Disaster recovery • Hardware independence • Trade CAPEX for OPEX • More scale • Elastic resources • Faster speed and agility • Reduced maintenance • Better availability and fault tolerance
- 30. But there are still limitations Physical Servers Datacenters Virtual Servers Datacenters • Trade CAPEX for OPEX • More scale • Elastic resources • Faster speed and agility • Reduced maintenance • Better availability and fault tolerance • Still need to administer virtual servers • Still need to manage capacity and utilization • Still need to size workloads • Still need to manage availability, fault tolerance • Still expensive to run intermittent jobs Virtual Servers in the cloud
- 31. Evolving to serverless SERVERLESS Virtual servers in the cloud Physical servers in datacenters Virtual servers in datacenters
- 32. No server is easier to manage than any server All of these responsibilities go away Provisioning and utilization Availability and fault tolerance Scaling Operations and management
- 33. Serverless with AWS Lambda
- 34. EVENT DRIVEN CONTINUOUS SCALING PAY BY USAGE Deliver on demand, never pay for idle
- 35. No servers to provision or manage Scales with usage Never pay for idle Availability and fault tolerance built in Benefits of Lambda and serverless compute
- 36. How it works?
- 37. Using AWS Lambda Bring your own code • Node.js, Java, Python, C# • Bring your own libraries (even native ones) Simple resource model • Select power rating from 128 MB to 1.5 GB • CPU and network allocated proportionately Flexible use • Synchronous or asynchronous • Integrated with other AWS services Flexible authorization • Securely grant access to resources and VPCs • Fine-grained control for invoking your functions
- 38. Using AWS Lambda Authoring functions • WYSIWYG editor or upload packaged .zip • Third-party plugins (Eclipse, Visual Studio) Monitoring and logging • Metrics for requests, errors, and throttles • Built-in logs to Amazon CloudWatch Logs Programming model • Use processes, threads, /tmp, sockets normally • AWS SDK built in (Python and Node.js) Stateless • Persist data using external storage • No affinity or access to underlying infrastructure
- 39. Amazon S3 Amazon DynamoDB Amazon Kinesis AWS CloudFormation AWS CloudTrail Amazon CloudWatch Amazon Cognito Amazon SNSAmazon SES Cron events DATA STORES ENDPOINTS CONFIGURATION REPOSITORIES EVENT/MESSAGE SERVICES Example event sources that trigger AWS Lambda … and a few more with more on the way! AWS CodeCommit Amazon API Gateway Amazon Alexa AWS IoT AWS Step Functions
- 40. Use cases
- 41. Common use cases Web Applications • Static websites • Complex web apps • Packages for Flask and Express Data Processing • Real time • MapReduce • Batch Chatbots • Powering chatbot logic Backends • Apps & services • Mobile • IoT </></> Amazon Alexa • Powering voice-enabled apps • Alexa Skills Kit IT Automation • Policy engines • Extending AWS services • Infrastructure management
- 42. Common use cases Web Applications and Backends Internet Mobile Apps Websites Services AWS Lambda function AWS API Gateway Cache All publicly accessible endpoints Amazon CloudWatch Monitoring Amazon CloudFront Amazon S3 AWS Lambda function AWS Lambda function Amazon DynamoDB Web Applications • Static websites • Complex web apps • Packages for Flask and Express Backends • Apps & services • Mobile • IoT </></>
- 43. Common use cases Web Applications • Static websites • Complex web apps • Packages for Flask and Express Data Processing • Real time • MapReduce • Batch Chatbots • Powering chatbot logic Backends • Apps & services • Mobile • IoT </></> Amazon Alexa • Powering voice-enabled apps • Alexa Skills Kit IT Automation • Policy engines • Extending AWS services • Infrastructure management Lambda + S3
- 44. Common use cases Web Applications • Static websites • Complex web apps • Packages for Flask and Express Data Processing • Real time • MapReduce • Batch Chatbots • Powering chatbot logic Backends • Apps & services • Mobile • IoT </></> Amazon Alexa • Powering voice-enabled apps • Alexa Skills Kit IT Automation • Policy engines • Extending AWS services • Infrastructure management
- 45. Customers innovating with serverless
- 46. @parallax
- 48. 1. User visits HTTPS GET / S3 with CloudFront 2. CSS & JS HTTPS GET *.js *.css S3 with CloudFront index.html 3. Lang detect API Gateway w/ Lambda HTTPS GET /users/ country HTTPS POST /users/ update 4. User fills details API Gateway w/ Lambda Inserted into DynamoDB PAGE LIFECYCLE
- 49. 5. 6. 5. FB Login (optional) Hits Facebook Hosted Endpoint via Facebook Javascript SDK 6. YouTube YouTube iframe 7. Start recording API Gateway w/ Lambda Responds with S3 upload token Uploads directly to S3 bucket over HTTPS using token 8. Upload recording HTTPS GET api.facebook.com HTTPS GET youtube.com { “email”: “xyz”, “profile_id”: 123 } HTTPS GET /recordings/token HTTPS POST bucket.s3.amazon/UID/ recording-X.mp3 PAGE LIFECYCLE
- 50. 9. Submit details API Gateway w/ Lambda 10. Artwork gen HTTPS POST /users/generate_ artwork API Gateway w/ Lambda. Create image, put on S3, return S3 image URL 11. Artwork display CloudFront w/ S3 HTTPS GET /domain.com/UID.png AddThis.js is populated with the share texts, and includes the S3 URL HTTP GET addthis.com/file.js HTTPS POST /users/ update { url: “domain.com/UID .png” } 12. Social share 13. Social share HTTPS GET https://twitter.com/intent/ tweet?text=XYZ Directly hits the social media service PAGE LIFECYCLE
- 51. Principle 1 Microservices only rely on each other’s public API “Contracts” by NobMouse. No alterations other than cropping. https://www.flickr.com/photos/nobmouse/4052848608/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 52. Microservice A Microservice B public API Principle 1: Microservices only rely on each other’s public API public API
- 53. public API Microservice A Microservice B Principle 1: Microservices only rely on each other’s public API public API
- 54. public API public API Nope! Microservice A Microservice B Principle 1: Microservices only rely on each other’s public API
- 55. storeRestaurant (id, name, cuisine) storeRestaurant (id, name, cuisine) storeRestaurant (id, name, arbitrary_metadata) addReview (restaurantId, rating, comments) storeRestaurant (id, name, arbitrary_metadata) addReview (restaurantId, rating, comments) Version 1.0.0 Version 1.1.0 Version 2.0.0 public API Microservice A Principle 1: Microservices only rely on each other’s public API
- 56. Principle 2 Use the right tool for the job “Tools #2” by Juan Pablo Olmo. No alterations other than cropping. https://www.flickr.com/photos/juanpol/1562101472/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 57. public API Microservice A Microservice B Amazon Elasticsearch Service RDS Aurora DynamoDB public API Principle 2: Use the right tool for the job
- 58. public API RDS Aurora Microservice A Microservice B Amazon Elasticsearch Service DynamoDB public API Principle 2: Use the right tool for the job
- 59. Principle 3 Secure Your Services “security” by Dave Bleasdale. No alterations other than cropping. https://www.flickr.com/photos/sidelong/3878741556/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 60. Principle 3: Secure Your Services • Defense-in-depth • Network level (e.g. VPC, Security Groups, TLS) • Server/container-level • App-level • IAM policies • Gateway (“Front door”) • API Throttling • Authentication & Authorization • Client-to-service, as well as service-to-service • API Gateway: custom Lambda authorizers • IAM-based Authentication • Token-based auth (JWT tokens, OAuth 2.0) • Secrets management • S3 bucket policies + KMS + IAM • Open-source tools (e.g. Vault, Keywhiz) API Gateway
- 61. Principle 4 More than just technology transformation “rowing on the river in Bedford” by Matthew Hunt. No alterations other than cropping. https://www.flickr.com/photos/mattphotos/19189529/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)
- 62. “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” Melvin E. Conway, 1967 Conway’s Law
- 63. Silo’d functional teams à silo’d application architectures Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 64. Silo’d functional teams à silo’d application architectures Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 65. Cross functional teams à self-contained services Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 66. Cross functional teams à self-contained services Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 67. Cross functional teams à self-contained services (“Two-pizza teams” at Amazon) Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html
- 68. Image from Martin Fowler’s article on microservices, at http://martinfowler.com/articles/microservices.html No alterations other than cropping. Permission to reproduce: http://martinfowler.com/faq.html Cross functional teams à self-contained services (“Two-pizza teams” at Amazon) Full ownership Full accountability Aligned incentives
- 69. Principle 5 Automate Everything “Robot” by Robin Zebrowski. No alterations other than cropping. https://www.flickr.com/photos/firepile/438134733/ Image used with permissions under Creative Commons license 2.0, Attribution Generic License (https://creativecommons.org/licenses/by/2.0/)§
- 70. Focused agile teams delivery pipeline service releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild 2-pizza team
- 71. Principle 6: Automate everything AWS CodeCommit AWS CodePipeline AWS CodeDeploy EC2 ELB Auto ScalingLambdaECS DynamoDBRDS ElastiCache SQS SWF SES SNS API GatewayCloudWatch Cloud Trail KinesisElastic Beanstalk
- 72. It’s a journey… Expect challenges along the way… • Understanding of business domains • Coordinating txns across multiple services • Eventual Consistency • Service discovery • Lots of moving parts requires increased coordination • Complexity of testing / deploying / operating a distributed system • Cultural transformation
- 73. Benefits of Microservices Rapid Build/Test/Release Cycles Clear ownership and accountability Easier to scale each individual microservice New releases take minutes Short time to add new features Easier to maintain and evolve system Faster innovation Delighted customers Increased agility
- 74. AWS resources: • Microservices without the Servers https://aws.amazon.com/blogs/compute/ microservices-without-the-servers • Microservices with ECS: https://aws.amazon.com/blogs/compute/using-amazon- api-gateway-with-microservices-deployed-on-amazon- ecs/ • Serverless Service Discovery: https://aws.amazon.com/blogs/developer/ serverless-service-discovery-part-1-get-started/ • ECS Service Discovery: https://aws.amazon.com/blogs/compute/ service-discovery-an-amazon-ecs-reference- architecture/ • Serverless Webapp - Reference Architecture: https://github.com/awslabs/lambda-refarch-webapp • Zombie Microservices Workshop: https://github.com/awslabs/aws-lambda-zombie- workshop Popular open-source tools: • Serverless – http://serverless.com • Apex - http://apex.run/ https://aws.amazon.com/devops/ Additional Resources