[google-appengine] Re: Definition of Google's Infrastructure
Hi Alexander, This is a pretty neat idea, I like it. Also, it has the advantage of not being very hard for us to do. You'll notice we already have a read- only mode in place for datastore maintenance (i.e. CapabilityDisabledError from http://code.google.com/appengine/docs/datastore/exceptions.html). In the case of catastrophic failures, we could certainly have the system serve the app from a read-only datacenter. Of course, we will strive to minimize this as much as possible, but when all write- capable datacenters are down this is sure better than serving nothing at all! Please do file an issue on the tracker and let me know the link. Cheers, Jon On Oct 17, 3:20 pm, Alexander Konovalenko [EMAIL PROTECTED] wrote: On Oct 8, 11:17 am, Jon McAlister [EMAIL PROTECTED] wrote: Regarding the CDN case is markedly different from the datastore case, since you're just dealing with immutable blobs. This is not the thorny issue. I think I've got an idea. If there is a major problem that takes all the servers that are able to serve my app offline, it would be nice if the app could still operate in read-only mode from a backup data center on another continent. Many apps can indeed stay useful in read-only mode. And it might significantly alleviate the pain of service disruption for users. This looks like a feasible thing to implement. I'll describe it from the point of view of a single app. Several backup snapshots of the datastore could be continually maintained in remote data centers. The snapshots would lag behind the master copy a minute or two (or more), so they wouldn't have to be located close to the master copy, which is the point. When a severe service disruption affecting all master data centers is detected, the app's DNS quickly fails over to a backup data center, where the app continues to run in read-only mode using the last datastore snapshot. The application should detect the read-only mode to make sure it doesn't try to write anything to the database and to inform the users. When the problems have been settled, the app reverts to normal read- write mode. Most of the time the old master data center would take over. If it has been destroyed or something, one of the backup data centers could be manually made the master for this particular app. In that case, several minutes worth of data would be lost, but that seems acceptable for a complete destruction of the original data centers. I don't know whether there are serious holes in this outline, because I'm not really a distributed systems guy. Does it make sense? Jon, do you think it's worth to file an issue about this? -- Alexander --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Definition of Google's Infrastructure
On Oct 8, 11:17 am, Jon McAlister [EMAIL PROTECTED] wrote: Regarding the CDN case is markedly different from the datastore case, since you're just dealing with immutable blobs. This is not the thorny issue. I think I've got an idea. If there is a major problem that takes all the servers that are able to serve my app offline, it would be nice if the app could still operate in read-only mode from a backup data center on another continent. Many apps can indeed stay useful in read-only mode. And it might significantly alleviate the pain of service disruption for users. This looks like a feasible thing to implement. I'll describe it from the point of view of a single app. Several backup snapshots of the datastore could be continually maintained in remote data centers. The snapshots would lag behind the master copy a minute or two (or more), so they wouldn't have to be located close to the master copy, which is the point. When a severe service disruption affecting all master data centers is detected, the app's DNS quickly fails over to a backup data center, where the app continues to run in read-only mode using the last datastore snapshot. The application should detect the read-only mode to make sure it doesn't try to write anything to the database and to inform the users. When the problems have been settled, the app reverts to normal read- write mode. Most of the time the old master data center would take over. If it has been destroyed or something, one of the backup data centers could be manually made the master for this particular app. In that case, several minutes worth of data would be lost, but that seems acceptable for a complete destruction of the original data centers. I don't know whether there are serious holes in this outline, because I'm not really a distributed systems guy. Does it make sense? Jon, do you think it's worth to file an issue about this? -- Alexander --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Definition of Google's Infrastructure
Regarding 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. does this mean that an app's data is stored in one and only one data center with no off-site backups? I could understand that the off-site backup of an app isn't automatically started up when there is a burp in service from a datacenter, but if all of the data was lost from a datacenter would it just be gone? On Oct 7, 9:26 pm, Jon McAlister [EMAIL PROTECTED] wrote: 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Definition of Google's Infrastructure
The OP said: get deployed to regional (ie international) data centers? I'm taking more of a generic geophysical location, not international, or as you've framed, intercontinental perspective. But in the end, it's the same -- availability zones will, when fully rolled out, offer geophysical differentiation of deployments, and that is, in fact, quite intrinsic to modern cloud computing. SSDS, same deal. I want to say Hadoop nodes are also organized this way. It's just the way it's done for professional cloud deployments. You have 12 different Google datacenters for a reason -- some of the same reason those deploying applications in the cloud need geophysical differentiation. On Wed, Oct 8, 2008 at 1:17 AM, Jon McAlister [EMAIL PROTECTED] wrote: Regarding the CDN case is markedly different from the datastore case, since you're just dealing with immutable blobs. This is not the thorny issue. Regarding the EC2 availability zone case, these are not spread across continents. Quoting from http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1347: Amazon EC2 now provides the ability to place instances in multiple locations. Amazon EC2 locations are composed of regions and availability zones. Regions are geographically dispersed and will be in separate geographic areas or countries. Currently, ***Amazon EC2 exposes only a single region***. So, this case is not very complicated either, since all the availability zones are right next to one another. I contend that neither of these solve the generic problem. On Oct 7, 9:59 pm, Andrew Badera [EMAIL PROTECTED] wrote: EC2 has availability zones. SSDS will be doing something similar. CDNs and SDNs often operate on the concept of replicating content close to various edges in order to reduce latency/improve throughput. Short of fixes on that scale, one must engage in data sync'g in some form or another. All kinds of reasons for it, and it's most definitely already being done, in various forms. On Wed, Oct 8, 2008 at 12:26 AM, Jon McAlister [EMAIL PROTECTED] wrote: 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
[google-appengine] Re: Definition of Google's Infrastructure
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 -~--~~~~--~~--~--~---
[google-appengine] Re: Definition of Google's Infrastructure
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 -~--~~~~--~~--~--~---
[google-appengine] Re: Definition of Google's Infrastructure
Reliability/redundancy is important. However don't overlook the fact that performance for international users is greatly affected by your server's location, considering latency/packet loss, etc. And there are markets outside the US. ;-) On Oct 7, 3: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 -~--~~~~--~~--~--~---
[google-appengine] Re: Definition of Google's Infrastructure
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 -~--~~~~--~~--~--~---
[google-appengine] Re: Definition of Google's Infrastructure
EC2 has availability zones. SSDS will be doing something similar. CDNs and SDNs often operate on the concept of replicating content close to various edges in order to reduce latency/improve throughput. Short of fixes on that scale, one must engage in data sync'g in some form or another. All kinds of reasons for it, and it's most definitely already being done, in various forms. On Wed, Oct 8, 2008 at 12:26 AM, Jon McAlister [EMAIL PROTECTED] wrote: 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Definition of Google's Infrastructure
Regarding the CDN case is markedly different from the datastore case, since you're just dealing with immutable blobs. This is not the thorny issue. Regarding the EC2 availability zone case, these are not spread across continents. Quoting from http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1347: Amazon EC2 now provides the ability to place instances in multiple locations. Amazon EC2 locations are composed of regions and availability zones. Regions are geographically dispersed and will be in separate geographic areas or countries. Currently, ***Amazon EC2 exposes only a single region***. So, this case is not very complicated either, since all the availability zones are right next to one another. I contend that neither of these solve the generic problem. On Oct 7, 9:59 pm, Andrew Badera [EMAIL PROTECTED] wrote: EC2 has availability zones. SSDS will be doing something similar. CDNs and SDNs often operate on the concept of replicating content close to various edges in order to reduce latency/improve throughput. Short of fixes on that scale, one must engage in data sync'g in some form or another. All kinds of reasons for it, and it's most definitely already being done, in various forms. On Wed, Oct 8, 2008 at 12:26 AM, Jon McAlister [EMAIL PROTECTED] wrote: 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
