Born in the Cloud; Build it Like a Startup
•
3 j'aime•854 vues
by Rich Cowper, Manager of Solution Architecture, AWS
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Born in the Cloud; Build it Like a Startup
Similaire à Born in the Cloud; Build it Like a Startup (20)
Plus de Amazon Web Services
Plus de Amazon Web Services (20)
Dernier
Dernier (20)
Born in the Cloud; Build it Like a Startup
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Rich Cowper; Solutions Architect November 30th, Born in the Cloud Build it like a startup
- 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. What to Expect from the Session My Expectations: • 100 Level AWS constructs • Familiarity with AWS services
- 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. 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
- 6. What are startups thinking about? Expecting scale Focus on features Lean IT department Low Cost == Long Runway
- 8. What else are we thinking about? Reliability Performance Cost Efficiency Security
- 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. OK, so how have people done this historically?
- 11. Using these kinds of frameworks…
- 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. 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. 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. ExampleApp-Test Plus some significant benefits… ExampleApp-Prod Availability Zone A Availability Zone B ELB EC2 Amazon RDS Stby EC2 AWS Cloud Watch • Service wide resource monitoring • Log management AWS Security • Identity and access management • VPC networking Specialist Services • Block/Object Storage • Caching • DNS
- 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 Amazon 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 AWS Cloud Watch • Service wide resource monitoring • Log management AWS Security • Identity and access management • VPC networking Specialist Services • Block/Object Storage • Caching • DNS
- 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 Concurrent req/sec Benchmark: 100% CPU: 1490 req/sec 40% CPU: 575 req/sec Concurrent req/sec Benchmark: 100% CPU: 977 req/sec 40% CPU: 379 req/sec @0 CPU Credits: 153 req/sec
- 18. Benchmarking the T2.Micro CPU Credit Balance CPU Utilization (1 Hour) Cruising along at 375 req/sec avg Credit Exhaustion ~150 req/sec Higher 500 Rates
- 20. Containers in theory look like conventional N-Tier VM Based N-Tier: Container Based N-Tier: Web Server Web Server ELB Web Server Web Server DBStby Hypervisor Cont. InstancesCont. InstancesCont. Instances
- 21. In practice, leverage the platform… VM Based N-Tier: Amazon Elastic Container Service 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
- 22. How startups are building containers on AWS ## setup 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 aws ecs to define more sophisticated services aws ecs create-service --service-name <serviceName> --cli-input-json file://sophisticated-service-def.json
- 23. 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 *RDS Container-level logging
- 24. But what about? Scheduler Cont. InstancesCont. InstancesCont. Instances Service DiscoveryContainer Registry Dockerfiles docker-compose.yml Services / Tasks Container-level logging Application Load Balancer RDS Standby *RDS RDS Master
- 25. What does this cost? ‘Production-grade’ 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 Concurrent req/sec Benchmark: 100% CPU: 1490 req/sec 40% CPU: 575 req/sec Concurrent req/sec Benchmark: 100% CPU: 1680 req/sec 80% CPU: 1403 req/sec
- 26. N-tier / Container DevOps The Stack Challenge
- 27. Opinion Time: Traditional VM and Container architectures are rooted in emulating classic physical servers…
- 28. … and therefore inherit the Stack Challenge Who's responsibility is? • Server Level Configuration: • Packages/Dependencies • Users/Groups • Build Sources • Files • Bootstrapping commands • Services • Security • Cluster level configuration • Container instances • Supporting core services
- 29. The Stack Challenge Who's 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…
- 31. Meanwhile, back at the lab…
- 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 cant things just scale automatically?
- 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? ServerCentric Architecture
- 34. Serverless
- 35. A serverless web application architecture: Images/Video HTML/CSS/JS Static Asset Requests Angular/SPA Amazon CloudFront / S3 Desktop *aaS Mobile
- 36. A serverless web application architecture: Images/Video HTML/CSS/JS Static Asset Requests Dynamic RequestsAWS Lambda Angular/SPA Amazon API Gateway CloudFront / S3 api.example.com Desktop *aaS Mobile
- 37. A serverless web application architecture: Images/Video HTML/CSS/JS Static Asset Requests Dynamic RequestsAWS Lambda Amazon DynamoDB Persistence / Database Angular/SPA API Gateway CloudFront / S3 api.example.com Desktop *aaS Mobile
- 38. How to do this on AWS? AWS SAM
- 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
- 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. 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. …and so on…
- 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. 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. 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. Final thought…
- 48. A well-defined microservice implies it’s own architecture Reliability Performance Cost Efficiency Security Expecting scale Focus on features Lean IT department Low Cost == Long Runway
- 49. Thank you! Rich Cowper– cowper@amazon.com Please don’t forget to fill out your survey!
Notes de l'éditeur
- Make the point that
- Elasticity makes the difference between dollars a month and thousands a month Managed services simplify your problems Bake in security and DevOps from the start
- Showing how conventional monolithic and n-tier architecture is possible on AWS. Cover region and availability zone here.
- Problems Containers Solve: Simplifies the stack challenge Developer autonomy; less operational friction Resource efficiency Microservice-friendly Portability
- Problems Containers Solve: Simplifies the stack challenge Developer autonomy; less operational friction Resource efficiency Microservice-friendly Portability
- Scheduling Cluster Management Service Discovery Solution for horizontal scale
- Partners such as Consul.io Build your own using ELB, DNS and CloudWatch Events and Lambda functions.
- Describe the stack challenge and how it does not align to these principles. Talk about why monolithic and n-tier is bad.
- Describe the stack challenge and how it does not align to these principles. Talk about why monolithic and n-tier is bad.
- Historically, teams have been segregated by function. Waterfall / Monolithic Dependencies define development Friction between phases Process and standards over invention and simplification
- Essentially showing how long AWS has been around vs containerization and classic monolithic architectures Explain how each major architectural approach has influenced the other At the end of the day, conatiners, vms, or monolithic applications are all server centric and face the stack challenge.
- No severs, no stack challenge Automatic scaling Turn-key reliability Line of sight to price-per-user Service-wide security model
- No severs, no stack challenge Automatic scaling Turn-key reliability Line of sight to price-per-user Service-wide security model
- No severs, no stack challenge Automatic scaling Turn-key reliability Line of sight to price-per-user Service-wide security model
- Individual services are built, tested, operated, and maintained by the same team/developer. No DevOps person responsible.
- Individual services are built, tested, operated, and maintained by the same team/developer. No DevOps person responsible.
- Showing that it will most likely be a mix of Lambda, ECS, EC2 for Api requests, in conjunction with legacy frameworks like wordpress and other higher aws services
- Showing that it will most likely be a mix of Lambda, ECS, EC2 for Api requests, in conjunction with legacy frameworks like wordpress and other higher aws services
- Showing that it will most likely be a mix of Lambda, ECS, EC2 for Api requests, in conjunction with legacy frameworks like wordpress and other higher aws services
- Showing that it will most likely be a mix of Lambda, ECS, EC2 for Api requests, in conjunction with legacy frameworks like wordpress and other higher aws services
- Showing that it will most likely be a mix of Lambda, ECS, EC2 for Api requests, in conjunction with legacy frameworks like wordpress and other higher aws services
- So, after hearing Paul, you’re sold. You want to start using AWS Lambda and developing in a serverless world. It has it all. Scalability beyond your wildest imagination. Decreased cost that maps directly to compute time. Organizational compartmentalization --- teams can work on subsets of application functionality without needing a monolithic application build path. The UNIX philosophy, or atomization --- each service does one thing, and does it really well. Sounds great!
- Before we get into the weeds, let’s take a step back To get one thing out of the way --- at Polybit, we look at AWS as them “System Architecture of the Web” Software-configurable infrastructure, many ways to do many things, but what is the best way? And what do high-level abstractions on top of a “system architecture of the web” look like?
- The technology is great, and we’re ready to hop aboard. But there are a bunch of organizational issues. I’m going to go over ways you can tackle these within your AWS stack, and also how we’re thinking about them and can help you out.
- This is access to all of stdlib’s command line tools These literally just create lambda’s in the cloud that we manage for you so you don’t have to Also accessible on our search page, stdlib.com/search
- Set up Hybrid Gateway with EBS OR Use API Gateway Simple Proxy Mapping all HTTP services to your domain via DNS (Route 53) f.yourdomain.com/doathing/thething Hybrid Gateway can be a simple Node.js app on EBS for handling a lot of async i/o
- Note that we DON’T USE Lambda versioning here. Remember, use .gitignore for environment files We choose to treat them as completely separate Lambdas.
- Note that we DON’T USE Lambda versioning here. Remember, use .gitignore for environment files We choose to treat them as completely separate Lambdas.
- Note that we DON’T USE Lambda versioning here. Remember, use .gitignore for environment files We choose to treat them as completely separate Lambdas.
- Here we do use Lambda versioning You’ll need to save version identifiers from Lambda in a database
- Here we do use Lambda versioning You’ll need to save version identifiers from Lambda in a database
- Here we do use Lambda versioning You’ll need to save version identifiers from Lambda in a database
- Here we do use Lambda versioning You’ll need to save version identifiers from Lambda in a database
- Calling a Lambda function from another application? Use the AWS SDK and invoke OR Request via HTTPS with Gateway we set up
- Think of it like NPM for Remote Procedure Calls to Microservices