Thanks for your input! Well, the main reason why I came up with the approach to deploy applications to each customer mainly was because of the AuthSub restriction that each app could only be restricted to one Google Apps domain. This was the only way to allow users to login with a Google Apps account and grant access to their contacts data. A lot has changed since the initial version (OpenID/OAuth support etc.) and since the most recent versions of the SDK I'm confident that it the task queues will allow to handle thousands of concurrent tasks/users. This has been another showstopper for us as we have to run thousands of long living background tasks in parallel.
However I'd of course prefer to put all apps under a premium account but as far as I understand it will not be possible to add all applications that I own as a developer - only the once that are added to our own Google Apps domain as a service? Or am I wrong? This would be very good news indeed as this would resolve the 9$/month minimum fee. Daniel On Wednesday, November 9, 2011 3:49:56 PM UTC+1, Jon McAlister wrote: > > Are there other reasons holding you back? I ask because the two you > have listed could both be overcome. The simplest design I could > imagine would be for you to code your own authorization and accounting > system within your app. It would take some work, but would presumably > pay for itself in terms of keeping your customers and also gaining new > customers. That is, the app would accept login from all Google > accounts, but then your code checks the accounts against ACLs > maintained by the app itself. You'd need to also write an admin page > to allow the customer to add or remove folks from the ACL, but this is > also somewhat better because now you could control the UI here. In > terms of accounting, one simple solution would be for you to run a > mapreduce each night to compute how much space/ops is used for each > customer. Then, customers using lots of space would be billed. Given > that, as you say, most customers use very little resources, you should > only need to bill your top customers specially. > > The alternative would be for you to work out a special contract as a > Premier Account, so that all of these apps were billed to your Premier > Account instead of to the customer: > http://code.google.com/appengine/docs/premier/index.html > > On Wed, Nov 9, 2011 at 4:42 AM, Daniel Florey <[email protected]> wrote: > > Hi Emlyn, > > running as a multi-tenancy app is not doable for several reasons: > > - Clients want to be able to protect the data by managing the permissions > > (=access to the datastore) by themselves > > - The app can use a lot of resources depending on the settings of the > > customer. I don't see a simply way to charge them for the resources > consumed > > when using a multi-tenancy app > > You plugin concept sounds very interesting and is a good idea! In our > case > > we are the only app running on app engine in 99% of the cases. Once GAE > is > > more widely adopted this would be very interesting. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/google-appengine/-/UKr8tzjcJgEJ. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > 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 view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/PePR_FjRT3sJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
