The key to the claims at scaling in most of these things is that you can throw more tin at the problem. Often this ignores the fact that there is a chumping database behind the scenes where scaling is a bit tricker, and more expensive, or they do smarts like Amazon's S3. The point is though that sometimes the unexpected happens and you have two options.
1) Scale to the possible peak that occurs in an exceptional circumstance
2) Prepare a static page for the exceptional circumstance
Sometimes, for instance if your website is the way you handle customers in the exceptional case, you have to go for the peak. Lots of times however its about getting information out.
As an example, the South East of the UK today was brought to a halt by the sort of snow levels that people in Boston would consider a "flurry" and the folks in Scandinavia would just shrug and walk on. This brought lots of the various sites down, for instance SouthEastern (my local rail company) had their site offline for most of the day.
What did they need to tell me? ALL TRAINS ARE CANCELLED INTO LONDON. But their dynamic site couldn't handle it. Later in the day they switched over to a PHP solution with a minimal (single) page on it but it took a good half of the day.
This is why people should always think about the ultimate fail-over for their sites. Sure you've scaled to some peak, but what if the worst happens and you get treble that peak? The answer is to switch to a file based approach, load that file into memory and just serve it as fast as you can, its amazing how many connections you can support when you are just returning a single static memory loaded page.
Some people will say "scale to that extraordinary peak" but you know what? 99.99% of the people hitting the site were looking for the same single piece of information and saying "normal service will be resumed once the snow has melted" would have been fine for the one random person looking to visit their aunt next June.
Failure conditions don't always mean that you site hasn't failed, it means that you've coped with that failure in a smart way.
Technorati Tags: SOA, Service Architecture
2 comments:
"PHP solution with a single static page"? There is no need for PHP here, because IIS is more than capable to serve static pages. That's what they've done btw.
Steve, as a fellow SouthEastern rider (from Blackheath), I also witnessed their website being out of play for most of the day (maybe their techie was stuck in the snow somewhere?)... and it made me wonder if we could implement a simple technology to gradually degrade the website functionality when the peaks come? First drop some images, then drop the javascript, drop the timetable search feature and then, ultimately, revert to a static page with predefined content... Surely that should be possible?
Also, in terms of scalability, TfL did pretty well that very same day, though!
Post a Comment