
AppEngine doesn’t fit the needs of startups on the runway - vaksel
http://www.threeriversinstitute.org/blog/?p=226
======
grandalf
If he's frustrated with app engine, he hasn't built a complex system and had
to refactor it in order to scale -- app engine puts these decisions in your
lap up front, not after you get on techcrunch.

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.

~~~
wmf
Big design up front is bad, but big scaling up front is good?

~~~
grandalf
Not at all.

Consider Rails: Convention over configuration. The same applies to app engine,
only with a slightly more restrictive set of conventions.

------
KentBeck
Interesting comments below. Apparently my point wasn't as clear as I hoped.
I'll try once more--in the runway portion of a startup, especially when
bootstrapping, I am willing to completely ignore scale if I can gain an order
of magnitude in cycle time for experiments.

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.

------
vomjom
The main problem with AppEngine is vendor lock-in.

If you write your program to AppEngine, and Google decides one day to close
down your site, you have no options.

~~~
grandalf
Not really -- someone could easily write an nginx/hypertable system to let you
run your app engine app on other hardware.

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.

~~~
fauigerzigerk
He didn't say that they might shut down AppEngine. He said they might decide
to close down your site. No library stops working from one day to the next.

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.

~~~
grandalf
The risk you are describing is that Google decides to shut down YOUR site
only?

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.

~~~
fauigerzigerk
The risk that my site could be shut down without notice ranks pretty high.
Just think of copyright issues of the sort that Google itself has all the
time. What would be Google's reaction to a cease and desist letter be?

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.

~~~
grandalf
Good point about a cease and desist letter, but I do think you'd run that
risks with a lot of hosting companies and even bandwidth providers.

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.

~~~
fauigerzigerk
Yes you're completely right that I may have that problem with other hosting
companies as well. And that's why it's so important to be able to move if need
be.

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.

~~~
grandalf
True. There isn't currently a great path away from app engine, but there is
nothing about app engine that prevents someone from building one.

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.

------
jshen
The title is terribly misleading and the article is silly. The bulk of the
article lays out a scenario in which you would and should use a relational
database. i.e. he's got some data and wants to run arbitrary queries on it.
Claiming that app engines isn't a good fit for startups because it's not good
at this is absurd.

