[google-appengine] Per-domain data stores and selling our apps to people who use google domains...

[Andy Burke]

Hi,

My name is Andy Burke. I have a background in the video game
industry, but I also dabble in GAE. About a year ago I got excited
about developing a GAE-based issue tracker. GAE seems like the
perfect platform for such an application. I began working, got my
issues into the datastore, got some rudimentary milestone support,
email integration, all that jazz. Then I started thinking about how I
was going to roll this application out. I realized that I'd need to
add a lot of complexity to my data model to keep different 'domains'
separate (a domain being something like a company who can have any
number of projects in the system). Additionally, I'd end up, as the
developer of the application, with access to all these different
domains' data. Why would a company want to use my issue tracking
software if they knew I could gain access to all their internal
issues? I'm just some guy off the street, I'm not Google, why should
they trust me?

After thinking about all this, I opened an issue w/ GAE:

http://code.google.com/p/googleappengine/issues/detail?id=1206

The features I'm effectively asking for in the issue are:

- Each google apps domain should have its own datastore
- Each google apps domain should be able to install an app created
with GAE into its own domain

Now, this seems like it would be great for developers and great for
Google:

- It would make it a lot easier to develop apps that might be used by
lots of different organizations, simplifying GAE developers' datastore
models
- It would mean that billing for application usage could be per-domain
in addition to per-app
- Eg: if I make a really popular app, I don't have to pay google for
the bandwidth and storage, the domains that install and use it do
- Google could build out a way that GAE-developed apps could be
installed into domains with various pricing models:
- One-time cost
- Subscription based
- Per-transaction
- Google could skim money off the top, the rest would be passed on to
the app developer, ala the iPhone App Store or Facebook credits

Let me give you a little imaginary scenario that demonstrates what I'd
like to see happen with GAE:

I develop my issue tracking software and it's really nice. I set my
app up to use per-domain datastores. I also set my app to be
available for a monthly subscription of $10, with the first month
free. So now people who use Google apps for their domains can install
my app into their domain and try it out for the first month. If they
want to keep using it, they'll start paying $10/month through Google
checkout (or whatever service Google provides). All their issues are
stored in their own domain. Even as the developer, I don't have
access to them and they don't have to worry about privacy issues from
me. If they generate a ton of datastore queries because they're a
huge company, they get billed for that, not me. Google takes their
cut from the subscription payment, say 30%. Google's happily getting
$3/month for each domain using my app. I'm happily getting $7 a month
and not worrying about the datastore for all these different
companies. The company that's using my app is happy because their
data is all private. They're also really happy they hosted with
Google apps because they realize they have access to tons of software
as a service that's easy to install in their domain, maintains their
privacy and adds value to using Google apps.

This seems like such a huge win for Google, GAE developers and Google
Apps customers: why has this issue been languishing for over a year?

I'd really love to hear if these features have any chance of being
implemented. I haven't done much on GAE with regard to apps that
could be used as SaaS in the last year because it seems so daunting to
handle the datastore/bandwidth usage costs of GAE, the separation of
data by domain, the amount of work I'd need to do to be able to bill a
domain for their usage, etc. It seems like all that would be much
better handled in the GAE and Google Apps themselves.

If these features are implemented, I'll be developing SaaS on GAE in a
heartbeat and I'm sure lots of other developers would be, too. It
just seems like such a win for GAE, Google Apps and GAE developers.
If you're a GAE developer and you agree, please make sure to star the
issue:

http://code.google.com/p/googleappengine/issues/detail?id=1206

Thanks,
andy

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

[Stephan Hartmann]

Hi Andy,

In general i like your idea and i stared it.

Do i understand it right, that you could already achieve this, if every customer would have its own GAE account and deploy your app to it and add it to his apps domain?
You just want to make this process a one-click-buy in the Google marketplace?
Then it should be also possible to update the applications via marketplace in case there is a new version.

But you should still have the choice to offer an app also as one-for-all with real multi-tenancy support.

Regards,
Stephan

2010/5/6 Andy Burke <abu...@bitflood.org>

[bFlood]

this is a great idea, starred.

right now we deploy our app to each user's GAE instance somewhat
manually. it's not too difficult with a limited number of clients but
an automated method using a Google sanctioned app store would be
great.

cheers
brian

> > google-appengi...@googlegroups.com<google-appengine%2Bunsubscrib e...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/google-appengine?hl=en.
>
> --
> 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 athttp://groups.google.com/group/google-appengine?hl=en.

[Tristan]

In your model, how will you provide support / maintenance to these
applications? If you don't have access to the application instance,
and your customers don't have access to the source code, how do you
solve issues that arise? Say a corrupt datastore for some reason? Then
the company will still have to trust you with their data as you fix
any bugs that pop up. Updates won't solve everything. In that
scenario, you'll end up coding a whole bunch of datastore convenience
tools to allow them better control of their data then the datastore
viewer. That will complicate things probably on the same level as
having multi-tenancy app in the first place.

I like the idea, but I also feel that the ability to provide
maintenance is essential, which requires trust anyway.

Tristan

[Nick Johnson (Google)]

Hi Andy,

On Thu, May 6, 2010 at 8:19 PM, Andy Burke <abu...@bitflood.org> wrote:

Hi,

My name is Andy Burke.  I have a background in the video game
industry, but I also dabble in GAE.  About a year ago I got excited
about developing a GAE-based issue tracker.  GAE seems like the
perfect platform for such an application.  I began working, got my
issues into the datastore, got some rudimentary milestone support,
email integration, all that jazz.  Then I started thinking about how I
was going to roll this application out.  I realized that I'd need to
add a lot of complexity to my data model to keep different 'domains'
separate (a domain being something like a company who can have any
number of projects in the system).

This doesn't have to involve a great deal of extra complexity in your code. The keyword here is "multitenancy", and there are several possible solutions. One option is detailed in my blog post here: http://blog.notdot.net/2009/11/API-call-hooks-for-fun-and-profit and another here: http://blog.notdot.net/2009/11/Enforcing-data-isolation-with-CurrentUserProperty

A third option is to use a model that several of our customers are already using: Have your users create an app engine app and add you as an administrator, whereupon you deploy your app to their instance.

 

 Additionally, I'd end up, as the
developer of the application, with access to all these different
domains' data.  Why would a company want to use my issue tracking
software if they knew I could gain access to all their internal
issues?  I'm just some guy off the street, I'm not Google, why should
they trust me?

Users seem generally tolerant of this if you are professional. FogBugz, for example, have an excellent bug tracking (and more) platform, which is optionally hosted on their hardware. The same goes for a plethora of other companies.

One important thing to note is that there are few (if any) plausible scenarios that _don't_ require trust from your users. Since you wrote the code, you could easily be doing nearly anything with their data; if you provide for updates, you could modify the app to disclose information to you, even if you don't have direct access to their datastore. Essentially the only way around this would be to provide your users with the source, and make updates entirely manual and up to them to apply.

 

After thinking about all this, I opened an issue w/ GAE:

http://code.google.com/p/googleappengine/issues/detail?id=1206

The features I'm effectively asking for in the issue are:

- Each google apps domain should have its own datastore
- Each google apps domain should be able to install an app created
with GAE into its own domain

You can certainly do this already by having your users create their own app instances as I outlined above, of course.

--
Nick Johnson, Developer Programs Engineer, App Engine Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047
Google Ireland Ltd. :: Registered in Dublin, Ireland, Registration Number: 368047

[Andy Burke]

> This doesn't have to involve a great deal of extra complexity in your code.
> The keyword here is "multitenancy", and there are several possible
> solutions. One option is detailed in my blog post here:http://blog.notdot.net/2009/11/API-call-hooks-for-fun-and-profitand another

> here:http://blog.notdot.net/2009/11/Enforcing-data-isolation-with-CurrentU...

I'm sorry, but hooking the API to do this seems pretty complex to me.

As a developer, it would be much nicer if I could create apps that
were specifically meant to be deployed into a customer's Google Apps
domain. My code would be significantly simpler in that it would just
operate on a datastore assuming that the datastore is owned by the
consumer of the app and not shared with any other consumers.

> A third option is to use a model that several of our customers are already
> using: Have your users create an app engine app and add you as an
> administrator, whereupon you deploy your app to their instance.

This seems like an awfully big hurdle for someone to deploy an app.
Shouldn't Google's goal be to make Google Apps as easy to use as
possible? By making it easier for 3rd party developers to enhance the
value of Google Apps, both Google and the 3rd party developers would
benefit.

The GAE system is already fairly user-unfriendly. Every time I go to
my dashboard, I get redirected to my start page which doesn't actually
list any of my apps. There's no support email for me to talk to.
Instead, I have to craft specific URLs to get to my apps. Now, this
is likely a bug and I'll eventually get around to reporting it, but
imagining trying to walk some customer through the process of getting
an account and deploying an app seems like pure pain to me.

I'd much prefer if there were a Google Apps Marketplace. I could
create my app with GAE and configure it to be made available through
the Google Apps Marketplace. People who have Google Apps could easily
browse/search the marketplace, where I could provide screenshots,
pricing information, etc. Then, with a single click they could choose
to consume my app in their domain.

> Users seem generally tolerant of this if you are professional. FogBugz, for
> example, have an excellent bug tracking (and more) platform, which is
> optionally hosted on their hardware. The same goes for a plethora of other
> companies.

I agree, but I would prefer if I could just take myself out of the
loop. It's their data. I really don't want access to it. I'm
presenting a system whereby I can develop an app that potentially
deals with sensitive data and I can assure customers that only they
(and Google) have access to that data, not me.

Someone else raised the issue of bugs that would require access to the
datastore to resolve. If that were the case, I would much rather have
a customer opt-in to giving me some type of access to their data when
they find it necessary because of a software bug. In that case, the
vast majority of users would probably not need to ever give me
access. Only the minority who encounter a bug and want to help in the
resolution would need to expose their data to me as the developer.

> One important thing to note is that there are few (if any) plausible
> scenarios that _don't_ require trust from your users. Since you wrote the
> code, you could easily be doing nearly anything with their data; if you
> provide for updates, you could modify the app to disclose information to
> you, even if you don't have direct access to their datastore. Essentially
> the only way around this would be to provide your users with the source, and
> make updates entirely manual and up to them to apply.

Sure, but customers are used to running software. They're not as used
to having their data live under someone else's control.

But, to be honest, let's just forget that I even mentioned the
security issue with regard to the datastore: the fact still remains
that it would be much less work for me as a developer if I could
develop an app that works against a client's own datastore rather than
my app's shared datastore.

The complexity of my models goes down:
- I don't need to store information about which clients own which
data

My development time goes down:
- I don't need to spend time enforcing client separation
- I don't need to write as much code to handle who the current
client using the app is
- I don't need to develop a time/storage billing system per-client
to recoup my GAE hosting costs

My potential return goes up:
- Lots of companies are using Google Apps for hosting their domains,
this is a nice market for me to target
- Google Apps Marketplace would provide an easy way for people to
find and subscribe to/buy my application
- Google makes out well, too, taking some percentage of the
subscription/sale

All these things seem like they'd be wins on both Google's side and
GAE developers' sides. Yes, your links may provide ways that GAE
developers can do some of this, but it's certainly less attractive
than the solution I'm proposing.

[Jay]

There is a Google Apps Marketplace. Have you seen it?
http://www.google.com/enterprise/marketplace/
It is not the solution you are looking for though.

I don't think I want Google to offer a separate datastore option. (I'm
not sure I understand what that would actually mean). Offering a
separate datastore would certainly complicate things for the platform
- and I want my platform fast and stable. Although I understand the
motivation behind what is being discussed, my vote is not in that
direction.

I'm also not sure I understand what you are getting at with your
second point. What does it mean to 'install' a Google App Engine
application "in" a Google Apps domain? The Google Apps Marketplace
offers this, but again, I don't think it is probably what you are
intending.

These questions of "where is my data, how secure is it, who has access
to it" are good ones. Some companies are prepared to embrace cloud
based solutions for some applications. I'm sure the distribution of
which companies for what applications will change over time. But, if
it is a big concern for them, and it certainly is a legitimate
concern, then a cloud based solution of the variety offered by google
app engine may not be the best fit.

Of course there are many other alternatives. For example, one could
put together an Appscale based solution and run it on Rackspace cloud.
There are many many options.

-- Jay

[hawkett]

I tried arguing for a similar model around this about 18 months ago

http://groups.google.com/group/google-appengine/browse_thread/thread/439d466d4e04b522/7847cf95195d53a7

And created an issue for it

http://code.google.com/p/googleappengine/issues/detail?id=945

It's not quite the same as what you are asking, as I was looking for a
common admin console for a single app deployment by the vendor (not
the customer) with multiple customers and multiple backing datatsores
- precisely because of the customer confidence thing. The main
argument was that being professional and trustworthy didn't prevent
bugs - having different customer's data separated at the platform
level is a whole different world of customer comfort to saying 'I
promise we programmed it real safe'. It's not about whether I
programmed it real safe or not - it't about reducing barrers to
customer acceptance.

The single app/admin console is a must-have from my perspective -
managing a stack of different app versions across multiple customers
would be a logistical nightmare (well we know it is - that's what this
cloud thing is for).

The concept of '1-click, new customer, separate datastore, single
admin console with both consolidated and drill-down stats' seems
compelling to me. Granted the marketplace delivers all of that except
the separate datastores, so I'm not complaining, but the separate
datastore thing has a lot of strong arguments.

In fact, the separate datastore would apply to task queues as well.
The main reason is that when something goes wrong, it can go wrong for
all your customers - getting tasks for one customer stuck in the
queue? That impacts all of your customers. One customer pushing
quotas? That impacts all your customers. The thread above links to an
issue in another project that highlights the sort of things customers
are scared of.

I noticed when I changed my app's name the other day, and used a
bookmark from before the name change (containing a key from the old
app), GAE threw an error that basically said 'this app can't access
this other app's data' - and it was a warm fuzzy feeling that the
platform was sorting that stuff out. Now if the key also contained a
customer identifier, the same logic could easily apply. 'Customer
identifier' could be an openid provider, which every google apps
account is.

Now I know each of us can implement that right now with the dbhooks
article that Nick wrote, and that's definitely very cool - but that's
a gazillion developers all rolling their own solution - and that looks
scary as hell to a conservative customer. They don't know who they
can trust - it's a much easier sell to say google does it at the
platform level - and a much easier sell is a win for google as well,
especially if they are taking a cut on the platform use - especially
by big conservative customers.

It is a bit of strange argument, because on the one hand I am saying
we don't want things that go wrong in the app to affect all our
customers, and the other hand arguing that google should move
functionality into the platform, where if things go wrong, well that's
not just my customers, but everyone's customers. But its an argument
that works, because google has the resourcesto handle that kind of
stuff - it's their core business. An that's a lot more attractive to
customers.

Anyway, just thinking out loud really...

[Jay]

Nice discussion. Hawkett, what do you think the api you are describing
might look like? Or is there no change because app engine would know
that an app has been deployed to a google apps domain (through Google
Apps Marketplace) and build that info into the keys or what not like
they currently do with app-id? If there is a change to the api, can
you sketch an example of how you are thinking about it?

On May 11, 5:10 pm, hawkett <hawk...@gmail.com> wrote:
> I tried arguing for a similar model around this about 18 months ago
>

> http://groups.google.com/group/google-appengine/browse_thread/thread/...

> > > solutions. One option is detailed in my blog post here:http://blog.notdot.net/2009/11/API-call-hooks-for-fun-and-profitandan...

[hawkett]

Hi Jay,

I'm thinking that the API would change very little - certainly 100%
backward compatible with existing app engine code. For the simple use-
case though - 'on' or 'off' - configure it in app.yaml - if it's on,
then the datastore essentially has a 'login:required' flag on it, and
all keys for that application must contain the openid provider - that
field on the key is not something the developer can set (like the app
id). If it's off, then its what we have now. An extra method on the
Key class - e.g. Key.openid_provider() would make sense as well - when
the config is off, it returns None. Exposing to the customer whether
this flag was set would also be very helpful. The important thing here
is that developer doesn't even have the opportunity to muck it up.
Every app in the marketplace with this flag on is suddenly seeming
much more secure to the customer. Beyond the marketplace, using
openid in this fashion means customers are not restricted to google
apps - any (trusted) openid provider would work.

There's plenty of other stuff to consider, such as adminstrator access
to the datastore - it's hard to see how you could avoid allowing app
administrators full privileges. But that's a different problem -
where you can trust the integrity of the vendor, and don't need to
worry about their ability to deliver a bug free application that won't
expose your data accidentally. Then there's google's access to the
data as well - I can't work out from the terms what the restrictions
on google's access are. I'm guessing most of incentives for google to
keep it secure are reputational, and while those are pretty good
incentives, it is a bit of a grey area for customers.

It would also be good to be able to specify the lock against
particular kinds - Nick highlighted this advantage in his 'enforcing
data isolation...' article linked above. The problem with this though
is that it introduces the ability for the developer to muck it up. It
would also be a lot messier to expose the configuration to the
customer. But still, making it configuration based is good, and it can
be easily highlighted in the admin console which Kinds are secured and
which are not. Remember the goal here is not to prevent malicious
attacks - just make it easy for developers to deliver applications
that secure their customers data, and that customers understand to be
secure. Cheers,

Colin

> ...
>
> read more »

[Robin]

re the Pricing model.

An App Engine App Store along the lines of Apple's iPhone app store,
would surely be a winner for everyone! This would be a fantastic
feature.

Although I would like to think Google would be a little more generous
in their ToCs re the commission they take.

[hawkett]

Worth noting that the two markets are quite different - with one being
consumer and one being business. Business generally will make less
snap purchases, will do more due diligence, and be prepared to pay
more once they establish the product they intend to buy.