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

Reliability Very important! Not really talked about yet.

Build for Failure

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

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)

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

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

Redundancy

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)

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!

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) = 0.0001% 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!!

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…

No downtime deployment

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

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

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

Continuous deployment

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 https://github.com/Strider-CD

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

Questions?