Developers: Will you ditch Amazon Web services for Google AppEngine?(alleyinsider.com)
alleyinsider.com
Developers: Will you ditch Amazon Web services for Google AppEngine?
http://www.alleyinsider.com/2008/5/googles_app_engine_opens_for_business
4 comments
AWS has been working great for us. The new persistent storage feature is the best thing since sliced bread (I'm in the alpha). I definitely don't see us leaving EC2 for AppEngine anytime soon.
AFAIK, Google doesn't offer anything compelling enough for most people to switch.
AFAIK, Google doesn't offer anything compelling enough for most people to switch.
That would be a risky effort because:
1. Google App Engine (GAE) is non-relational in both structure and use. If your app has significant database complexity then your GAE database may not be consistent at any particular time. Correcting those inconsistencies is up to you.
2. Each year computers get faster and faster. What doesn't scale today may likely scale tomorrow. Sometimes waiting six months and buying a faster server is a better solution.
3. The a priori likelihood that your site will be popular enough to demand the scalability GAE can apparently deliver is very low, indeed nil. Are you willing to pioneer on an inconsistent infrastructure when you could use a proven relational one?
4. Above I said "_apparently_ deliver...": it is by no means a given that GAE will prove adequate. It is, after all, a beta site.
5. Is it worthwhile investing the time to learn a new non-relational database system and framework and implement your site in that system when you _know_ you could implement it instead with proven technology? Were your site to prove popular you might have to buy some computing power, get new servers, etc. But isn't that a known path? Isn't GAE the unproven, unknown path? What do you do if your GAE app doesn't scale? Is the flaw in your code or in Google's infrastructure? You can't always tell because Google's infrastructure isn't transparent.
I see GAE as useful mostly for it's integration and toolkit. I would welcome the addition to GAE of a relational database (or of even a non-relational database that guaranteed the ACID (Atomicity, Consistency, Isolation, Durability) properties. But barring such an addition, life will continue just as before GAE.
1. Google App Engine (GAE) is non-relational in both structure and use. If your app has significant database complexity then your GAE database may not be consistent at any particular time. Correcting those inconsistencies is up to you.
2. Each year computers get faster and faster. What doesn't scale today may likely scale tomorrow. Sometimes waiting six months and buying a faster server is a better solution.
3. The a priori likelihood that your site will be popular enough to demand the scalability GAE can apparently deliver is very low, indeed nil. Are you willing to pioneer on an inconsistent infrastructure when you could use a proven relational one?
4. Above I said "_apparently_ deliver...": it is by no means a given that GAE will prove adequate. It is, after all, a beta site.
5. Is it worthwhile investing the time to learn a new non-relational database system and framework and implement your site in that system when you _know_ you could implement it instead with proven technology? Were your site to prove popular you might have to buy some computing power, get new servers, etc. But isn't that a known path? Isn't GAE the unproven, unknown path? What do you do if your GAE app doesn't scale? Is the flaw in your code or in Google's infrastructure? You can't always tell because Google's infrastructure isn't transparent.
I see GAE as useful mostly for it's integration and toolkit. I would welcome the addition to GAE of a relational database (or of even a non-relational database that guaranteed the ACID (Atomicity, Consistency, Isolation, Durability) properties. But barring such an addition, life will continue just as before GAE.
"3. The a priori likelihood that your site will be popular enough to demand the scalability GAE can apparently deliver is very low, indeed nil. Are you willing to pioneer on an inconsistent infrastructure when you could use a proven relational one?"
The perceived probability of "getting popular enough" is for most start-ups non-zero. Else many start-ups would not even exist at all. That is, the expected value of the entire start-up endeavor, E(start-up)--say in the unit of dollars--is driven by these rare, but extreme outcomes.
Given this is the case, my impression is that: P( failure to scale | RDBMS ) > P( failure to scale | BigTable/simpleDB ) (that is, it is much more difficult to scale up RDBMS than BigTable/SimpleDB)
and P( success | failure to scale ) is near 0,
then it makes sense to prepare for that possible rare outcome of having to scale, in order to preserve that expected value.
The perceived probability of "getting popular enough" is for most start-ups non-zero. Else many start-ups would not even exist at all. That is, the expected value of the entire start-up endeavor, E(start-up)--say in the unit of dollars--is driven by these rare, but extreme outcomes.
Given this is the case, my impression is that: P( failure to scale | RDBMS ) > P( failure to scale | BigTable/simpleDB ) (that is, it is much more difficult to scale up RDBMS than BigTable/SimpleDB)
and P( success | failure to scale ) is near 0,
then it makes sense to prepare for that possible rare outcome of having to scale, in order to preserve that expected value.
"Sometimes waiting six months and buying a faster server is a better solution."
Sounds like a great use of your limited resources!
Sounds like a great use of your limited resources!
I'm using Heroku, which runs on Amazon. Since I'm not using Amazon service directly, this might actually be a more fair comparison (AWS by itself is lower level than Heroku and GAE). I don't plan to switch because I've been having a good experience with Heroku, I happen to know Rails and my project is already well underway.
What I would like to see is a functional language supported by a Heroku-type service or on GAE so that I could take the same in-cloud dev approach and learn a new language paradigm at the same time. I'm impulsive, so right now I'm interested in ErlyWeb. Python isn't different enough to warrant the jump, so unless I magically hit the level where I will benefit from Big Table (and I don't just use SimpleDB or Heroku doesn't pick up a doc-DB in the meantime), I'm fine where I am.
I am very glad they lifted the user limit, however, because I would like to see what the non-early-adopters start to produce.
What I would like to see is a functional language supported by a Heroku-type service or on GAE so that I could take the same in-cloud dev approach and learn a new language paradigm at the same time. I'm impulsive, so right now I'm interested in ErlyWeb. Python isn't different enough to warrant the jump, so unless I magically hit the level where I will benefit from Big Table (and I don't just use SimpleDB or Heroku doesn't pick up a doc-DB in the meantime), I'm fine where I am.
I am very glad they lifted the user limit, however, because I would like to see what the non-early-adopters start to produce.
Why? Because AppEngine makes you program in a way that will infinitely scale - which is a lot harder. You have to denormalize all your data, manually calculate everything, etc.
If you want to become the next big thing, you won't do it with AppEngine. Why? Because the advantage that you and your buddy have as a two-person team is that you don't have to worry about instantly having millions of users. AppEngine is what people like Google have to start out with. So, if you have an idea, you can beat bigger players out of the gate because you can start small. You can use things like joins to make your application easy to code.
If you forgo that advantage, you just aren't going to be agile enough to compete with large teams.