Google will ban you from accessing their service the instant their algorithm detects it's not an actual human being making searches and viewing their ads. Even if you behave nicely with your scripts and rate-limit them not to hit Google's servers badly.
What, exactly, is your reason? Google custom search engines are a perfectly viable option for most use cases, but apparently you'd like to pass off their search results are your own, or you'd like to create an ad-free version of Google? I have no idea, because, again, you haven't actually given a reason why you should be allowed to do something that, in general, I don't think should be allowed. Why should a competitor be allowed to scrape Google's search results?
On the other hand, Google has no problem hitting your servers and causing more than $1000 fees for the owner for nothing.
You like straw men, apparently. Anyone who doesn't like Google hitting their servers can easily disable indexing entirely, or rate limit the indexing process. That is, Google actually respects robots.txt files, which is more than I can say for a huge number of other crawlers out there on the Internet. Before you go complaining about something that can actually be controlled by a halfway competent sysadmin, maybe you should worry more about the bots that don't actually play by the rules, and have no intention of doing so? They're far more of a problem.
I know you're just throwing numbers out there, but the way you arrived at your figure is flawed. You claim that Linux use on the desktop is 1%; okay, fine, I can live with that. You then go on to show that only a fraction of those Linux users are interested in games, and that fraction of the total computer population is the market size.
Your assertion that this is then 0.1% of sales presumes that 100% of the non-Linux market is interested in games, which is clearly not the case. That is, in order to make the numbers comparable, we have to make the same comparison with other platforms that you did with Linux:
1. PC use for the desktop is at around 92%.
2. 50% of that is installed base in corporate systems (market share is common derived from units sold, not 'platform preference by person').
3. 25% are not interested in games.
4. 15% of what is left will pirate any game that comes out.
So, again, maybe 10% of that is actually a viable market. Sure, 9.2% is > 0.1%, but that presumes that any of these ballpark figures are meaningful. What if the average Linux user is actually more likely to be a gamer than the average PC user? That is, there might exist a correlation between being a gamer (or at least being the kind that buys blockbuster titles) and platform preference. What if the average linux user is more likely to pay (when they aren't open source zealots) than the average PC user? All of these ideas need to be factored in to any real calculation of market size.
I think you misunderstand the point of App Engine. Varnish and HA-Proxy are things that are installed on servers to improve their performance. The idea behind using GAE is to remove yourself from needing applications of that variety at all. Using GAE, you don't have to worry about the server hardware, the operating system, the load balancer, caching, or any other system details; you just run a program. If fine tuning system architecture is your idea of fun, or is critical for your particular application, then by all means stay away from GAE.
If, however, thinking about these system architecture concerns makes your head hurt, as it does mine, and you just want to get your application running, then use GAE. GAE abstracts scalability; that is the point of the platform. You're paying Google to use their know-how to make your simple Python / Java / Go program run and work for request volumes in the 1 per minute range to the 100 per second range. To me, that is what makes GAE amazing and worthwhile.
I am a researcher, and I don't have the time or energy to spend on managing servers or configuring, updating, and ensuring reliability of operating systems. I want a PaaS architecture that removes me from the hardware and operating system levels. Those pieces of the puzzle are not relevant to me, and dealing with them just saps time and energy from what I actually want to focus on. What I want is somewhere where I can hand off the code that is relevant to my application and know that the program, and the servers it reside on, will continue to operate for any load level twenty four hours a day. For my purposes, it's perfect. I am hard pressed to imagine that any but the largest players derive their competitive advantage from their server infrastructure, so, to me, not having to worry about it just frees up limited resources to focus on what's important.
It seems clear you haven't tried App Engine. You mention Azure's integration with Eclipse as something which competitors have that Google doesn't, except that the Google Eclipse plugin has provided the same (and dare I say better) integration with the Eclipse environment since App Engine launched, which was well before Azure. You then go on to allude to "services" that Amazon provides, which if you're referring to EC2 is a bit like comparing Gmail to exim4 with mutt, and if you're referring to the other AWS, is just plain wrong. There is no "traditional platform" with EC2; there's merely what you build, or what you tie into with web calls. In the former case, it's worth noting that the reason many people turn to App Engine, or Azure, is that they don't want to manage their own system images; they just want to run a program. In the latter case, you can use any of the AWS services that have web protocols with App Engine just fine, and many people do.
If you want to make a more reasonable comparison, it's App Engine versus Azure versus Amazon Elastic Beanstalk. Azure supports
I'm really perplexed by this "huge amount of stuff" that other people offer. The only thing I can think of is the ability to dynamically tailor the system your program runs on, but if that's what you want, you're shopping for EC2 and other virtualization solutions like Rack Space, not Azure/AEB/GAE. If you're looking for platform-as-a-service because you understand the tradeoffs that you're entering into, those three are the main players in town. Of those three, GAE wins hands down in my opinion. Not only does it support more languages and programming styles (frontend / backend code can be separated and used for different types of instances) than either Azure or AEB, the value added services make programming many types of applications simpler (and they can all be avoided if lockin is feared). Azure requires you to program in Windows with their tools, and who wants to be required to do that? AEB has all the slowness of EC2 without the configurability, so it seems you'd be better off with either Azure or GAE no matter what.
Take a tiny amount of time to understand what you're criticizing next time.
Your laptop, tablet, phone, and more all already have Wifi. So do your SO's (if applicable) and children's (if applicable) devices. Get one portable 3G device, either a portable modem or your phone, and use tethering. Stop paying the phone company by device and only pay them by plan.
If I had to pay by device for Internet access at my house I'd be screwed . .
Not quite. This move is all about options and preventing the dreaded 'lockin'.
Developers ask: If I bet my development on a single PaaS provider, won't I be tied to them indefinitely?
VMware says: If you use our open source stack that can be hosted by us, or by you, you won't be tied to a particular framework or hosting provider. We'll happily host you if our service fits your needs but, if your needs outgrow us or we fail to meet your quality expectations, you can always run the exact same stack out of your own datacenter or someone else's.
What remains to be seen is how good the performance is and how easy it is to use the platform.
What everyone seems to be forgetting is that this is Google's data. What I mean by that is that the data does not even remotely imply that you do not need technical expertise to be a good manager. All of the managers at Google had good technical expertise, or they wouldn't have gotten there (because, remember, Google valued technical expertise in their managers). There are no pointy-haired bosses at Google.
What the data is really saying is that after you have passed a threshold level of technical competence, how you manage becomes more important than how good you are at coding. In other words, if you're technically competent enough to apprehend what's going on and make informed decisions, it matters more what decisions you make and how you arrive at those decisions, not that you're the best coder in the room.
How is that surprising? As soon as you start hiring hundreds of pointy-haired bosses, then the data will rank technical competence as the first priority. The data is only a reflection of existing conditions. People are saying, "technical competence is good enough, but here's what isn't". Don't take this as a sign that technical competence is not important.
More seriously, I can see that this might appeal to people who travel a lot, but for everyone else ?
You're probably right, but since I am one of those individuals with a 100% travel job, the first time I heard of this service I said "finally!". While I usually make it home on weekends, I can often be gone for two or three weeks at a time. In the best of situations I can get my snail mail once a week, but often it's much worse than that. With this service, I can get all of my snail mail when it arrives like a normal person.
The only thing keeping me from signing up is that, because of my situation, I very intentionally avoid having anything important snail mailed to me. Hence, I'm not sure that $20/month to see my junk mail faster is worthwhile. I think I've phased snail mail out of my life too much to justify the cost, but the service is exactly something I'd want.
From a more digital age perspective though, I also just thought the idea of having digital copies of all of my mail and trashing the originals was really cool (i.e. without my personal effort involved). Anything that's not sentimental I have no desire to have an original of anymore; filing cabinets are for people born before I was. This takes out the effort but still allows me to maintain my perfect paperless office.
"Our vision is to speed up time, eventually eliminating it." -- Alex Schure