Should we allow control over where the app is serving from? Sure, that sounds very reasonable, and is notably important for certain legal reasons amongst our European customers.
Should we design our system so that if the datacenters where an app is deployed are vaporized, then the app keeps serving? No, this is a much thornier issue. Notably, I disagree with the claim that true inter-continental deployment of an app is a "basic premise of modern cloud computing", mostly because this is really hard, and few systems actually get this right. Think about it from the view of a datastore write. When you write an entity, should that entity be immediately available on every continent? The reasonable answer is no, because if we guaranteed that, then the write latency would skyrocket. But if we don't guarantee that, what do we guarantee instead? If the app is presently serving from two continents, but we do not guarantee strong write behavior, how are conflicting writes then to be merged? If one datacenter disappears and then later comes back online, what happens to the writes that were halfway applied but not yet fully merged? Do we permit data to be dropped or do we try to reconcile this data, in spite of the fact that it may be hours or days stale? The answer to the above questions rely heavily on the specifics of the data and the behavior of the application, and most apps are happy to avoid this issue and are fine serving from one or a small number of locations. It's not a trivial thing to design one (or a handful of) generic APIs that support true inter-continental application presence, but this doesn't mean we'll give up trying to do so. We also welcome any technical suggestions you have. For instance, how would you presently solve this issue outside of Google App Engine? On Oct 7, 1:39 pm, "Andrew Badera" <[EMAIL PROTECTED]> wrote: > That's the point of the cloud -- if you're going to make your resources > external, remote, you need to provide a means for assuring uptime. For some > people, different geophysical locations are required for their service. > Obviously GAE beta shouldn't see a true NEED for this while still in beta, > but like SSL and everything else GAE lacks, there IS a need, it IS a basic > premise of modern cloud computing. > > On Tue, Oct 7, 2008 at 4:35 PM, Sal <[EMAIL PROTECTED]> wrote: > > > So you want to be assured that if all the Google data centers in the > > U.S. (over 12) go down (I wonder the probability of this), your GAE > > application will still be up? > > > On Oct 7, 11:35 am, "Andrew Badera" <[EMAIL PROTECTED]> wrote: > > > Ahh ... availability and assurance? That's half the point of the cloud. > > > > On Tue, Oct 7, 2008 at 2:34 PM, Sal <[EMAIL PROTECTED]> wrote: > > > > > Honestly, why would anyone need to deploy their GAE applications to > > > > international data centers? > > > > > On Oct 7, 10:48 am, dleifker <[EMAIL PROTECTED]> wrote: > > > > > What exactly does the term Google's Infrastructure imply? Once > > > > > deployed does an application get deployed to regional (ie > > > > > international) data centers? If not, from what general geographical > > > > > area are the applications being served from? (US only?) And are there > > > > > plans to allow an application to be deployed to international > > > > > locations? > > > > -- > > > Thanks- > > > - Andy Badera > > > - [EMAIL PROTECTED] > > > - (518) 641-1420 > > > > -http://higherefficiency.net > > > -http://changeroundup.com/ > > > > -http://flipbitsnotburgers.blogspot.com/ > > > -http://andrew.badera.us/ > > > > - Google me:http://www.google.com/search?q=andrew+badera --~--~---------~--~----~------------~-------~--~----~ 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-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
