Aws for Startups Building Cloud Enabled Apps
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Aws for Startups Building Cloud Enabled Apps

on

  • 1,552 views

 

Statistics

Views

Total Views
1,552
Views on SlideShare
1,552
Embed Views
0

Actions

Likes
10
Downloads
85
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Aws for Startups Building Cloud Enabled Apps Presentation Transcript

  • 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. 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. Intro
  • 4. Utility computing On demand Pay as you go Uniform Available
  • 5. On demand Pay as you go Uniform Available Utility computing
  • 6. Utility computing
  • 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. 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. 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. 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. Scaling up as you grow
  • 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. 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. 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. 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. 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. 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. 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. • 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. Scaling this horizontally and vertically here will get us pretty far ( 10s-100s of thousands )
  • 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. This will take us pretty far honestly, but we care about performance and efficiency, so lets clean this up a bit
  • 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. 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. 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. Auto-Scaling!
  • 27. Sunday Monday Tuesday Wednesday Thursday Friday Saturday Typical weekly traffic to Amazon.com
  • 28. Sunday Monday Tuesday Wednesday Thursday Friday Saturday Typical weekly traffic to Amazon.com Provisioned capacity
  • 29. November traffic to Amazon.com November
  • 30. November traffic to Amazon.com Provisioned capacity November
  • 31. November traffic to Amazon.com 76% waste 24% Provisioned capacity November
  • 32. November traffic to Amazon.com November
  • 33. Decompose into small, loosely coupled, stateless building blocks Prerequisite
  • 34. Having decomposed into small, loosely coupled, stateless building blocks You can now Scale out with ease Having done that…
  • 35. Having decomposed into small, loosely coupled, stateless building blocks We can also Scale back with ease Having done that…
  • 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. Scaling the Database
  • 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. But how do I choose what DB technology I need? SQL? NoSQL?
  • 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. 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. 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. 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. Being Agile with continuous deployment
  • 45. Idea Product Least friction Highest quality
  • 46. Idea Product Shortest time Highest accuracy
  • 47. Idea Product Failing fast when you need to
  • 48. Idea Product Product ProductFreedom to pivot if you have to
  • 49. How? deploy often …on a platform built for iteration
  • 50. Everything that was a constrained resource is now a programmable resource
  • 51. Auto Scaling Group V1 Elastic Load Balancer Amazon Relational Database Service (RDS)
  • 52. Auto Scaling Group V1 Auto Scaling Group V2 Elastic Load Balancer Amazon Relational Database Service (RDS)
  • 53. Auto Scaling Group V1 Auto Scaling Group V2 Elastic Load Balancer Amazon Relational Database Service (RDS)
  • 54. Auto Scaling Group V1 Auto Scaling Group V2 Elastic Load Balancer Amazon Relational Database Service (RDS)
  • 55. Auto Scaling Group V2 Elastic Load Balancer Amazon Relational Database Service (RDS)
  • 56. Get smart Achieve a lot even if team is small
  • 57. Offload undifferentiated heavy lifting
  • 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. 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. 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. A Summary
  • 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. 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. QUESTIONS?