Hi Greg, Thanks for the detailed response. It removes a lot of the uncertainty, allowing us focus on actual concerns.
My main concerns now are: - prohibitive cost of backend instance - 15 minutes idle time cost for frontend instances - details on what experimental entails, with respect to GO runtime *Prohibitive cost of backend instance* Backend Instances seem ridiculously and prohibitively high ($115/month for a resident 256MB/1.2GHz instance). Their prohibitive costs makes them very unattractive for a lot of users who could leverage this functionality, causing us to look elsewhere. In a way, it seems we're caught between a rock and a hard place. Backends are an excellent way to do long-running CPU-intensive actions, allowing us move away from the current practice of spawning chains of tasks which each complete in a set time, or using a map-reduce operation. However, the backends are so expensive that most people will not use them. Unfortunately, the current practice of using frontend instances and tasks/map-reduce is now expensive also because for each instance, we have to pay an extra 1/4 instance hour tax beyond our usage. *15 minutes idle time cost for frontend instances* For backends, the 1/4 hour may make sense, since backends are typically used for long-running tasks. However, for frontends where requests should typically finish within a second, and loading time can be within a second, the 1/4 hour tax seems unfair. Since loading time and request time for frontends can be within a second, it doesn't make sense to keep idle instances up for 15 minutes. Something in the tune of 1 minute for instances beyond the first one is more ideal (ie if u have one instance handling requests, keep the 15 minutes idle time. For instances 2 and up, shut them down after 1 minute of inactivity). *details on what experimental entails, with respect to GO runtime* The other question I had was with GO support. The current SDK - does not support transactions, batch datastore operations, parallel requests, etc - depends on using the remote API to the python SDK which could limit the ability to do some functionality (e.g. integrated testing framework, etc) - has an API which sometimes feels like a proof-of-concept API, and not a fully designed uniform API set - Also, the Google Group for it seems like a ghost town, which suggests either low interest or some level of disappointment in the current SDK set It looks really "experimental" unlike the Java SDK which was experimental when released but was much more featureful and integrated. Can you define what experimental means with respect to GO runtime: - how long will it be supported for, in case Google decides to pull the plug for lack of demand - is there a roadmap for the features. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. 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.
