Download as PDF, PPTX
Uploaded byBoaz Ziniman
Microservices and Serverless for Mega Startups - DevOps IL Meetup
1) The document discusses best practices for running microservices at scale, including breaking monolithic architectures into loosely coupled microservices, using the right tools for each job, securing services, focusing on organizational transformation, and automating everything. 2) Five principles for running microservices are outlined: microservices only rely on each other's public APIs, using the right tool for the job, securing services with defense-in-depth, focusing on cross-functional teams for alignment, and automating everything. 3) Examples of event-driven serverless architectures using AWS Lambda and other AWS services are provided.
More Related Content
Similar to Microservices and Serverless for Mega Startups - DevOps IL Meetup
![Jumpstart your idea with AWS Serverless [Oct 2020]](https://cdn.slidesharecdn.com/ss_thumbnails/jumpstartyourideawithawsserverlessoct2020-240904053409-07f4072b-thumbnail.jpg?width=640&height=640&fit=bounds)
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Microservices and Serverless for Mega Startups - DevOps IL Meetup
- 1.
- 2. About me • TechnicalEvangelist 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 theMonolith • An Introduction to Microservices • Who needs servers? • Lambda and Serverless on AWS • 5 Principals for running Microservices at scale
- 4. Migrating from Monolith toMicroservice
- 5.
- 6. Challenges with monolithicsoftware 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 deliverypipeline app (aka the “monolith”) developers
- 8. Too much softwarecoupling 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 thathave bounded contexts” Adrian Cockcroft (VP of Cloud Architecture @ AWS, former Cloud Architect at Netflix)
- 14. “service-oriented architecture composed of loosely coupled elements thathave 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 thathave 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 thathave 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 TonyWalmsley: 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”
- 21. = 50 milliondeployments a year Thousands of teams × Microservice architecture × Continuous delivery × Multiple environments (5708 per hour, or every 0.63 second)
- 22. Servers How will theapplication 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!!)
- 23. What is serverless? Build andrun applications without thinking about servers
- 24. Let’s take alook at the evolution of computing Physical Servers Datacenters Virtual Servers Datacenters Virtual Servers in the cloud
- 25. Each progressive stepwas 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
- 26. But there arestill 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
- 27. Evolving to serverless SERVERLESS Virtual servers inthe cloud Physical servers in datacenters Virtual servers in datacenters
- 28. No server iseasier to manage than any server All of these responsibilities go away Provisioning and utilization Availability and fault tolerance Scaling Operations and management
- 29. Serverless with AWSLambda
- 30. EVENT DRIVEN CONTINUOUSSCALING PAY BY USAGE Deliver on demand, never pay for idle
- 31. No servers toprovision or manage Scales with usage Never pay for idle Availability and fault tolerance built in Benefits of Lambda and serverless compute
- 32.
- 33. Using AWS Lambda Bringyour 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 …and GO 3 GB
- 34. Using AWS Lambda Authoringfunctions • 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
- 35. Amazon S3 Amazon DynamoDB Amazon Kinesis AWS CloudFormation AWSCloudTrail 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
- 36.
- 37. 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
- 38. Common use cases WebApplications 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 </></>
- 39. 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
- 40. 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
- 41. Customers innovating withserverless
- 42.
- 44. 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
- 45. 5. 6. 5. FB Login (optional) HitsFacebook 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
- 46. 9. Submit details APIGateway 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
- 47. Principle 1 Microservices only relyon 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/)
- 48. Microservice A MicroserviceB public API Principle 1: Microservices only rely on each other’s public API public API
- 49. public API Microservice AMicroservice B Principle 1: Microservices only rely on each other’s public API public API
- 50. public API publicAPI Nope! Microservice A Microservice B Principle 1: Microservices only rely on each other’s public API
- 51. 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
- 52. Principle 2 Use theright 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/)
- 53. public API Microservice AMicroservice B Amazon Elasticsearch Service RDS Aurora DynamoDB public API Principle 2: Use the right tool for the job
- 54. public API RDS Aurora Microservice AMicroservice B Amazon Elasticsearch Service DynamoDB public API Principle 2: Use the right tool for the job
- 55. Principle 3 Secure YourServices “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/)
- 56. Principle 3: SecureYour 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
- 57. Principle 4 More thanjust 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/)
- 58. “Any organization thatdesigns a system will produce a design whose structure is a copy of the organization’s communication structure.” Melvin E. Conway, 1967 Conway’s Law
- 59. 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
- 60. 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
- 61. 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
- 62. 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
- 63. 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
- 64. Image from MartinFowler’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
- 65. Principle 5 Automate Everything “Robot” by RobinZebrowski. 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/)§
- 66. Focused agile teams deliverypipeline service releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild releasetestbuild 2-pizza team
- 67. Principle 6: Automateeverything AWS CodeCommit AWS CodePipeline AWS CodeDeploy EC2 ELB Auto ScalingLambdaECS DynamoDBRDS ElastiCache SQS SWF SES SNS API GatewayCloudWatch Cloud Trail KinesisElastic Beanstalk
- 68. It’s a journey… Expectchallenges 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
- 69. Benefits of Microservices Rapid Build/Test/Release Cycles Clearownership 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
- 70. AWS resources: • Microserviceswithout 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
- 71.