2. A short bit of history
● Not that long ago, a "server" was :
○ One piece of hardware
○ One operating system
○ Physically racked, powered, networked in a
managed datacenter
● People started playing with "virtualization"
○ One piece of hardware
○ Multiple operating systems running independently
○ Physically racked, powered, networked in a
managed datacenter
3. As virtualization was taking off...
● Mid-2000's, Amazon.com buys a TON of
hardware.
● The mantra for the folks building Amazon.
com infrastructure:
Provide service style endpoint access to
infrastructure management for internal use.
EVERYTHING IS AN API
8. By Cloud, I mean....
● Must be distributed.
● Must be programatically accessible
● Is multi-tenanted (you are not the only user
of the hardware)
9. In general, what is AWS?
● A collection of commonly used pieces of
software, made easily accessible in:
○ Distributed environment: Multiple Availability zones
per region, multiple regions
○ Programatically accessible infrastructure
For example: Mysql, MS SQL, Memcached, Linux,
Windows,
CDN, DNS Management, User/Admin management,
Firewalls, Load balancers...
12. Some of what this buys us
● We can spin up replica environments
● Easier functional testing...in STAGING
● Load test against prod without touching prod
● Build in automated deployments and testing,
making pushing to prod a breeze for all
devs.
● This makes the feedback loop tighter, faster,
and keeps changes and their inevitable bugs
more in context
● This all wraps up to make you, the devs,
more confident to try new things.
14. Lots of configuration management
options....
● Chef (Opscode)
● Puppet (What I use)
● AMI's (Server images)
● Cloudformation (AWS Service)
15.
16. But wait...isn't the cloud dangerous?
● Yes! Just as dangerous as your datacenter
● Secrets stores in S3, managed by puppet
● Each app has its own key, security groups
● Managing security via security groups, ssh
keys
17.
18. General scaling on AWS
● Use autoscale groups (even if you never
have to autoscale)
● You can trigger autoscaling on any metric
● Use EBS and instance store autoscale
groups
○ 30 seconds to "traffic ready" prebuilt EBS instance
vs. 2-10 min for a instance store
○ Keep a baseline # of instance store nodes, for when
EBS has issues.
○ You can have multiple autoscale groups load into
one ELB (so, app-ebs-fastscale-group and app-
instancestore-noscale-group)
19. General scaling on AWS
● For high IO data (RDS or self-managed
EC2), use provisioned IOPS.
● On EC2, EBS volumes can be RAID10'd...
need a 50k IOPS volume? :D Great way to
vertically scale.
●
20. General scaling on AWS
● Adhere to 12factor.net rules so you can
horiziontally scale
○ CNAME all resources, such as mysql servers. If you
can easily move a resource, you can easily vertically
scale it elsewhere and move to it.
○ Store dependent content away from web tier nodes,
ie media, user uploads. If a web node dies and you
lost anything, you did it wrong.
○ All pieces of app modular, independently scalable
and revvable without retooling
21.
22. General High Availability on AWS
● Multi-Region (Each region has multiple AZ's)
● Multi-Availability Zone for
○ RDS (built in) (takes ~3 min to failover)
○ Load balancing
○ Autoscaling groups (3 AZ's recommended)
● Dynamic DNS
● Health Checks on apps
23. General High Availability on AWS
● Mix in instance store baseline with EBS for
fast scaling for when EBS has issues.
● Health Checks on apps
● Status updates to S3 file, updates app to
point to failover resources... No db? Write
to a SQS queue!
● Oh yeah, use a lot of SQS!
29. RDS Tricks
● Multi-AZ, takes ~3 min to failover
● EBS volumes of greater storage get better
performance, always use 300gb for prod,
even for small instances.
● Read slaves have a lot of challenges with
schema changes. It is usually faster to just
rebuild slaves
● For monitoring, grant repl client to user
30. Some other tricks
● ELB's are EBS-backed EC2 Instances...when EBS
alerts go out, be careful!
● Setup ifttt alerts for AWS RSS status updates
● Use New Relic. Please!
● IAM Roles allow for interaction with AWS
infrastructure...think, a monitoring server that tells an
autoscale group to respond to a problem by launching
new nodes
● Route53 is awesome. Alias A records, super reliable,
you can keep low ttl's
31. Pay Amazon Less
● Reserved instances can save a lot of money
● Spot instances are great for batch and
processing, EMR, Cluster Compute
● S3 static hosting is ridiculously inexpensive.
Go that route for anything static.
● For dev work, Heroku is great, no cost for
apps that do not scale
33. Good stuff
● http://www.12factor.net/
● http://paulstamatiou.com/how-to-getting-started-with-
amazon-ec2
● http://loggly.com/blog/2011/05/send-custom-metrics-to-
cloudwatchs-api/
● https://github.com/toolness/fleeting
● AWS Marketplace has a lot of good stuff
● My example repos: https://github.
com/mozilla/sys_config_examples and https://github.
com/mozilla/sys_scripts_examples
● https://help.ubuntu.com/community/CloudInit
● http://awsofa.info/
●
34. Demo time (if there is time)
-Building a new autoscale group/app?
-Managing infrastructure via fabric, jenkins,
puppet
-Show off the puppet systems config setup?