AppEngine doesn’t fit the needs of startups on the runway
threeriversinstitute.org
threeriversinstitute.org
This is my favorite aspect of app engine -- you can be confident that if you follow the best practices your app will scale. Try that with a rails or django app.
Sure you can scale Rails horizontally, but what about Sphinx? What about Mysql? If you're lucky your app will scale in a way that the "simple" methods of scaling these tools happens to work. But what if it's not?
Before long you'll wish you'd just been forced to make all requests complete in under 4 seconds initially :)
These are problems that you as a coder can address directly with app engine. Without it, you have to wear all sorts of sysadmin hats and hope you're not doing something foolish.
Consider Rails: Convention over configuration. The same applies to app engine, only with a slightly more restrictive set of conventions.
You've heard of the C3 project?
AppEngine offes a different tradeoff--easy scaling but relatively slow experimentation. My comments about the fit of AppEngine only apply on the runway. Once you get to climb out (validated product/validated business model/rapid growth), AppEngine is a great fit.
If you write your program to AppEngine, and Google decides one day to close down your site, you have no options.
If a) you know *nix and SQL and b) don't need to scale to 1000's of users a minute, I don't see the need for AppEngine.
That nobody has done this suggests that the community doesn't think google is going to shut down app engine. You run the same risk using any library that is currently being maintained that you would have to suffer a learning curve to improve if the maintainer quit.
I wonder what the appeals process is in case of a dispute. Considering some people's experiences with Google Checkout I would at least read the terms of service very carefully.
This is not just an issue with Google. It's a general issue with that kind of all in one cloud service.
[edit] If you use google accounts for authentication the risk is even greater.
Where does that rank among:
- Your chief developer gets seriously injured or quits
- Your funding dries up
- You run into unexpected scaling problems when rolling your own data center.
- You miss out on some other opportunity because you have allocated lots of your finite resources to scaling.
I think we can look to Amazon AWS to see a more likely outcome of the sort of concern you are getting at: After a while Amazon did adjust the pricing of some of its services to better mirror its own costs. This was not to be punitive toward its customers, but simply to allow it to better pass along costs (most customers saw their bill decrease).
So I'd say the real risk is that if you use a beta cloud service and your business model is based on some sort of loophole in the pricing, you run the risk of that loophole being closed and your costs increasing.
This risk ranks much higher than my fear of scaling problems as that is something I am at least competent at solving. My funding doesn't dry up over night. If my chief developer quits, development will slow down for a while but the service won't stop working tomorrow. Some risks just cannot be avoided anyway.
And I'm not saying I want to run my own data center. What I'm saying is that I want reasonable terms of service and a realistic transition path to a different provider.
In case of a conflict I want someone to talk to me _before_ my site is shut down, and if the issues cannot be resolved I want a reasonable period of time to move elsewhere.
[edit] If the technical specificities of a platform prevent me from moving my site within that grace period, I'm not going to use the platform for any serious business.
If your business/project is on shaky enough legal ground that you really have to worry about cease and desist letters, then I'd say you would need to look into some sort of offshore hosting. If so then your argument is against most normal hosting not just google app engine.
As for the transition path, that is a good point. Google has open sourced the spec and sdk, so someone could feasibly reverse engineer something that behaved just like app engine -- in fact I wouldn't be surprised if a serious attempt at this happens fairly soon.
My project is not any more on shaky ground than Google's own business. Search engines or any service that lets users upload or link content is prone to cease and desist letters. Only very recently there was a post here on HN where someone complained that 6 tweets were uploaded to a competitor's site by a user.
And then there's Google's user authentication service, which is very convenient. I can't think of a way to migrate that one without asking all my users to create new accounts and provide their google login password so I can check whether they are the legitimate owner of that account.
As for user auth, I'd suggest setting up a table that stores the user's email address and a random hash, so if google auth stops working they can just "reset their password" and you can use your own auth system w/ the same email address as the google account.
You won't be locked in. If you need to get out you can :)
(Specifically, people like ribrdb, who himself is a googler, has produced a Ruby api wrapper [handily called appengine-apis] for the Java API, and an adapter that interfaces with one of Ruby's ORM/DataStore libraries called DataMapper. Data access as a result is uniform from an end user perspective across environments)