Cross-posted on the Google Cloud Platform Blog.
As the most recent and deadly Ebola outbreak spread in Guinea, Sierra Leone and Liberia, the global philanthropic community sought new and innovative ways to raise money for much needed awareness and relief. Band Aid 30 was imagined as a modern echo of the original Band Aid’s successful campaign to address hunger in Africa. A global team immediately set out to organize a live performance that would feature dozens of the world’s top music artists.
The project came together in just shy of 14 days, so things were a bit frenetic. The logos changed 17 times. Layout and top billing were in constant flux. The front page had UK and US donation links… or maybe just UK? Looming in the back of Jonathan’s mind was the fact that when this site goes live, and several dozen artists with an aggregate 100+ million twitter followers all invite the world to donate, the traffic would be coming fast and heavy.
They were using Google Cloud Platform, which was a bit new to them, and they were really eager to set up automatic scaling so that they’d be able to handle the load. They were also using Google DNS to direct traffic to a Google Compute Engine instance hosting Wordpress and using a local instance of MySQL as the database.
As I explained to Mukesh and Jonathan the standard best practices required to operate a dynamic website like this correctly (e.g., use a load balancer, use replica pools, use autoscaler, and move MySQL to CloudSQL with MemCacheD, and configure WordPress for performance), an idea struck:
Miles: “Hey, what dynamic stuff are you running through WordPress?”
Mukesh: “Well, really nothing. All payment processing is offloaded, comments are using disqus, but that’s really just for layout. And so the PR/media team can make updates on the day of the event.”
Because 100% of the site was static, rather than creating all of the above services, we simply copied the Band Aid 30 website to Google Cloud Storage. Cloud Storage is integrated into the Google front end, a powerful distributed edge routing and caching system that provides incredible performance for serving static content. Just imagine how much content is being served through this system for YouTube, Google Play, Picasa... it’s staggering!
Copying the site might sound complex, but let me assure you, it’s not. In fact, it’s exactly three short lines of code at your command line prompt:
//go get my website, make sure you go to an empty folder first
wget --convert-links -q --mirror -p --html-extension --base=./ -k -P ./ http://ipaddressforyourstagingserver
//put that website in the cloud
gsutil cp -R * gs://www.yourrockingwebsite.com
//let everyone read it
gsutil -m acl set -R -a public-read gs://www.yourrockingwebsite.com That’s it! This solution had simplicity written all over it.
Simplicity also meant cost savings. The dynamic setup – which is obviously more functional – allows lots of simultaneous site editors, data-driven features and richer logging, but is also substantially more expensive to operate. We think all of that would’ve looked something like this, and cost in excess of $10,000 USD per month.
Now, compare that to what we actually built.
It only cost $9.17 (yes, you read that right) to run this production website on launch day, without a single performance hiccup or any risk of operational crisis. It just worked.
That’s a 99.92% discount from our original approach. Assuming all other costs of Band Aid 30 are zero (clearly they aren’t), this would represent a 40,621,592.14% ROI based on their smash success of raising over £2.5 million GBP. Not too shabby ;)
We’re really excited about the positive impact in Ebola victim’s lives that Band Aid 30 is making, the outstanding execution under pressure that Mukesh, Jonathan and the whole Adtrak team delivered (in less than 14 days) and our opportunity to help in this little way.
0 comments:
Post a Comment