I'd be really curious to know what their "800 million requests a month" means. When we actually added up numbers a while back, we were doing around 250 million requests to our Python machines/day, and we only had 200 servers (which included dbs/etc), that was around 3-3.5 billion pageviews a month IIRC. We now have 300 machines and do about 5 billion pageviews, but that completely ignores the huge amounts of requests to our realtime stream servers and our API (which get shit on every "pageview" at least once).
It's really hard to compare different systems without knowing what kind of complexity each pageview engenders in terms of backend processing.
At one end there's flat HTML files, where you could serve 800 million pages/month from maybe a single particularly beefy server; at the other fully-dressed SOAs and CEPs and your uncle's pet dog rover performing multivariate regressions, meaning you need 9,000 servers.
I'm hoping they'll provide some more insight into what the breakdown of tasks are between the machines, and if that 800 million number is actually correct.
It seems extremely high for what my absolutely-no-idea-what-these-sites-could-possible-need-that-many-servers-for thought process can fathom.
I don't know about him but we do 1 billion/month using at peak some 12 servers (c1.xlarges and m1.xlarges), including our DB. These are all dynamic requests.
Moovweb creates mobile versions of standard websites on the fly. That sounds pretty expensive, and they probably have a ton of network overhead from distant servers and slow clients.
I interviewed with moovweb a while back... they basically transcode non-mobile-optimized sites into mobile-optimized sites on the fly by transforming html/css/etc.
