4 ms·

> I'm going to assume everyone experiencing this issue is using M/S. Upgrading to HRD will solve your issue. This is the reason I abandoned AE and part of why

> I'm going to assume everyone experiencing this issue is using M/S. Upgrading to HRD will solve your issue. This is the reason I abandoned AE and part of why adopting a platform that isn't standardized is incredibly dangerous. The problem is technical debt constantly accrues even when you aren't making changes. Even though the API was unchanged, HRD differs subtly enough that breakage can occur on any non-trivial project. Edge cases (how indices behave within transactions comes to mind, but there are plenty more examples) will see new semantics compared to M/S, and so this "upgrade" involves not only thorough testing and auditing, but likely also code changes and potentially significant engineering hours. http://goo.gl/HVuaC http://goo.gl/HVuaC: These techniques are not needed with the (now deprecated) Master/Slave Datastore, which always returns strongly consistent results for all queries. This means a project written and signed off circa 2011 requires mandatory engineering costs just to continue running in a functioning and supported fashion. An AE app will never quite resemble that ancient perl5 behemoth running uninterrupted since 1997, as the underlying implementation and recommended APIs are constantly modified and replaced (Datastore, NDB, Python major version). "A strong test suite will save your soul!" I hear you say, tests that a small project might have survived without if targeting any other platform, and testing on AppEngine is also yet another moving target (for example, testing nested subrequests was all but impossible using the SDK until relatively recently). The promise was a carefree life for a project willing to code against their proprietary APIs; the reality is a constantly moving target, "not quite free" autoscaling and the threat that while you're asleep an unannounced change will take down your app (I could name a few, but as many will attest this has happened regularly since launch).

Benferhat 14y ago
The Master/Slave datastore has been deprecated for almost a year. [0] Beyond the latency issues, it simply wasn't reliable; both reads and writes were failing way too often. I'm glad GAE is focusing its resources on the HRD. [0] http://googleappengine.blogspot.com/2012/04/masterslave-datastore-thanks-for-all.html http://googleappengine.blogspot.com/2012/04/masterslave-data...
- muraiki 14y ago
  The problem is occurring during the same timeframe for someone else who is using the HRD: https://code.google.com/p/googleappengine/issues/detail?id=8788#c12 https://code.google.com/p/googleappengine/issues/detail?id=8...
Ensorceled 14y ago
> The promise was a carefree life for a project willing to code against their proprietary APIs; the reality is a constantly moving target, "not quite free" autoscaling and the threat that while you're asleep an unannounced change will take down your app (I could name a few, but as many will attest this has happened regularly since launch). Yeah, I got sucked in with the same promise and I had the exact same sour experience. Including panicky calls from the client when the app suddenly stopped working. The maintenance windows used to plop right in the middle of my client's busy time, once a month at least and often more. The worst part is the apologists, like lysprr@gmail.com in the original bug report: > I got here from HackerNews, but after seeing the original poster spam the forums in multiple places and have a bad attitude, I can't blame Google for not fixing what looks to me like a non-issue. > > Fuck 'em. That always reply to your request for help while you're attempting to fix a suddenly dead application and a totally screwed client.
- deleted 14y ago
  [deleted]
  - BCM43 14y ago
    What? Their message is at the bottom of the linked page, with their email above it.
codeulike 14y ago
Salesforce have quite a nice solution for a similar problem. If you write custom Apex code, the platform will not let you deploy it to live unless it has sufficient unit test coverage. It runs the tests and calculates code coverage when you try and deploy, and if your tests aren't covering enough, no deployment happens. So, you have tests. Then, upcoming platform changes are released to sandbox environments six months or so before they go live - you can see if your tests run, and have time to keep up with things. You do have to keep up though.
- to3m 14y ago
  I take it they then don't have any tests of their own to assure backwards compatibility? Maybe I've been spoiled by using Windows for 20 years but I feel that we should be able to expect better from vendors than this. That goes double if you're paying them, though it sounds in Salesforce's case as if they pay you, because I can't see any other way in which this arrangement would make sense.
  - codeulike 14y ago
    > I take it they then don't have any tests of their own to assure backwards compatibility? I think they do. They take that pretty seriously, breaking changes to the API are rare and usually obscure edge cases.
mcmillen 14y ago
If you've been running a 1997-era Perl app unmodified --including the operating system of the machine it's running on, and security patches to Perl in the mean time -- you are so owned and I really hope you're not storing any important data on that box. I'm not saying that App Engine is a panacea, but regardless of how you write your code and what technologies you use, there'll be some sort of mandatory maintenance and system administration that you have to do every so often.
- hosay123 14y ago
  That's a fair point, however my personal expectation would be that unlike a perl (or PHP or Python or .. solution), App Engine probably won't exist in its current form as a supported product in 16 years. Maybe it'll go the way of Wave, or perhaps hopefully the technology style itself will simply be supplanted by newer and better. Regardless I'd say that given an app today, the 1997 perl5 app (MySQL 3.2 and perl5.003 were already circulating) still has much better supportability prospects over this time frame than App Engine ever did or ever will.
wallywax 14y ago
> This means a project written and signed off circa 2011 requires mandatory engineering costs just to continue running in a functioning and supported fashion. Funny (?) thing is, as an engineer at Google, stuff like that happened to me ALL THE TIME. I don't even want to think about how much of my time was spent simply migrating to the "latest greatest" replacement for some critical service that was being deprecated.
- theatrus2 14y ago
  I think thats the modus operandi of any big internet company with significant internal infrastructure. The next big thing is always coming.

Benferhat 14y ago

The Master/Slave datastore has been deprecated for almost a year. [0] Beyond the latency issues, it simply wasn't reliable; both reads and writes were failing way too often. I'm glad GAE is focusing its resources on the HRD. [0] http://googleappengine.blogspot.com/2012/04/masterslave-datastore-thanks-for-all.html http://googleappengine.blogspot.com/2012/04/masterslave-data...

muraiki 14y ago
The problem is occurring during the same timeframe for someone else who is using the HRD: https://code.google.com/p/googleappengine/issues/detail?id=8788#c12 https://code.google.com/p/googleappengine/issues/detail?id=8...

Ensorceled 14y ago

> The promise was a carefree life for a project willing to code against their proprietary APIs; the reality is a constantly moving target, "not quite free" autoscaling and the threat that while you're asleep an unannounced change will take down your app (I could name a few, but as many will attest this has happened regularly since launch). Yeah, I got sucked in with the same promise and I had the exact same sour experience. Including panicky calls from the client when the app suddenly stopped working. The maintenance windows used to plop right in the middle of my client's busy time, once a month at least and often more. The worst part is the apologists, like lysprr@gmail.com in the original bug report: > I got here from HackerNews, but after seeing the original poster spam the forums in multiple places and have a bad attitude, I can't blame Google for not fixing what looks to me like a non-issue. > > Fuck 'em. That always reply to your request for help while you're attempting to fix a suddenly dead application and a totally screwed client.

deleted 14y ago
[deleted]
- BCM43 14y ago
  What? Their message is at the bottom of the linked page, with their email above it.

codeulike 14y ago

Salesforce have quite a nice solution for a similar problem. If you write custom Apex code, the platform will not let you deploy it to live unless it has sufficient unit test coverage. It runs the tests and calculates code coverage when you try and deploy, and if your tests aren't covering enough, no deployment happens. So, you have tests. Then, upcoming platform changes are released to sandbox environments six months or so before they go live - you can see if your tests run, and have time to keep up with things. You do have to keep up though.

to3m 14y ago
I take it they then don't have any tests of their own to assure backwards compatibility? Maybe I've been spoiled by using Windows for 20 years but I feel that we should be able to expect better from vendors than this. That goes double if you're paying them, though it sounds in Salesforce's case as if they pay you, because I can't see any other way in which this arrangement would make sense.
- codeulike 14y ago
  > I take it they then don't have any tests of their own to assure backwards compatibility? I think they do. They take that pretty seriously, breaking changes to the API are rare and usually obscure edge cases.

mcmillen 14y ago

If you've been running a 1997-era Perl app unmodified --including the operating system of the machine it's running on, and security patches to Perl in the mean time -- you are so owned and I really hope you're not storing any important data on that box. I'm not saying that App Engine is a panacea, but regardless of how you write your code and what technologies you use, there'll be some sort of mandatory maintenance and system administration that you have to do every so often.

hosay123 14y ago
That's a fair point, however my personal expectation would be that unlike a perl (or PHP or Python or .. solution), App Engine probably won't exist in its current form as a supported product in 16 years. Maybe it'll go the way of Wave, or perhaps hopefully the technology style itself will simply be supplanted by newer and better. Regardless I'd say that given an app today, the 1997 perl5 app (MySQL 3.2 and perl5.003 were already circulating) still has much better supportability prospects over this time frame than App Engine ever did or ever will.

wallywax 14y ago

> This means a project written and signed off circa 2011 requires mandatory engineering costs just to continue running in a functioning and supported fashion. Funny (?) thing is, as an engineer at Google, stuff like that happened to me ALL THE TIME. I don't even want to think about how much of my time was spent simply migrating to the "latest greatest" replacement for some critical service that was being deprecated.

theatrus2 14y ago
I think thats the modus operandi of any big internet company with significant internal infrastructure. The next big thing is always coming.