GAE vs. Rails
13 views
Skip to first unread message
ebdb
Jul 26, 2008, 3:29:26 PM7/26/08
to Google App Engine
I'm trying to decide whether to invest time and energy into GAE. I've
done a bunch of projects in Ruby on Rails, so I've put a lot of time
into learning how to do that. Taking on GAE would slow me down for a
while so it has to be really worth it. So far, my analysis is that
there are some major benefits and big risks:
Potential benefits:
- Don't need to worry about system administration.
- Free hosting up to about 5 million page views a month. I'm guessing
it might cost anywhere from $20 to $100 a month to serve that many
page views using Ruby on Rails, depending on what's on the pages.
- Maybe better performance compared to Ruby?
- Users log in with their Google account (though this has some
downsides -- hinders migrating away from GAE, and could add complexity
if you want to support non-Google users)
- Python and Django instead of Ruby and Rails. Some would see this as
a benefit.
- In general if you're running on GAE, your interests and Google's
interests are roughly aligned. Perhaps more so than with a
conventional VPS host. If your app is successful they make more money
-- they charge you for system resources and they can potentially sell
ads on your app. Having your interests aligned with those of a
powerful force like Google could be advantageous.
Risks:
The main risk is that you're really at Google's mercy.
- Google could decide to change their prices to anything they want any
time.
- You can't easily switch to a different platform because of the non-
relational data store.
- Using Google's authentication would be convenient and maybe would
bring in more users, but would make it almost impossible to move away
from if Google raised their prices.
So those are my thoughts so far. Any comments would be appreciated.
Thanks,
E
done a bunch of projects in Ruby on Rails, so I've put a lot of time
into learning how to do that. Taking on GAE would slow me down for a
while so it has to be really worth it. So far, my analysis is that
there are some major benefits and big risks:
Potential benefits:
- Don't need to worry about system administration.
- Free hosting up to about 5 million page views a month. I'm guessing
it might cost anywhere from $20 to $100 a month to serve that many
page views using Ruby on Rails, depending on what's on the pages.
- Maybe better performance compared to Ruby?
- Users log in with their Google account (though this has some
downsides -- hinders migrating away from GAE, and could add complexity
if you want to support non-Google users)
- Python and Django instead of Ruby and Rails. Some would see this as
a benefit.
- In general if you're running on GAE, your interests and Google's
interests are roughly aligned. Perhaps more so than with a
conventional VPS host. If your app is successful they make more money
-- they charge you for system resources and they can potentially sell
ads on your app. Having your interests aligned with those of a
powerful force like Google could be advantageous.
Risks:
The main risk is that you're really at Google's mercy.
- Google could decide to change their prices to anything they want any
time.
- You can't easily switch to a different platform because of the non-
relational data store.
- Using Google's authentication would be convenient and maybe would
bring in more users, but would make it almost impossible to move away
from if Google raised their prices.
So those are my thoughts so far. Any comments would be appreciated.
Thanks,
E
g-man
Jul 26, 2008, 10:12:09 PM7/26/08
to Google App Engine
So, all the downsides you've mentioned are not technical, but
political...
From the technical side, you have the hosting and scalability problems
solved with the datastore model and Google's infrastructure. The data
backup and migration issues are being addressed in various ways, but
are not solved yet, due to the newness of the system. Python and
Django are solid languages, and (speaking as a 'Rails Refugee'),
produce much cleaner code, due to the lack of all the end..end..end...
constructs (closer to HAML).
Your argument therefore boils down to 'I have to be beholden to Google
for my existence.'
I've got news for everyone: The future of web apps as we knew them is
changing. If I can open a page, see what's been done, and then clone
it in a slightly different way, that formerly unique value evaporates.
Look at the lesson of how Campfire (the flagship 37signals app,
created by the very inventors of Rails) was easily cloned last April.
It was quickly removed upon request, but that shows you what is
happening. When any high-school kid anywhere in the world can write an
app, or copy yours, think what kind of jungle we will live in!
Ironically, DHH himself has seen the way things are going, and in his
recent video outlined a rational 'reality check' for all those who
would create the next Facebook - it probably ain't gonna happen! The
future will be one of many small apps serving business users in
support of their primary products or services, which is kind of a
reflection of the world economy itself.
Therefore, the scalability and data security are nice, the lack of
hassle about hosting is nice, and now we are learning how to do non-
SQL data design and beta-testing the platform and API so it can be a
practical next-generation tool for web applications, not all of which
will be huge!
There are some fine discussions of these various questions here in
this group, so stick around...
political...
From the technical side, you have the hosting and scalability problems
solved with the datastore model and Google's infrastructure. The data
backup and migration issues are being addressed in various ways, but
are not solved yet, due to the newness of the system. Python and
Django are solid languages, and (speaking as a 'Rails Refugee'),
produce much cleaner code, due to the lack of all the end..end..end...
constructs (closer to HAML).
Your argument therefore boils down to 'I have to be beholden to Google
for my existence.'
I've got news for everyone: The future of web apps as we knew them is
changing. If I can open a page, see what's been done, and then clone
it in a slightly different way, that formerly unique value evaporates.
Look at the lesson of how Campfire (the flagship 37signals app,
created by the very inventors of Rails) was easily cloned last April.
It was quickly removed upon request, but that shows you what is
happening. When any high-school kid anywhere in the world can write an
app, or copy yours, think what kind of jungle we will live in!
Ironically, DHH himself has seen the way things are going, and in his
recent video outlined a rational 'reality check' for all those who
would create the next Facebook - it probably ain't gonna happen! The
future will be one of many small apps serving business users in
support of their primary products or services, which is kind of a
reflection of the world economy itself.
Therefore, the scalability and data security are nice, the lack of
hassle about hosting is nice, and now we are learning how to do non-
SQL data design and beta-testing the platform and API so it can be a
practical next-generation tool for web applications, not all of which
will be huge!
There are some fine discussions of these various questions here in
this group, so stick around...
ebdb
Jul 26, 2008, 11:43:03 PM7/26/08
to Google App Engine
On Jul 26, 7:12 pm, g-man <gregor...@gmail.com> wrote:
> So, all the downsides you've mentioned are not technical, but
> political...
I better clarify something: I'm trying to size up whether to invest
> So, all the downsides you've mentioned are not technical, but
> political...
time and energy in learning to develop in Python on GAE. I'm
interested in looking at the situation coldly and deciding based on
facts. I have absolutely no interest in slamming one platform or
another or in worrying about politics. I'm trying to weigh pros and
cons and size up risk.
When I list the possible downsides it's not to piss on GAE or bum
anyone out. I'm saying "these are some potential risk factors I've
noticed. Anyone know of any ways they're mitigated? Any others I
haven't thought of?" Same goes for the GAE advantages I listed.
>
> From the technical side, you have the hosting and scalability problems
> solved with the datastore model and Google's infrastructure.
Scalability is less a concern for what I'm working on. I'm not sure my
apps would ever surpass the five-million-pageview limit.
The data
> backup and migration issues are being addressed in various ways, but
> are not solved yet, due to the newness of the system.
Python and
> Django are solid languages, and (speaking as a 'Rails Refugee'),
> produce much cleaner code, due to the lack of all the end..end..end...
> constructs (closer to HAML).
>
> Your argument therefore boils down to 'I have to be beholden to Google
> for my existence.'
get some insightful comments. But you could say that being at the
mercy of Google is my main concern, for reasons I outlined in my
original post.
> I've got news for everyone: The future of web apps as we knew them is
> changing. If I can open a page, see what's been done, and then clone
> it in a slightly different way, that formerly unique value evaporates.
lets us throw together apps quickly? That's sort of true of Rails too
though.
E
Greg
Jul 27, 2008, 12:51:03 AM7/27/08
to Google App Engine
A couple of comments...
> - Users log in with their Google account (though this has some
> downsides -- hinders migrating away from GAE, and could add complexity
> if you want to support non-Google users)
I don't understand why everyone gets hung up on this. GAE provides
everything you need to do your own authentication, so you have a
choice. Either use their authentication system, to save time, and
accept the closer ties with Google. Or write your own authentication
and remain (more) independant.
I don't worry too much about Google's pricing - in fact I'm looking
forward to the day when they start charging, because then the quotas
should disappear. I think Google built GAE to get more of the internet
on their own servers, so they can spider it easier, and reduce the
risk of ISPs starting to charge them for delivering traffic. They will
make some money off it too, but if they put prices up, they'll drive
people back to Amazon or their own servers, so they can't get too
unreasonable.
Lastly, one risk you haven't mentioned is service levels, particularly
during this preview period - and we don't know how long the preview
period will last. I have an application I'd love to migrate to GAE,
because it would take the sysadmin worry away, but major banks use the
app and I can't risk any outages. This will come with time - hopefully
Google will give us an SLA, but we'll also get a pretty good idea
after a few months of use.
Cheers!
Greg.
> - Users log in with their Google account (though this has some
> downsides -- hinders migrating away from GAE, and could add complexity
> if you want to support non-Google users)
everything you need to do your own authentication, so you have a
choice. Either use their authentication system, to save time, and
accept the closer ties with Google. Or write your own authentication
and remain (more) independant.
I don't worry too much about Google's pricing - in fact I'm looking
forward to the day when they start charging, because then the quotas
should disappear. I think Google built GAE to get more of the internet
on their own servers, so they can spider it easier, and reduce the
risk of ISPs starting to charge them for delivering traffic. They will
make some money off it too, but if they put prices up, they'll drive
people back to Amazon or their own servers, so they can't get too
unreasonable.
Lastly, one risk you haven't mentioned is service levels, particularly
during this preview period - and we don't know how long the preview
period will last. I have an application I'd love to migrate to GAE,
because it would take the sysadmin worry away, but major banks use the
app and I can't risk any outages. This will come with time - hopefully
Google will give us an SLA, but we'll also get a pretty good idea
after a few months of use.
Cheers!
Greg.
Bill
Jul 27, 2008, 3:44:54 PM7/27/08
to Google App Engine
E,
I'm familiar with both platforms and am in a similar situation.
Here's how I break it down:
If a primary concern is starting with an architecture that
can scale, then AE (AppEngine) is a big win. Some will call
it pre-optimization. Others will say it's doing it right
the first time and feeling free to grow your app users without
fear. For me, I really like the idea of applying scaling
constraints upfront to build my app platform AS LONG AS IT
ISN'T TOO CONSTRAINING (and this is the big unanswered
question mark that will only be answered in time.)
I'm not sure the above concern should be your primary one,
since you explicitly say your apps will be small. Depends on
your plans. Depends on whether you can afford the time for
upfront learning python and different platform.
Python is good language like Ruby. Easier to make DSLs with
Ruby but I'm actually enjoying the tightness of Python. One
drawback of AE is the sandboxing and possible
unavailability of some python packages, so it doesn't have
complete python libraries.
There are RoR solutions that provide AppEngine-like scaling.
If you have bucks, look at EngineYard. If you like the easy
deployment like AE, look at Heroku. Or you can just use
simple small virtual machines like a SliceHost that can
be resized later.
I don't want to deal with a significant amount of the stack
necessary for high-availability web apps. This means
master/slave DB, multiple server boxes, load balancing, etc.
There's a lot that can go wrong there and I'd rather be
programming apps. I'm outsourcing all of that if possible.
Given the above, I will be at *someone's* mercy, whether it's
Heroku, EngineYard, RightScale, etc. This is where Google's
namebrand and ability to undercut others in price impacts my
choice. If, worse-case scenario, I have to leave my primary
platform, it's bad news whoever I go with. You'd certainly
have to make some tweaks and would be better off with a generic
Rails installation. For my AppEngine apps, I'd have to use
the open-source SDK APIs and replace the back-end datastore,
etc, if others haven't already done it using HBase or another
open datastore.
My conscious choice: Embrace constraints and be optimistic.
I am building for an optimistic future and not a pessimistic
fall-back. Consider Google-failure risk lumped into the already
considerable risk of being a self-funding entrepreneur.
Let's break it down:
1) I rock and Google rocks.
My apps are wildly successful, scale to gazillions, and I
focus on app development not as much platform issues.
Google's pricing is a big win compared to other scalable
platforms.
2) I rock and Google sucks.
My apps are wildly successful but AppEngine fails to deliver.
Google does a worse job hosting my popular website than
other companies. If I hosted a Rails app, I could move
between multiple turn-key hosts. My python webapp needs to
be moved to a Django host with a custom datastore.
3) I suck and Google rocks.
My app is unsuccessful.
4) I suck and Google sucks.
My app is unsuccessful.
Entrepreneurs win under scenario #1. Scenario #2 is unlikely.
#3 and #4 only matter if using AppEngine contributed to my
app not being good, and I think that's unlikely as well.
Other considerations though: AppEngine's not production-ready
until they lift quotas and possibly allow HTTPS if you aren't
using their authentication.
I'm familiar with both platforms and am in a similar situation.
Here's how I break it down:
If a primary concern is starting with an architecture that
can scale, then AE (AppEngine) is a big win. Some will call
it pre-optimization. Others will say it's doing it right
the first time and feeling free to grow your app users without
fear. For me, I really like the idea of applying scaling
constraints upfront to build my app platform AS LONG AS IT
ISN'T TOO CONSTRAINING (and this is the big unanswered
question mark that will only be answered in time.)
I'm not sure the above concern should be your primary one,
since you explicitly say your apps will be small. Depends on
your plans. Depends on whether you can afford the time for
upfront learning python and different platform.
Python is good language like Ruby. Easier to make DSLs with
Ruby but I'm actually enjoying the tightness of Python. One
drawback of AE is the sandboxing and possible
unavailability of some python packages, so it doesn't have
complete python libraries.
There are RoR solutions that provide AppEngine-like scaling.
If you have bucks, look at EngineYard. If you like the easy
deployment like AE, look at Heroku. Or you can just use
simple small virtual machines like a SliceHost that can
be resized later.
I don't want to deal with a significant amount of the stack
necessary for high-availability web apps. This means
master/slave DB, multiple server boxes, load balancing, etc.
There's a lot that can go wrong there and I'd rather be
programming apps. I'm outsourcing all of that if possible.
Given the above, I will be at *someone's* mercy, whether it's
Heroku, EngineYard, RightScale, etc. This is where Google's
namebrand and ability to undercut others in price impacts my
choice. If, worse-case scenario, I have to leave my primary
platform, it's bad news whoever I go with. You'd certainly
have to make some tweaks and would be better off with a generic
Rails installation. For my AppEngine apps, I'd have to use
the open-source SDK APIs and replace the back-end datastore,
etc, if others haven't already done it using HBase or another
open datastore.
My conscious choice: Embrace constraints and be optimistic.
I am building for an optimistic future and not a pessimistic
fall-back. Consider Google-failure risk lumped into the already
considerable risk of being a self-funding entrepreneur.
Let's break it down:
1) I rock and Google rocks.
My apps are wildly successful, scale to gazillions, and I
focus on app development not as much platform issues.
Google's pricing is a big win compared to other scalable
platforms.
2) I rock and Google sucks.
My apps are wildly successful but AppEngine fails to deliver.
Google does a worse job hosting my popular website than
other companies. If I hosted a Rails app, I could move
between multiple turn-key hosts. My python webapp needs to
be moved to a Django host with a custom datastore.
3) I suck and Google rocks.
My app is unsuccessful.
4) I suck and Google sucks.
My app is unsuccessful.
Entrepreneurs win under scenario #1. Scenario #2 is unlikely.
#3 and #4 only matter if using AppEngine contributed to my
app not being good, and I think that's unlikely as well.
Other considerations though: AppEngine's not production-ready
until they lift quotas and possibly allow HTTPS if you aren't
using their authentication.
luismgz
Jul 27, 2008, 4:10:45 PM7/27/08
to Google App Engine
g-man summed it up pretty well...
Let me add a few points:
1) Django is not a "language" but a framework. You don't have to use
it if you don't lik it. There are hundreds of alternatives compatible
with GAE.
2) Ruby may be the next (or one of the next) languages supported. I
guess it's just a matter of time, since Ruby and Python share many
similarities.
And IMHO the advantages of GAE surpass by a large margin its perceived
disadvantages.
I believe the main concern would be the switch from traditional
databases to the BigTable datastore.
Luis
Let me add a few points:
1) Django is not a "language" but a framework. You don't have to use
it if you don't lik it. There are hundreds of alternatives compatible
with GAE.
2) Ruby may be the next (or one of the next) languages supported. I
guess it's just a matter of time, since Ruby and Python share many
similarities.
And IMHO the advantages of GAE surpass by a large margin its perceived
disadvantages.
I believe the main concern would be the switch from traditional
databases to the BigTable datastore.
Luis
ebdb
Jul 27, 2008, 7:37:59 PM7/27/08
to Google App Engine
On Jul 27, 12:44 pm, Bill <billk...@gmail.com> wrote:
> E,
> I'm familiar with both platforms and am in a similar situation.
> Here's how I break it down
Bill, thanks for the awesome analysis. That's exactly the type of
> E,
> I'm familiar with both platforms and am in a similar situation.
> Here's how I break it down
methodical breakdown I was looking for.
While I agree with your assumptions and observations, I'm tending
towards a different conclusion. Maybe I'm more pessimistic by nature.
My take is that given GAE's risk factors (e.g., no telling where
Google's going to go with their pricing), it has to blow Rails-on-a-
VPS out of the water to make sense.
I'll keep an eye on it though, and maybe start learning Python if I
can find the time. Some things about GAE seem really great to me, such
as avoiding the tedium and peril of system administration.
E
Reply all
Reply to author
Forward
0 new messages