

Developers: Will you ditch Amazon Web services for Google AppEngine? - fromedome
http://www.alleyinsider.com/2008/5/googles_app_engine_opens_for_business

======
mdasen
No. Google's AppEngine just isn't great for small sites (and by small I mean
anything under reddit/digg sized).

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.

------
cmer
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.

------
giardini
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.

~~~
koolkao
"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.

------
justindz
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.

