A couple things strike me about the rebuttals here: The illusion of simplicity No one is saying this specifically, but the spirit of what is being said follow

A couple things strike me about the rebuttals here: The illusion of simplicity No one is saying this specifically, but the spirit of what is being said follows the line of thinking that because it's easy to get a server stack set up and running, it's a "simple task"". Getting a stack running is easy. Making it scale beyond a certain threshold is not simple. That threshold tends to be a brick wall in my experience. Underestimation of time spent It's easy to sink a lot of time in to these administrative tasks. You have to remember what business you're in. If you're a sysadmin, great. This is time well spent, but most of us are not sysadmins. We're in some other business. It is good to understand how a web hosting stack works from a high level. It helps you make good decisions. One of those "good decisions" is recognizing where your time is best spent. If your business is anything other than system administration, I doubt that relentlessly benchmarking your stack to see how many reqs/s you can host is a good use of your time. The assumption that "I" know a solution The only people with enough knowledge to challenge Patrick's decisions are those who have met this challenge. My WP hosting works fine, but that's because 2,500 visitors a day is a big day for me. I wouldn't even begin to suggest that he didn't make a sound decision until I had met this challenge myself. I have some small idea of how difficult it must be, because our company's software does "real time" online procurement events (reverse auctions). Sounds like boring stuff, right? Consider one of the basic tenants of scaling: serve from cache and avoid re-building on each request. Now, consider that in a reverse auction, you might have 10 bidders placing bids on 500 line items spread out over 8 lots. Bid rates regularly top 30 bids per minute. Each bidder has a unique object cache because of the nature of reverse auctions (they each have their own data sets to track). Sometimes we implement weighting, where the bids are multiplied by a factor, have some fixed value added to them, or are calculated as a markup/markdown percentage against a fixed value. Then there's the observer screen, which has views for overview, line item summary, and line item detail, each of which have their own view states. Every time someone places a bid, there are a number of objects that are completely invalidated and must be rebuilt. Everyone involved (observers and bidders) in the live event is polling the server at the fastest rate we can afford. As much as I appreciate input, I'm not asking for solutions to our scaling challenges. We have plenty of good ideas, and we've stayed ahead of the curve (mostly) on what could very generously be called a shoestring budget. Even having done that, I can't question Patrick's decision here. If I suspect anything, it's that he made a wise choice. Scaling is hard. My point is that you'll never know if you can meet a challenge until you do it yourself. If you have met the challenge, great, but at what cost? Consider your own bias and take a serious look at the time investment. If you still think you've got all the answers and you can do it in trivial time, please send me your business card, because I'll hire you on the spot.