It sounds like the author was making the same mistake that pretty much everybody makes: Treating your blog as though it were dynamic content. But it's not. It's static HTML, and you should never have to make any modifications to anything to make it scale.
Step one: Have your blog export all entries to plain HTML.
Step two (optional): move your imagery out to S3/Cloudfront.
That's it. That will allow your little out-of-the-box slice handle all the traffic that we can throw your way.
Scaling is an issue that you're meant to have with your product. Because your product actually needs to talk to databases and do things, it may have trouble doing those things when lots of people hit it at once. A website hosting a blog, on the other hand, needs to serve files. And that's been a solved problem for fifteen years.
The problem became unsolved in the interim, largely because it was virtually impossible for the 2001 Internet to overwhelm the limits of Apache's default settings, whereas it is fairly easy in 2011 to do that with social media.
There have been three posts on my blog this year which would, with absolute engineering certainty, have effectively DOSed Apache if I had kept the Ubuntu default settings. All involve numbers which are really small for computers, like 300k (hits in a day)
It took me years of blogging to realize why this happened and address it, despite my blog running on a beefy machine and me theoretically having experience with much harder problems than serving 20k of plain text repeatedly.
Have you considered simply moving your entire blog onto Cloudfront? It would take a lot of traffic to bring that down, and deploying to it is essentially as easy as deploying to a web server.
I'm afraid I'm going to have to stand by my assertion that static file hosting is a solved problem in 2011. I think the real issue we're seeing with all these "Slashdotted blogs" is that the database-based-blog is the 20 minute intro lesson for every new server-side tech. The result is that everybody thinks about blog hosting as a problem involving taking content from the database and displaying it to the user. This leads to things like caching and other performance hacks that could be done away with if you simply thought of the problem in terms of hosting files.
Kind of. This is all good advice, but WordPress is still the major blogging platform, and it is awful at scaling out of the box. You can get Super Cache or Total Cache but most people don't do that up front because they're not expecting the traffic, and even those won't do S3/Cloudfront for the static content in your site's themes.
If you're stuck with traffic to your blog, you should look at an existing caching solution and maybe scale your VPS a little. It's not likely to be a permanent thing.
> If the blog supports comments, it needs to talk to databases.
Sure, but it doesn't have to fall over. Outsourcing to Disqus is the easiest solution, but you can build your own AJAXy solution. Or just write out a new static file for each comment (if you're really overloaded, comments may take a while to be processed, but you can just serve the old page in the interim.)
"If the blog supports comments, it needs to talk to databases."
No it doesn't. Comments aren't added all that much relative to how much your site is getting hit. It would make more sense that the page is just a static html file with a form. The form submits to your app engine (php/python/whatever) which adds the data to the database. That then triggers your static html file to be rewritten to display that comment as well. The only other modification you "may" want to make is set it so that browsers don't cache your html page so they can see new comments if they refresh.
If you have a blog that may one day see traffic, I'd recommend taking that bit of the post to heart and skipping the whole "serve blog content via the database" part altogether.
It sounds like the author was making the same mistake that pretty much everybody makes: Treating your blog as though it were dynamic content. But it's not. It's static HTML, and you should never have to make any modifications to anything to make it scale.
Step one: Have your blog export all entries to plain HTML.
Step two (optional): move your imagery out to S3/Cloudfront.
That's it. That will allow your little out-of-the-box slice handle all the traffic that we can throw your way.
Scaling is an issue that you're meant to have with your product. Because your product actually needs to talk to databases and do things, it may have trouble doing those things when lots of people hit it at once. A website hosting a blog, on the other hand, needs to serve files. And that's been a solved problem for fifteen years.