AWS re:Invent 2016: Born in the Cloud; Built Like a Startup (ARC205)

304 views

Published on

This presentation provides a comparison of three modern architecture patterns that startups are building their business around. It includes a realistic analysis of cost, team management, and security implications of each approach. It covers Elastic Beanstalk, Amazon ECS, Docker, Amazon API Gateway, AWS Lambda, Amazon DynamoDB, and Amazon CloudFront, as well as Docker.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
304
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
43
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

AWS re:Invent 2016: Born in the Cloud; Built Like a Startup (ARC205)

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Paul Underwood, Solution Architect, AWS Keith Horwood, CEO and Founder, Polybit November 29, 2016 Born in the Cloud Built like a Startup ARC205
  2. 2. What to Expect from the Session How to think like a startup when deploying your next workload on AWS. Whether you work for an enterprise or a small business.
  3. 3. What to Expect from the Session My expectations: • 100-level AWS constructs • Familiarity with AWS services
  4. 4. What to Expect from the Session My expectations: • 100-level AWS constructs • Familiarity with AWS services Architectures we will cover: • N-tier • Containerized • Serverless Implications on: • Cost • Performance • Team structure
  5. 5. What to Expect from the Session My expectations: • 100-level AWS constructs • Familiarity with AWS services Architectures we will cover: • N-tier • Containerized • Serverless Implications on: • Cost • Performance • Team structure Deep dive w/ Polybit: • Practical DevOps techniques in an increasingly serverless world
  6. 6. What are startups thinking about? Expecting scale Focus on features Lean IT department Low cost == Long runway
  7. 7. Isn't everybody?
  8. 8. What else are we thinking about? Reliability Performance Cost efficiency Security
  9. 9. Can building like a startup align these goals? Reliability Performance Cost efficiency Security Expecting scale Focus on features Lean IT department Low cost == Long runway
  10. 10. OK, so how have people done this historically?
  11. 11. Using these kinds of frameworks…
  12. 12. How? Monolithic/N-tier architectures Data Center 1 Your infrastructure provider Data Center 2 Load Balancer DB Master DB Stby App Server App Server
  13. 13. How do startups do this on AWS? git clone git://myrepo && cd myrepo eb init eb create prod pg_restore -v –h mydb.rds.amazonaws.com latest.dump eb setenv SHARED_KEY_OF_SOME_SORT=34dsa…2x32vxj /// Changes eb create test git add . && git commit -m “profound change“ eb deploy /// Test eb switch prod && eb deploy
  14. 14. ExampleApp-Test This gets us VM-based N-tier on AWS ExampleApp-Prod Availability Zone A Availability Zone B Elastic Load Balancing EC2 RDS Stby EC2
  15. 15. ExampleApp-Test Plus some significant benefits ExampleApp-Prod Availability Zone A Availability Zone B ELB EC2 RDS Stby EC2 Amazon CloudWatch • Service-wide resource monitoring • Log management AWS Security • Identity and access management • VPC networking Specialist services • Block/object storage • Caching • DNS
  16. 16. ExampleApp-Test The quickest path to best practices AWS Elastic Beanstalk – Making N-Tier Easier ExampleApp-Prod Availability Zone A Availability Zone B ELB EC2 RDS Stby EC2 AWS Elastic Beanstalk • Builds you into best practices from the start • Integrates with developer workflows • Use the Elastic Beanstalk Command Line Interface Amazon CloudWatch • Service-wide resource monitoring • Log management AWS Security • Identity and access management • VPC networking Specialist Services • Block/Object Storage • Caching • DNS
  17. 17. What does this cost? “Development-grade” stack “Production-grade” stack Tier Spec Monthly Cost Load Balancer 1x $18.30 Application Server 1 x t2.micro $9.52 Database Server 1 x t2.micro 100 GB $23.95 Total Monthly $51.77 Tier Spec Monthly Cost Load Balancer 1x $18.30 Application Server 2 x m4.large $121.18 Database Server 2 x m4.large 100 GB $198.93 Total Monthly $320.11
  18. 18. Containerized Architectures
  19. 19. Containers in theory look like conventional N-tier VM-based N-tier Container-based N-tTier Web Server Web Server ELB Web Server Web Server DBStby Hypervisor Cont. InstancesCont. InstancesCont. Instances
  20. 20. In practice, leverage the platform VM-based N-tier Amazon ECS-based N-tier Web Server Web Server ELB Web Server Web Server DBStby Hypervisor Cont. InstancesCont. InstancesCont. Instances Application Load Balancer RDS Standby RDS Master
  21. 21. How startups are building containers on AWS ## set up aws ecs get-login docker build –t <tagName> . docker tag <tagName>:latest <repoUrl>/<tagName>:latest ecs-cli configure --region us-west-2 --cluster <clusterName> ecs-cli up --keypair <keyPairID> --capability-iam --size 2 --type … ## auto-generate service and task definition, no ALB, no ASG ecs-cli compose service create --file docker-compose.yml ecs-cli compose service start ## instead, use ECS to define more sophisticated services aws ecs create-service --service-name <serviceName> --cli-input-json file://sophisticated-service-def.json
  22. 22. What does ECS give us? Scheduler Cont. InstancesCont. InstancesCont. Instances Application Load Balancer RDS Standby RDS Master Container Registry Dockerfiles docker-compose.yml Services/tasks *Amazon RDS managed
  23. 23. But what about? Scheduler Cont. InstancesCont. InstancesCont. Instances Service discovery Container instance scaling Container Registry Dockerfiles docker-compose.yml Services/tasks Container-level logging Application Load Balancer RDS Standby
  24. 24. What does this cost? “Production-grade” Amazon EC2 stack (40% utilization)Tier Spec Monthly Cost Load Balancer 1x $18.30 Application Server 2 x m4.large $121.18 Database Server 2 x m4.large 100 GB $198.93 Total Monthly $320.11 “Production-grade” ECS stack (80% utilization) Tier Spec Monthly Cost Load Balancer 1x $18.30 Container Instances 2 x m4.large $121.18 Database Server 2 x m4.large 100 GB $198.93 Total Monthly $320.11
  25. 25. N-tier/Container DevOps The Stack Challenge
  26. 26. Opinion time: Traditional VM and container architectures are rooted in emulating classic physical servers…
  27. 27. … and therefore inherit the Stack Challenge Whose responsibility is? • Server-level configuration: • Packages/dependencies • Users/groups • Build sources • Files • Bootstrapping commands • Services • Security • Cluster-level configuration • Container instances • Supporting core services
  28. 28. The Stack Challenge Whose responsibility is? • Server-level configuration: • Packages/dependencies • Users/groups • Build sources • Files • Bootstrapping commands • Services • Security • Cluster-level configuration • Container instances • Supporting core services Tooling can get you so far… Eventually, you need DevOps staff…
  29. 29. Why??? Developer DevOps Engineer !=
  30. 30. What is that rushing sound? Dev Test Ops Main. Feature 1 Feature 2 Feature 0
  31. 31. Meanwhile, back at the lab…
  32. 32. Thinking big, inventing, simplifying Traditional VM and container architectures are rooted in emulating classic physical servers. Why should anyone care about servers? Feature development is far more valuable than solving server-centric stack challenges. Why can’t things just scale automatically?
  33. 33. Historical perspective… 2006 EC2 2009 ELB 2010 RDS 1946 ENIAC Monolithic Cloud VMs 2013 Docker 1979 chroot process isolation Containers Tipping point for “modern” startup adoption What’s next? Server-Centric Architecture
  34. 34. Serverless
  35. 35. A serverless web application architecture Images/Video HTML/CSS/JS Static Asset Requests Angular/SPA Amazon CloudFront/ Amazon S3 Desktop *aaS Mobile
  36. 36. A serverless web application architecture Images/Video HTML/CSS/JS Static Asset Requests Dynamic RequestsAWS Lambda Angular/SPA Amazon API Gateway Amazon CloudFront/ Amazon S3 api.example.com Desktop *aaS Mobile
  37. 37. A serverless web application architecture Images/Video HTML/CSS/JS Static Asset Requests Dynamic RequestsAWS Lambda Amazon DynamoDB Persistence/Database Angular/SPA Amazon API Gateway Amazon CloudFront/ Amazon S3 api.example.com Desktop *aaS Mobile
  38. 38. How to do this on AWS? Flourish
  39. 39. What does this cost? Imagine the following daily customer usage pattern: Cost per user/month: Assumption Unit Total Pages / Day 10 Avg Size of Page 200 kb API Requests / Page 5 Avg size of API Req 4 kb DB Ops per API Req 2 1r/1w Storage (per month) 500 kb Charge Monthly Cost CloudFront Data Transfer 0.0051 CloudFront Request Pricing 0.0003 S3 Request Pricing (15% cache-hit) 0.00102 S3 Data Transfer 0.004335 API Gateway Data Transfer 0.00054 API Gateway Request Pricing 0.00525 Lambda Request Pricing 0.0003 Lambda Duration Cost 0.000312 DynamoDB IO Pricing 0 DynamoDB Storage 0.000125 Total Monthly Cost / User $0.017282
  40. 40. Microservice thinking
  41. 41. Through a microservice lens on Day 0 Images/Video HTML/CSS/JS Service 0: CoreSiteAWS Lambda DynamoDB Angular/SPA API Gateway CloudFront/S3 Dev Test Ops Main.
  42. 42. As microservice complexity scales… Images/Video HTML/CSS/JS Service 1: CoreSite API AWS Lambda DynamoDB Angular/SPA API Gateway CloudFront/S3 Dev Test Ops Main. Service 0: CoreSite FrontEnd Service Mitosis @ 2 Pizzas
  43. 43. …and so on…
  44. 44. Let your teams pick the right tools for the job Service 0 Service 2 Service 1 Dev Test Ops Main. Dev Test Ops Main. Dev Test Ops Main.
  45. 45. Let your teams pick the right tools for the job Core Svcs Service 0 Service 2 Service 1 Route 53 DNS API Gateway Account Mgmt Dev Test Ops Main. Dev Test Ops Main. Dev Test Ops Main.
  46. 46. Let your teams pick the right tools for the job Core Svcs Service 0 Service 2 Service 1 Route 53 DNS API Gateway Account Mgmt Dev Test Ops Main. Dev Test Ops Main. Dev Test Ops Main. Big Data Amazon EMR Amazon Kinesis Amazon Redshift Mobile/UX Amazon Cognito Amazon Mobile Analytics AWS Mobile Hub
  47. 47. So, we understand N-tier and container DevOps Core Svcs Service 0 Service 2 Service 1 Route 53 DNS API Gateway Account Mgmt Dev Test Ops Main. Dev Test Ops Main. Dev Test Ops Main. Big Data Amazon EMR Amazon Kinesis Amazon Redshift Mobile/UX Amazon Cognito Amazon Mobile Analytics AWS Mobile Hub VM Based N-Tier Service Dockerized Service Dev Test Ops Main. Dev Test Ops Main.
  48. 48. What about DevOps in a serverless world? Core Svcs Service 0 Service 2 Service 1 Route 53 DNS API Gateway Account Mgmt Dev Test Ops Main. Dev Test Ops Main. Dev Test Ops Main. Big Data Amazon EMR Amazon Kinesis Amazon Redshift Mobile/UX Amazon Cognito Amazon Mobile Analytics AWS Mobile Hub Serverless Service Dev Test Ops Main.
  49. 49. Unlocking Practical Serverless Development
  50. 50. So you want to go serverless… Scalability Decreased cost UNIX philosophy Organizational Compartmentalization
  51. 51. AWS: The system architecture of the web
  52. 52. Organizational tooling for serverless - Sharing - Discovery - Environments - Deployment pipelines - Microservice versioning - Legacy app interoperability
  53. 53. Discover, create, manage services https://github.com/poly/stdlib Install CLI $ npm install lib –g Initialize Workspace $ lib init Create Service $ lib create Test Service Locally $ f . Deploy Service [dev] $ lib up dev Test Service Remotely $ f username/service@dev
  54. 54. Discover, create, manage services https://stdlib.com/search
  55. 55. Sharing and discovery DNS (Route 53) Gateway (API Gateway) Client Request https://f.yourdomain.com/your-service your-service (Lambda)
  56. 56. Environment and deployment MY_VARIABLE=test STRIPE_API_KEY=watlol DATABASE_URL=localhost // load .env files require(‘dotenv’); const stripe = require(‘stripe’); // do something process.env.STRIPE_API_KEY .env index.js
  57. 57. Environment and deployment - package.json - .dev.env - .staging.env - .prod.env - .gitignore - index.js files $ deploy-command --env prod deploy - package.json - .env - index.js
  58. 58. Environment and deployment $ deploy-command --env prod deploy - package.json - .env - index.js your-service_prod (Lambda)
  59. 59. Microservice versioning Client Request your-service/VERSION your-service:VERSION (Lambda)
  60. 60. Microservice versioning $ deploy-command --version VER deploy {“Publish”: true} your-service:Number (Lambda) {“Version”: Number} createAlias “VER” :: Number
  61. 61. Microservice versioning $ deploy-command --version 1.0.0 deploy {“Publish”: true} your-service:NUMBER (Lambda) {“Version”: “NUMBER”} Mapping: “1.0.0” :: Number
  62. 62. Microservice versioning DNS (Route 53) Gateway (Elastic Beanstalk) Client Request your-service/VERSION your-service (Lambda) Version Mapping (DynamoDB)
  63. 63. Legacy app interoperability aws-sdk lambda.invoke(…) http f.yourdomain.com/(…)
  64. 64. Organizational tooling for serverless - Sharing - Discovery - Environments - Deployment pipelines - Microservice versioning - Legacy app interoperability
  65. 65. Organizational tooling for serverless Route 53 API Gateway Lambda EBS DynamoDB Node.js: “dotenv”… CLI tools...
  66. 66. One organizational solution Test Service Locally $ f . Deploy Service [dev] $ lib up dev Test Service Remotely $ f username/service@dev - Sharing - Discovery - Environments - Deployment pipelines - Microservice versioning - Legacy app interoperability https://github.com/poly/stdlib
  67. 67. https://stdlib.com/reinvent-2016 @polybit @keithwhor Your Library for Microservices
  68. 68. Final thought…
  69. 69. A well-defined microservice implies its own architecture Reliability Performance Cost efficiency Security Expecting scale Focus on features Lean IT department Low cost == Long runway
  70. 70. Thank you! Paul Underwood – paulu@amazon.com Keith Horwood – keith@polybit.com Please don’t forget to fill out your survey!

×