1. INFO 344 Web Tools And Development
CK Wang
University of Washington
Spring 2014

2. Reliability
Very important! Not really talked about yet.

3. Build for Failure

4. Build for Failure
Google pioneered this philosophy in late 90’s, Google’s Vision
Assume hardware will fail often, therefore:
Use cheap commodity hardware, and hence:
Write software to be fault tolerant to hardware failures
Cheap commodity = based on law of diminishing returns
Ex: 1Ghz machine = 100 dollars, 2 Ghz machine = 300 dollars, 3 Ghz machine = 1000 dollars
This changed the entire computing infrastructure landscape!
Prior to Google, industry opted for specialized hardware/super computers for faster computing

5. Google File System Problem: Need more Disk Space
Use cheap commodity hardware
Instead of specialized storage
Hook together 100’s of normal PCs!
Write GFS on top
Benefits
Cheaper GB/$$
More bandwidth (I/O of 100 network cards vs. 1)

6. Google MapReduce Problem: Need more CPU power
Use cheap commodity hardware
Instead of super computers to do computing
Hook together 100’s of normal PCs!
Benefits
Fault tolerant, not single point-of-failure (re-route jobs)
Cheaper!
New computing paradigm

7. Memcached Problem: Need more RAM Use cheap commodity hardware Benefits
Instead of specialized RAM hardware
Hook together 100’s of normal PCs!
memcached! Map virtual memory to physical memory that is actually on multiple machines!
Benefits
Cheaper! GB/$$, higher bandwidth

8. Redundancy

9. Redundancy Duplicate important components
Instead of 1 medium, consider 2x m1.small
Might be better as well for bandwidth (most front-end web roles are I/O bound)

10. Redundancy Load Balancer is great for Scalability
Lets try this on AWS!
Create 2 micro
Upload index.html
Add to LB, setup HC
Terminate 1
Load Balancer is great for Scalability
But even more critical for Reliability!!!
AWS LB – has a health monitor, auto removes dead EC2s from the LB and auto-adds them when they’re working!

11. Redundancy
Theory
Let the probability of each machine failing be P(f)
Then the probability of your service (with N machines) failing is
P(F) = P1(f) * P2 (f) * … PN (f)
Machines usually have 99.9% up time, fail = 0.1%,
N = 1, then P(F) = 0.1%
N = 2, then P(F) = %
In practice => P1(f) and P2 (f) not quite independent… lol because if #1 fails, #2 gets more traffic, hence more likely to fail, but basic idea = still true!!

12. Availability Zones Amazon RDS has option for Multi-AZ
Multiple Availability Zones
Great for production (reliability by redundancy)
AWS auto creates another machine in a different physical location (in case for data center failures)
Auto-syncs!
Much more expensive…

13. No downtime deployment

14. No downtime deployment
Azure
Production vs. Staging Environment
Deploy to Staging, then Swap VIP with Production
Let’s try it on Azure!
Open VS, create cloud service with Web Role
Publish on Azure (Production)
Change Hello World to “Bye World”
Change Publish settings to Staging, go!
On Dashboard, swap VIP
Best practice = always publish to Staging… never directly to production. Publish to Staging, run testing, then swap to production

15. No downtime deployment
AWS, Similar to Azure
Create new instance
Test
Add to LB
Remove old instance from LB
Seamless to end-user! Best experience

16. Rollback What if the new deployment sucks?
AWS: Don’t delete the old instance, keep it alive, just remove from LB
Azure: keep the instance running in Staging
Maybe wait a week? If no issues, then delete them.
If there are any issues => Rollback. Swap VIP again or add the old instance back to LB

17. Continuous deployment

18. Continuous deployment
Water fall/non-agile deployment method
Plan for 1 month
Code for 6 months
All teams integrate (1000 devs’ work)
PROBLEM! Integration Issues! Huge!
Solution? Integrate often. Agile method
Continuous deployment => agile method to the extreme
Deploy after each submission to GitHub!
No big integration headache

19. Unit tests & test automation
Software cycle
Write code
Deploy to Staging
Run unit tests/automation
Switch to Production
=> I’ve used it! Great!
Pulls your build from GitHub
Runs in container, runs your tests in parallel
Deploys to your servers!

20. Questions?