

Google App Engine update: performance improvements & new admin tools - mrud
http://googleappengine.blogspot.com/2010/10/new-app-engine-sdk-138-includes-new.html

======
johnnytee
I'm using app engine for all my new app idea and here's why.

1\. It's great for a one man show. Building an app takes a lot of time. I
don't need to speed my time being a sysadmin. I want to spend it coding. I've
used EC2 and a lot of my time was just spent tweaking and getting an instance
working and making sure you don't lose your data.

2\. The api's are great. I have instant access to memcache, mail, image and
task queue apis, zero configuration.

3\. I can build and test an app idea for free. If it gets traction it's
already to be scaled.

4\. I like Python. I used to be a php guy but after working with python my
tastes have changed.

5\. It's fast (most of the time). I do every once in awhile experience latency
but no deal breakers.

Possible cons. 1\. Technology lock in. Lets face it though, you're locked in
with whatever stack you choose. If you get successful who cares, then you can
hire so one to re-code your app if you desire.

2\. Python and Java only, yep I can see this being a con. I had to learn
Python to use app engine, which I don't think is a bad thing.

3\. Terms and conditions. You are bound to their T's and C's

I'm sure there are more cons but in my situation I want to build an app
quickly and it out the door. If it takes off I'm ready to scale and make some
money:)

~~~
bmelton
Should you add 'No RDBMS' as a con, or has that changed since the last time I
looked? Cause that is, quite frankly, the only con that matters to me.

~~~
johnnytee
Yep no relational db, I haven't ran into an issue I can't solve however with
bigtable.

Here's a good article on modeling relationships.
[http://blog.notdot.net/2010/10/Modeling-relationships-in-
App...](http://blog.notdot.net/2010/10/Modeling-relationships-in-App-Engine)

------
ianl
Did they ever release any information about how popular App Engine is? I've
always wondered how successful it's been and how many startups are willing to
lock themselves into the Google Infastructure.

~~~
mdasen
Here are some of my thoughts on it.

First, a startup's advantage is that you're small. You don't have to worry
about serving 100 million users. That means you can make your life a bit
easier as you grow. You can use a relational database while you're small, add
memcached as you grow, denormalize, etc. AppEngine makes you develop your
application to your end point in some ways. You can't use the techniques that
get you out the door fast with a high-quality product. Rather, you have to
over-engineer your product to scale to a number of users you'll likely never
have. Take Stack Overflow as an example. They're a really successful service
and they're running on 5 servers and a SQL database. Now, I'm sure they've
done caching and a bit of denormalization, but the key is that they could
launch without doing that and as they got more and more users they could add
that in.

Second, Google's infrastructure doesn't really have capabilities for some of
the cool things. For example, geolocation is a pain
(<http://code.google.com/appengine/articles/geosearch.html>). MapReduce
doesn't really exist. I mean, there are ways to deal with your data. The key
to MapReduce is its distributed nature - that portions of the data can be
computed on different boxes at the same time and then returned. This limits
your ability to do the kind of warehouse data processing that can give you
really cool results. And AppEngine is meant for web apps, not things trying to
compute stuff like Google does. Google is addressing lots of things. You can
now get incoming email. They introduced the task queue. But you're beholden to
a third party for a lot of things. Part of being a startup is trying to be
beholden to yourself and changing course quickly as you see something
important. AppEngine might limit you there depending on what you're looking to
do. Of course, it might also help.

Third, you're locked into Google's cost structure. It isn't expensive or
unfair. However, it is likely to be more expensive than owning your own boxes
if you're large and you have the issue that Google may not lower prices in
step with competitors. Amazon has been aggressively cutting prices, Linode has
been upping RAM, etc. It's a lot harder to migrate away from App Engine.

Fourth, you're beholden to Google for your application's health. Google is a
great company with wonderful engineers and AppEngine isn't abandoned at all.
That said, they have had datastore problems that saw the time to get one entry
from the datastore rise to 1.5 seconds or higher. Even after fixing the
problem, it isn't the fastest option out there. Note, App Engine is made to be
scalable and Fast Enough. It isn't tuned for pure speed. Basically, you have
to start closer to the more difficult to build, highly-scalable architecture
that you could be building as your site grows.

It's a cool product. The problem from my perspective is that there's little
reason for me to engineer a site that scales to high levels if no one is going
to use it. I don't know how many people will use a site until it's built. I
have a better chance of people using my site if I can a) get it out quickly
and b) add the features users want rather than the features that are easy with
AppEngine. I'm not going to get all my users overnight. In the months it takes
to get lots of users, I can optimize my code. Plus, if it takes off, I think
it would be a bit weird to be beholden to a single vendor. Yes, there are
open-source App Engine mostly compatible things out there and work arounds.
Still, it's easier to move from Linode to Amazon or Slicehost to a physical
server.

I've rambled a little too much, but it's half past midnight.

~~~
Yaggo
AppEngine is (especially) nice for hobby projects fitting into the free quota.
Although the concept is generally great, for commercial use there are some
frustrating restrictions, such as lack of support for naked domains, which
nailed my decision to go with Tornado + MongoDB + <your-favorite-cloud-
hosting>.

~~~
olifante
What do you mean by lack of support for naked domains? You can host your
AppEngine app at yourdomain.com via Google Apps, as described here:
<http://code.google.com/appengine/docs/domain.html>

I haven't heard of any limitations on using custom domains for commercial use,
cf. [http://groups.google.com/group/google-
appengine/browse_threa...](http://groups.google.com/group/google-
appengine/browse_thread/thread/4e1299bda9341b07)

~~~
Yaggo
> Due to recent changes, App Engine no longer supports mapping your app to a
> naked domain. If your domain registrar supports URL redirects, you can
> redirect from <http://yourdomain.com> to e.g <http://www.yourdomain.com> or
> <http://appid.yourdomain.com>.

[http://code.google.com/appengine/kb/general.html#naked_domai...](http://code.google.com/appengine/kb/general.html#naked_domain)

[http://stackoverflow.com/questions/817809/how-to-use-
google-...](http://stackoverflow.com/questions/817809/how-to-use-google-app-
engine-with-my-own-domain-not-subdomain)

<http://blog.notdot.net/2009/12/Naked-domains-on-App-Engine>

(For non-commercial use this limitation may be more acceptable, but if you are
seriously launching a commercial service, you probably want to freely choose
your domain.)

------
richardw
I'm using it as the backend for my Windows app's sync. So far it's been great.
Latency isn't that much of an issue because sync happens in the background,
but users report it as very quick.

I'm keen to put a GWT front-end on it. I've tried that on a side project and
it worked well. I do worry about the relative unpredictablility compared to
just a plain box, but it's balanced with the fact that I really don't want to
worry about operating system and web server level security or admin.

------
mshafrir
Deleting all of a kind will definitely be handy for those in the early
"hypothesis testing" stages of their apps.

