Aws for Startups Building Cloud Enabled Apps

2,894 views
2,699 views

Published on

Published in: Technology, Business

Aws for Startups Building Cloud Enabled Apps

  1. 1. Building cloud-enabled apps How to take advantage of the AWS scalability & elasticity Andreas Chatzakis – Solutions Architect @achatzakis AWS for Startups London, 12th September 2013
  2. 2. Agenda • Intro: AWS foundation • Scalability: from a single server to multiple instances • Autoscaling: pay only for what you use • Database: scaling relational or NoSQL DBs • Agility: not servers => software components
  3. 3. Intro
  4. 4. Utility computing On demand Pay as you go Uniform Available
  5. 5. On demand Pay as you go Uniform Available Utility computing
  6. 6. Utility computing
  7. 7. Compute Storage Security Scaling Database Networking Monitoring Messaging Workflow DNS Load Balancing BackupCDN On demand Pay as you go Uniform Available Utility computing
  8. 8. US-WEST (Oregon) EU-WEST (Ireland) ASIA PAC (Tokyo) US-WEST (N. California) SOUTH AMERICA (Sao Paulo) US-EAST (Virginia) AWS GovCloud (US) ASIA PAC (Sydney) Regions ASIA PAC (Singapore)
  9. 9. US-WEST (Oregon) EU-WEST (Ireland) ASIA PAC (Tokyo) US-WEST (N. California) SOUTH AMERICA (Sao Paulo) US-EAST (Virginia) AWS GovCloud (US) ASIA PAC (Sydney) Availability Zones ASIA PAC (Singapore)
  10. 10. Compute Storage AWS Global Infrastructure Database App Services Deployment & Administration Networking Amazon CloudWatch AWS IAM AWS CloudFormation Amazon Elastic Beanstalk AWS Data Pipeline AWS OpsWorks Amazon CloudSearch Amazon SQSAmazon SNS Amazon Elastic Transcoder Amazon SWF Amazon SES Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon RedShift AWS Storage Gateway Amazon S3 Amazon Glacier Amazon CloudFrontAmazon EC2 Amazon EMR Amazon VPC Amazon Route 53 AWS Direct Connect
  11. 11. Scaling up as you grow
  12. 12. Day One, User One: • A single EC2 Instance – With full stack on this host • Web App • Database • Management • etc • A single Elastic IP • Route53 for DNS EC2 Instance Elastic IP Amazon Route 53 User
  13. 13. Scaling Vertically • Simplest approach • Can now leverage PIOPs • High I/O instances • High Memory instances • High CPU instances • High storage instances • Easy to change instance sizes • Will hit an endpoint eventually hi1.4xlarge m2.4xlarge m1.small
  14. 14. Day One, User One: • We could potentially get to a few hundred to a few thousand depending on application complexity and traffic • Manual failover • No redundancy • Too many eggs in one basket EC2 Instance Elastic IP Amazon Route 53 User
  15. 15. Day One, User One: • We could potentially get to a few hundred to a few thousand depending on application complexity and traffic • Manual failover • No redundancy • Too many eggs in one basket EC2 Instance Elastic IP Amazon Route 53 User
  16. 16. Day Two, User >1: First lets separate out our single host into more than one. • Web • Database – Make use of a database service? Web Instance Database Instance Elastic IP Amazon Route 53 User
  17. 17. User >100: First lets separate out our single host into more than one. • Web • Database – Use RDS to make your life easier Web Instance Elastic IP RDS DB Instance Amazon Route 53 User
  18. 18. User > 1000: Next let’s address our lack of failover and redundancy issues: • Elastic Load Balancer • Another Web instance – In another Availability Zone • Enable RDS Multi-AZ Web Instance RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone Web Instance RDS DB Instance Standby (Multi-AZ) Elastic Load Balancer Amazon Route 53 User
  19. 19. • Create highly scalable applications • Distribute load across EC2 instances in multiple availability zones Feature Details Available Load balance across instances in multiple Availability Zones Health checks Automatically checks health of instances and takes them in or out of service Session stickiness Route requests to the same instance Secure sockets layer Supports SSL offload from web and application servers with flexible cipher support Monitoring Publishes metrics to CloudWatch Elastic Load Balancer Elastic Load Balancing
  20. 20. Scaling this horizontally and vertically here will get us pretty far ( 10s-100s of thousands )
  21. 21. User >10ks-100ks: RDS DB Instance Active (Multi-AZ) Availability Zone Availability Zone RDS DB Instance Standby (Multi-AZ) Elastic Load Balancer RDS DB Instance Read Replica RDS DB Instance Read Replica RDS DB Instance Read Replica RDS DB Instance Read Replica Web Instance Web Instance Web Instance Web Instance Web Instance Web Instance Web Instance Web Instance Amazon Route 53 User
  22. 22. This will take us pretty far honestly, but we care about performance and efficiency, so lets clean this up a bit
  23. 23. Shift some load around: Let’s lighten the load on our web and database instances: • Move static content from web servers to S3 and CloudFront • Move session/state and DB caching to ElastiCache or DynamoDB Web Instance RDS DB Instance Active (Multi-AZ) Availability Zone Elastic Load Balancer Amazon S3 Amazon Cloudfront Amazon Route 53 User ElastiCache DynamoDB
  24. 24. Working with S3 - Amazon Simple Storage Service • Object based storage for the web • 11 9s of durability • Good for things like: – Static assets ( css, js, images, videos ) – Backups – Logs – Ingest of files for processing • “Infinitely scalable” • Serves static content • Supports fine grained permissions • Ties in well with CloudFront & EMR • Logging for S3/CloudFront/Billing • Supports Encryption (transit/rest) • Reduced Redundancy 1/3 cheaper • Glacier for long term storage • Objects lifecycle configuration • Automatic partitioning (prefix choice can maximize throughput)
  25. 25. ElastiCache • Hosted Memcached – Speaks same protocol as open source memcached • Scale from one to many nodes • Self healing ( replaces dead instance ) • Very fast ( single digit ms speeds usually) • Local to a single AZ – So need to run different clusters across different Azs • Data is only in memory, so not persistent • Use AWS’s Auto Discovery client to simplify clusters growing and shrinking without affecting your application
  26. 26. Auto-Scaling!
  27. 27. Sunday Monday Tuesday Wednesday Thursday Friday Saturday Typical weekly traffic to Amazon.com
  28. 28. Sunday Monday Tuesday Wednesday Thursday Friday Saturday Typical weekly traffic to Amazon.com Provisioned capacity
  29. 29. November traffic to Amazon.com November
  30. 30. November traffic to Amazon.com Provisioned capacity November
  31. 31. November traffic to Amazon.com 76% waste 24% Provisioned capacity November
  32. 32. November traffic to Amazon.com November
  33. 33. Decompose into small, loosely coupled, stateless building blocks Prerequisite
  34. 34. Having decomposed into small, loosely coupled, stateless building blocks You can now Scale out with ease Having done that…
  35. 35. Having decomposed into small, loosely coupled, stateless building blocks We can also Scale back with ease Having done that…
  36. 36. Trigger auto-scaling policy Automatic resizing of compute clusters based on demand Feature Details Control Define minimum and maximum instance pool sizes and when scaling and cool down occurs. Integrated to Amazon CloudWatch Use metrics gathered by CloudWatch to drive scaling. Instance types Run Auto Scaling for On-Demand and Spot Instances. Compatible with VPC. as-create-auto-scaling-group MyGroup --launch-configuration MyConfig --availability-zones us-east-1a --min-size 4 --max-size 200 Auto-Scaling Amazon CloudWatch
  37. 37. Scaling the Database
  38. 38. Self-Managed Fully-Managed Database Server on Amazon EC2 Your choice of database running on Amazon EC2 BringYour Own License (BYOL) Amazon DynamoDB Managed NoSQL database service using SSD storage Seamless scalability Zero administration Amazon RDS Microsoft SQL, Oracle or MySQL as a managed service Flexible licensing BYOL or License Included Amazon Redshift Massively parallel, petabyte-scale, data warehouse service Fast, powerful and easy to scale Database Options
  39. 39. But how do I choose what DB technology I need? SQL? NoSQL?
  40. 40. For most use-cases SQL is good fit • Relational DBs: Established and well worn technology • Lots of existing code, communities, books, background, tools, skilled people etc • Flexible query model, data integrity • Can actually scale - especially for read heavy apps
  41. 41. Scaling Relational DBs • Read Replicas (Master – Slave) • Replication lag • Splitting Reads and Writes – Writes => master – Reads with tolerance to stale data => read replica (slave) – Reads with need for most recent data => master • Master is a SPOF – Try to decouple / introduce fault tolerance to your application
  42. 42. NoSQL data stores • Distributed systems, can scale up reads but also writes – Sharding + Replicas • Compromises: No JOINs, limited querying flexibility vs Relational – Denormalize data, schema dictated by app queries • Eventual consistency vs strong consistency
  43. 43. DynamoDB • Provisioned throughput NoSQL database • Fast, predictable performance • Fully distributed, fault tolerant architecture • Considerations for non-uniform data Feature Details Provisioned throughput Dial up or down provisioned read/write capacity. Predictable performance Average single digit millisecond latencies from SSD-backed infrastructure. Strong consistency Be sure you are reading the most up to date values. Fault tolerant Data replicated across Availability Zones. Monitoring Integrated to CloudWatch. Secure Integrates with AWS Identity and Access Management (IAM). Elastic MapReduce Integrates with Elastic MapReduce for complex analytics on large datasets.
  44. 44. Being Agile with continuous deployment
  45. 45. Idea Product Least friction Highest quality
  46. 46. Idea Product Shortest time Highest accuracy
  47. 47. Idea Product Failing fast when you need to
  48. 48. Idea Product Product ProductFreedom to pivot if you have to
  49. 49. How? deploy often …on a platform built for iteration
  50. 50. Everything that was a constrained resource is now a programmable resource
  51. 51. Auto Scaling Group V1 Elastic Load Balancer Amazon Relational Database Service (RDS)
  52. 52. Auto Scaling Group V1 Auto Scaling Group V2 Elastic Load Balancer Amazon Relational Database Service (RDS)
  53. 53. Auto Scaling Group V1 Auto Scaling Group V2 Elastic Load Balancer Amazon Relational Database Service (RDS)
  54. 54. Auto Scaling Group V1 Auto Scaling Group V2 Elastic Load Balancer Amazon Relational Database Service (RDS)
  55. 55. Auto Scaling Group V2 Elastic Load Balancer Amazon Relational Database Service (RDS)
  56. 56. Get smart Achieve a lot even if team is small
  57. 57. Offload undifferentiated heavy lifting
  58. 58. AWS Cloud-Based Infrastructure Your Business More Time to Focus on Your Business Configuring Your Cloud Assets 70% 30%70% On-Premise Infrastructure 30% Managing All of the “Undifferentiated Heavy Lifting” Focus on your core business
  59. 59. Relational Database Service DynamoDB SimpleDB Databases Middleware Frameworks Analytics Simple Queuing Service Simple Notification Service Simple Workflow Elastic MapReduce Simple Email Service CloudSearchElastiCache CloudWatch
  60. 60. User >1mil+: RDS DB Instance Active (Multi-AZ) Availability Zone Elastic Load Balancer RDS DB Instance Read Replica RDS DB Instance Read Replica Web Instance Web Instance Web Instance Web Instance Amazon Route 53 User Amazon S3 Amazon Cloudfront DynamoDB Amazon SQS ElastiCache Worker Instance Worker Instance Amazon CloudWatch Internal App Instance Internal App Instance Amazon SES
  61. 61. A Summary
  62. 62. • Make your application stateless – local file system only for temp files • Use Autoscaling in Multiple AZs • Make use of self scaling services ( ELB, S3, DynamoDB, SQS, SWF, SES, etc ) • Select data layer based on real needs • Leverage managed/low touch services
  63. 63. What is Cloud Computing http://aws.amazon.com/what-is-cloud-computing Architecture Center http://aws.amazon.com/architecture Articles http://aws.amazon.com/articles Documentation http://aws.amazon.com/documentation
  64. 64. QUESTIONS?

×