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... On May 7, 8:53 pm, Andy Burke <abu...@bitflood.org> wrote: > > 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-profitandanother > > 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. > > 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-appeng...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
