Selling App Engine Apps
Timofey Danshin
Nick Johnson (Google)
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
--
Nick Johnson, Developer Programs Engineer, App Engine
Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047
bFlood
that is how we will be deploying our app. Users add a specific email
address as a developer and then we load/maintain the source code
remotely. A simple cron request makes a call back to our controlling
app (on GAE) so we can change limits, upgrade features or turn off the
remote app (in the event they subsequently remove the developer email
account and stop paying). There are probably many other ways to combat
this issue
this setup works well in practice. The user pays Google directly for
usage and then licenses the software from us. It turned out to be a
lot easier then running it as a service (single GAE app) and having to
be the middle-man between the user and Google. Trying to estimate how
they would be billed per month was difficult and seemed like a
duplication of the existing infrastructure. Also, a flat fee might
have been more profitable (or not) but IMO does not play to one of
GAE's biggest strengths, true utility billing.
of course, this all breaks if Google decides to allow code downloads
in the future but we'll cross that bridge if and when we come to
it :)
cheers
brian
On Jan 18, 10:47 am, "Nick Johnson (Google)" <nick.john...@google.com>
wrote:
> Hi Timofey,
>
> You own the app, so you're welcome to do anything you like with it as long
> as it's not in violation of our TOS. If they add you as an administrator on
> an app they've created, you can, of course, deploy your app to it.
>
> -Nick Johnson
>
> On Mon, Jan 18, 2010 at 3:41 PM, Timofey Danshin
> <rus.mcdevelo...@gmail.com>wrote:
>
>
>
>
>
> > Hi. I've written a decent web-app on app-engine. Do i have the right to
> > sell it to others? I mean, not the source code, but install the app onto
> > their app engine accounts?
>
> > Thank you in advance,
> > Best Regards,
> > Timofey Danshin.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google App Engine" group.
> > To post to this group, send email to google-a...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
Nick Johnson (Google)
hi Timofey
that is how we will be deploying our app. Users add a specific email
address as a developer and then we load/maintain the source code
remotely. A simple cron request makes a call back to our controlling
app (on GAE) so we can change limits, upgrade features or turn off the
remote app (in the event they subsequently remove the developer email
account and stop paying). There are probably many other ways to combat
this issue
this setup works well in practice. The user pays Google directly for
usage and then licenses the software from us. It turned out to be a
lot easier then running it as a service (single GAE app) and having to
be the middle-man between the user and Google. Trying to estimate how
they would be billed per month was difficult and seemed like a
duplication of the existing infrastructure. Also, a flat fee might
have been more profitable (or not) but IMO does not play to one of
GAE's biggest strengths, true utility billing.
of course, this all breaks if Google decides to allow code downloads
in the future but we'll cross that bridge if and when we come to
it :)
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Timofey Danshin
--
Best Regards,
Timofey Danshin.
Eli Jones
Timofey Danshin
Andrew Chilton
2010/1/19 bFlood <bflo...@gmail.com>:
> that is how we will be deploying our app. Users add a specific email
> address as a developer and then we load/maintain the source code
> remotely. A simple cron request makes a call back to our controlling
> app (on GAE) so we can change limits, upgrade features or turn off the
> remote app (in the event they subsequently remove the developer email
> account and stop paying). There are probably many other ways to combat
> this issue
Wow, cool. I've been thinking of setting up one app for a while and
letting other Google Apps just add it via their accounts. Separating
data for each mapped domain seems to be easy enough, but letting lots
of people from different Google Apps Domains log in seems to be the
hardest thing to do (so your suggestion above seems to get around
this, thanks).
For more information about my login issues/problems, see:
http://groups.google.com/group/google-appengine/browse_thread/thread/a71984d787536d82/d64828849b924b83
Further to this, I tried OpenID and the federated login, but it seems
the IDP stuff (or whatever it is extra in the federated login
(discovery?)) isn't liked by the Python OpenID library (yet?). It
makes me sad this is so hard to set up. It seems the Google Labs
ShortLinks service somehow works exactly how I would like mine to but
I'm yet to find an answer as to how they did it. If anyone knows, I'd
be very grateful :)
> this setup works well in practice. The user pays Google directly for
> usage and then licenses the software from us. It turned out to be a
> lot easier then running it as a service (single GAE app) and having to
> be the middle-man between the user and Google. Trying to estimate how
> they would be billed per month was difficult and seemed like a
> duplication of the existing infrastructure. Also, a flat fee might
> have been more profitable (or not) but IMO does not play to one of
> GAE's biggest strengths, true utility billing.
Maybe this is the way forward for me. I guess there is also some way
to remotely disable the app (e.g. when their license is up) since
otherwise the user could just disable your access to the AppEngine
control panel. I guess your application has something like this in it?
Of course, this solution doesn't scale for hundreds or even thousands
of users so I'm kinda hesitant to do it. I'd love if you could
reassure me it can be done. :)
Cheers,
Andy
--
contact: Andrew Chilton
website: http://www.chilts.org/
bFlood
openid - I really wish Google would just build support for
FriendConnect directly into GAE. I don't have a good answer for you
right now, maybe someone else has done this already. that being said,
Nick built the very useful AEoid plugin: http://bit.ly/75CEy5
remote disable - there's actually two kill switches in our app but
there are probably others you could use. I'm leaning towards 1 now,
its more flexible
1) a cron job contacts our controlling GAE app, it can tell the app to
shutdown. this controlling app has a simple web UI where we store
client information (for instance, our 3rd party purchasing service
Avangate contacts this server with any online purchases for all
relevant accounts). Out clients cannot disable cron jobs and they
cannot see the urlfetch requests to the controlling app (although I
suppose Google could update the UI for this at some point)
2) we will be automating deployment using a native app on EC2. It
powers appcfg.py using additional metadata for each known instance.
Since this is automated, an extra site_config.txt file is (re)written
for each deployment. This file contains license info and a validity
date so the killswitch is hard-coded (note - the only way to update
this file is via appcfg, so if you need more flexibility, the cron
request route may be easier)
and finally, I forgot to mention another pro/con of this setup.
1) since all of our clients have their own GAE app, they also have
access to their own GAE free daily usage limits. Running this as a
service would have eaten these limits up very quickly (we are dealing
with a lot of data) but now they are spread evenly over each client.
over the course of a year, this is significant (although I'll have
better metrics as this year progresses)
2) conversely, each client then has to deal with the dreaded "cold
start" issue. The significance of this widely depends on how their
data is being accesses but I still think it's the biggest issue with
GAE right now (Nick - did I read correctly on the GAE-Java forum that
their instance should be keep alive for an *hour*?)
cheers
brian
On Jan 19, 1:56 am, Andrew Chilton <andychil...@gmail.com> wrote:
> Hi bFlood,
>
> 2010/1/19 bFlood <bflood...@gmail.com>:
>
> > that is how we will be deploying our app. Users add a specific email
> > address as a developer and then we load/maintain the source code
> > remotely. A simple cron request makes a call back to our controlling
> > app (on GAE) so we can change limits, upgrade features or turn off the
> > remote app (in the event they subsequently remove the developer email
> > account and stop paying). There are probably many other ways to combat
> > this issue
>
> Wow, cool. I've been thinking of setting up one app for a while and
> letting other Google Apps just add it via their accounts. Separating
> data for each mapped domain seems to be easy enough, but letting lots
> of people from different Google Apps Domains log in seems to be the
> hardest thing to do (so your suggestion above seems to get around
> this, thanks).
>
> For more information about my login issues/problems, see:http://groups.google.com/group/google-appengine/browse_thread/thread/...
Andrew Chilton
2010/1/20 bFlood <bflo...@gmail.com>:
> openid - I really wish Google would just build support for
> FriendConnect directly into GAE. I don't have a good answer for you
> right now, maybe someone else has done this already. that being said,
> Nick built the very useful AEoid plugin: http://bit.ly/75CEy5
Yep, I've seen Nick's OpenID and I do have a question for him
(probably in a different channel somewhere). Essentially it's OpenID
but of course the Google Apps Hosted OpenID has extended discovery
which I don't think (or can't get) the Python OpenID library to do.
Anyone had any success doing this? Especially with the endpoint
https://www.google.com/accounts/o8/site-xrds?hd=example.org
> remote disable - [snip]
Thanks for your descriptions Brian, they were pretty helpful
(especially from someone actually doing it). I still really want to
just have one app with proper login from their own Google Apps but
still haven't come across a solution to do it!
Nick Johnson (Google)
Hi Brian,
2010/1/20 bFlood <bflo...@gmail.com>:
> openid - I really wish Google would just build support forYep, I've seen Nick's OpenID and I do have a question for him
> FriendConnect directly into GAE. I don't have a good answer for you
> right now, maybe someone else has done this already. that being said,
> Nick built the very useful AEoid plugin: http://bit.ly/75CEy5
(probably in a different channel somewhere). Essentially it's OpenID
but of course the Google Apps Hosted OpenID has extended discovery
which I don't think (or can't get) the Python OpenID library to do.
Anyone had any success doing this? Especially with the endpoint
https://www.google.com/accounts/o8/site-xrds?hd=example.org
> remote disable - [snip]
Thanks for your descriptions Brian, they were pretty helpful
(especially from someone actually doing it). I still really want to
just have one app with proper login from their own Google Apps but
still haven't come across a solution to do it!
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
